Layer for executing other os programs
Layer for executing other os programs
I like to know how an os could run an exe file of win3.x or win9x and so on?
I mean in win9x it was possible to run old win3.x programs and dos programs and you can also run dos programs in win xp. Dos programs could be run in an virtual machine like dosbox or like win9x does it in vm86 mode, but how does an os know what program needs what os libraries?
I do not want (at the moment ) to implement things like that, but I like to know how it works and maybe some day I have much free time I like to try to write some code which does something like this.
The reason I ask, is that I could imagine an os which has a microkernel and for every os (the programs) it supports it has a server and on such an os it would just need to write another server and you could support another os (in theory).
I mean in win9x it was possible to run old win3.x programs and dos programs and you can also run dos programs in win xp. Dos programs could be run in an virtual machine like dosbox or like win9x does it in vm86 mode, but how does an os know what program needs what os libraries?
I do not want (at the moment ) to implement things like that, but I like to know how it works and maybe some day I have much free time I like to try to write some code which does something like this.
The reason I ask, is that I could imagine an os which has a microkernel and for every os (the programs) it supports it has a server and on such an os it would just need to write another server and you could support another os (in theory).
Re: Layer for executing other os programs
Research exoKernels. And possibly wine (that's: wine is not an emulator).
Though, if you're looking to do that for Your OS - I'd focus on getting very stable support for native applications first.
In a nutshell it would involve emulating/wrapping the entire API of the target operating system - including any foreign instruction sets (for example if you wanted to run PPC OSX applications on x86 hardware).
It boils down to a lot of work.
-B
EDIT: Clarification about PPC apps.
Though, if you're looking to do that for Your OS - I'd focus on getting very stable support for native applications first.
In a nutshell it would involve emulating/wrapping the entire API of the target operating system - including any foreign instruction sets (for example if you wanted to run PPC OSX applications on x86 hardware).
It boils down to a lot of work.
-B
EDIT: Clarification about PPC apps.
Re: Layer for executing other os programs
The idea was that it would be cool to have an os which has very good driver support and where you could run all your old apps or you have only 1 os and needn´t to restart your pc to run some special apps, which aren´t exist for another os.
It´s only an idea, I don´t thin that I will do such things for my os, but as always a human is very curiously and so I am
It´s only an idea, I don´t thin that I will do such things for my os, but as always a human is very curiously and so I am
-
- Member
- Posts: 566
- Joined: Tue Jun 20, 2006 9:17 am
Re: Layer for executing other os programs
Hi,
Windows is a multiple personality operating system , it supports 3 different subsystems (a) POSIX subsystem (b) Win32 subsystem (c) os/2 susbsystem . The os determines the executable type by examining the executable header .You may take a look at the tool exetype
Regards
Shrek
Windows is a multiple personality operating system , it supports 3 different subsystems (a) POSIX subsystem (b) Win32 subsystem (c) os/2 susbsystem . The os determines the executable type by examining the executable header .You may take a look at the tool exetype
Regards
Shrek
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re: Layer for executing other os programs
Actually, I think the OS/2 subsystem was retired quite a while ago. And you forgot NTVDM -- I'm pretty sure it's a "personality" subsystem in its own right.
@Flashburn: I think that the cheapest way to accomplish what you're talking about is virtualization. Now that it's hardware-accelerated and ubiquitous, it's much easier to get the OS you want to run, install it in a VM, and presto... Much easier than re-implementing each OS' API.
@Flashburn: I think that the cheapest way to accomplish what you're talking about is virtualization. Now that it's hardware-accelerated and ubiquitous, it's much easier to get the OS you want to run, install it in a VM, and presto... Much easier than re-implementing each OS' API.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re: Layer for executing other os programs
But there is the problem of 3d acceleration in a vm and a layer like wine has not that problem.
I will have a look at wine and see what it does. Thanks to all.
I will have a look at wine and see what it does. Thanks to all.
Re: Layer for executing other os programs
Basically you have to be able to interpret the executable format correctly. Old DOS programs uses a different (DOS specific) executable format so the loader would know that it needs to be run in vm86 mode, the same applies to Win3.x (IIRC). For Win3.x and NT (or XP) the libraries needed is determined from interpreting the executable (as part of the dynamic linking process). The executable may also contain information whether the file is for x86 or x64 so a 64-bit OS may run 32-bit applications properly.
-
- Member
- Posts: 566
- Joined: Tue Jun 20, 2006 9:17 am
Re: Layer for executing other os programs
Hi,Colonel Kernel wrote:Actually, I think the OS/2 subsystem was retired quite a while ago. And you forgot NTVDM -- I'm pretty sure it's a "personality" subsystem in its own right.
@Flashburn: I think that the cheapest way to accomplish what you're talking about is virtualization. Now that it's hardware-accelerated and ubiquitous, it's much easier to get the OS you want to run, install it in a VM, and presto... Much easier than re-implementing each OS' API.
You are correct , os/2 subsystem support is discontinued . But the NTVDM (theorectically at least) is considered as a part of the win32 subsystem ( to my recent recollection ) . Or it may another false assumption I made .In case your are correct colonel , then i forgot to mention wow64 as well
Regards
Shrek
Re: Layer for executing other os programs
Win 9x run Win 3.x apps is easy to do. It's just backward compatibility. But if u want your OS to run those, it's no so easy.
"Programmers are tools for converting caffeine into code."
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Layer for executing other os programs
The VM I use (VirtualBox) has 3D acceleration. And 3D acceleration in wine is a problem because the DirectX support (although very good) had some issues last time I checked.FlashBurn wrote:But there is the problem of 3d acceleration in a vm and a layer like wine has not that problem
- einsteinjunior
- Member
- Posts: 90
- Joined: Tue Sep 11, 2007 6:42 am
Re: Layer for executing other os programs
The whole big i dea behind all of this is the idea of a subsystem.
You OS could have "standard" system calls.Then the application,being it written
for win9x or even a posix application would be launched.
The appropriate subsystem will create a proper execution environment for the application
to run on.
The system calls used by the application are first redirected via the subsystem (i think it should work that way).The subsystem maps the system call to one of the operating system standard system calls and calls the kernel now.From there the kernel takes over and its still the responsibility of the subsystem to handle the return values and all the like.For example,since a posix app does not know much of maybe file handles that your os implements for example,the subsystem will keep a handle table for all open handles and return instead the required object to the application,say a file pointer,which is not exactly a file pointer in that sense.
The subsystem will map it to a handle evrytime maybe your app will like to read from the file.
Hope it helps.
You OS could have "standard" system calls.Then the application,being it written
for win9x or even a posix application would be launched.
The appropriate subsystem will create a proper execution environment for the application
to run on.
The system calls used by the application are first redirected via the subsystem (i think it should work that way).The subsystem maps the system call to one of the operating system standard system calls and calls the kernel now.From there the kernel takes over and its still the responsibility of the subsystem to handle the return values and all the like.For example,since a posix app does not know much of maybe file handles that your os implements for example,the subsystem will keep a handle table for all open handles and return instead the required object to the application,say a file pointer,which is not exactly a file pointer in that sense.
The subsystem will map it to a handle evrytime maybe your app will like to read from the file.
Hope it helps.