Uload ReactOS kernel module?
Uload ReactOS kernel module?
could i possibly have two kernel options in my OS, where one is my kernel and the other one ReactOS? Then the user could run some windows apps on my OS without installing a whole other one. is this possible?
oh microsoft, microsoft, what souls you have dismayed
- mathematician
- Member
- Posts: 437
- Joined: Fri Dec 15, 2006 5:26 pm
- Location: Church Stretton Uk
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Exokernels will still require the emulation layer. Actually, you'll need at least one in order to be even able to run ansi C applications...
Of course you could build a virtual machine that runs two OSes at the same time. Once the VM is complete you can theoretically run any program by switching OSes. No guest-specific code would be needed, but you'd have two separate systems which are really difficult to be made to cooperate with each other.
Of course you could build a virtual machine that runs two OSes at the same time. Once the VM is complete you can theoretically run any program by switching OSes. No guest-specific code would be needed, but you'd have two separate systems which are really difficult to be made to cooperate with each other.
Re: Uload ReactOS kernel module?
IMHO operating system = drivers + kernel + API + ABI. The ABI is generally determined by the process loading/creation functions in the kernel. Drivers are abstractified by the kernel to respond to various API calls. Are you therefore asking: can I create an operating system that can run programs with two sets of API/ABI implementations? In theory yes, but ReactOS is probably not the way, as its a complete operating system, expecting to run by itself. I suppose you could implement the ReactOS environment as it is open source, but you would need a very deep understanding of that particular project. You could, I suppose, port an emulator to your OS or even dualboot???com1 wrote:could i possibly have two kernel options in my OS, where one is my kernel and the other one ReactOS? Then the user could run some windows apps on my OS without installing a whole other one. is this possible?
Regards,
John.
Re: Uload ReactOS kernel module?
Hi,
Cheers,
Brendan
Have you considered porting Wine to your OS?com1 wrote:could i possibly have two kernel options in my OS, where one is my kernel and the other one ReactOS? Then the user could run some windows apps on my OS without installing a whole other one. is this possible?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
- Member
- Posts: 97
- Joined: Thu Mar 15, 2007 2:27 pm
WRONG! An exokernel isn't just a emulator OS, it multiplexes raw hardware, so each application uses a large lib instead of an os. i.e. oslib (or something like that) is a unix library, which unix apps can be compiled against, and run in the exokernel. It is a whole OS in a library, not really emulation.Combuster wrote:Exokernels will still require the emulation layer. Actually, you'll need at least one in order to be even able to run ansi C applications...
Of course you could build a virtual machine that runs two OSes at the same time. Once the VM is complete you can theoretically run any program by switching OSes. No guest-specific code would be needed, but you'd have two separate systems which are really difficult to be made to cooperate with each other.
Yes, and you can have multiple oslibs! Mwa ha ha! I was correct~!anon19287473 wrote:WRONG! An exokernel isn't just a emulator OS, it multiplexes raw hardware, so each application uses a large lib instead of an os. i.e. oslib (or something like that) is a unix library, which unix apps can be compiled against, and run in the exokernel. It is a whole OS in a library, not really emulation.Combuster wrote:Exokernels will still require the emulation layer. Actually, you'll need at least one in order to be even able to run ansi C applications...
Of course you could build a virtual machine that runs two OSes at the same time. Once the VM is complete you can theoretically run any program by switching OSes. No guest-specific code would be needed, but you'd have two separate systems which are really difficult to be made to cooperate with each other.
C8H10N4O2 | #446691 | Trust the nodes.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
It all depends on what you call emulation. In essence a libos is a conversion layer between the calls expected by application layer and the interfaces of the exokernel. Call it emulation or not, you still need a separate libos for windows programs, and a separate libos for *nix programs (and one for mac, and....)anon19287473 wrote:WRONG! An exokernel isn't just a emulator OS, it multiplexes raw hardware, so each application uses a large lib instead of an os. i.e. oslib (or something like that) is a unix library, which unix apps can be compiled against, and run in the exokernel. It is a whole OS in a library, not really emulation.Combuster wrote:Exokernels will still require the emulation layer. Actually, you'll need at least one in order to be even able to run ansi C applications...
Of course you could build a virtual machine that runs two OSes at the same time. Once the VM is complete you can theoretically run any program by switching OSes. No guest-specific code would be needed, but you'd have two separate systems which are really difficult to be made to cooperate with each other.
Similarly, wine provides a windows interface over your favorite linux in pretty much the same way. Still its called an emulator.
Also, true exokernel applications don't require a libOS. They use the raw interfaces of the kernel for their own gain.
Point remains, you need to provide code for each platform you want to run rather than just one. Something you wouldn't need with some virtual-machine style kernel/program.
Now, would you tell me what's so wrong about my statement?