DOS subsystem already dicussed in detail
Moderator: Moderator Team
DOS subsystem already dicussed in detail
Hello friends,
I saw some recent post about DOS/win16 subsystems.
I'd like to inform you that we already had a long discussion about the same topic.
Please have a look at http://www.reactos.com/forum/viewtopic.php?t=238
The above mentioned topic will clear most of the doubts about the approach to take for DOS subsystem.
We people are panning to start work on DOS subsystem soon. if anybody else has interest in it, we can discuss the idea at ReactOS developer mailing list.
I saw some recent post about DOS/win16 subsystems.
I'd like to inform you that we already had a long discussion about the same topic.
Please have a look at http://www.reactos.com/forum/viewtopic.php?t=238
The above mentioned topic will clear most of the doubts about the approach to take for DOS subsystem.
We people are panning to start work on DOS subsystem soon. if anybody else has interest in it, we can discuss the idea at ReactOS developer mailing list.
hello mjs,
If you read my post http://www.reactos.com/forum/viewtopic.php?p=2864#2864 in the above mentioned thread you'll see a something about 16 vs. 32 compiler suitability fro ROS subsystem.
Also please see Acetoline's replies. There are some other quite valuable comments from others.
We are planning to use mingw compiler for our approach.
Even after reading the above mentioned thread, you do not agee with our approach, you are welcome to go ahead with your implementation. In that case I'd suggest that gcc can also generate 16 bit code.
If you read my post http://www.reactos.com/forum/viewtopic.php?p=2864#2864 in the above mentioned thread you'll see a something about 16 vs. 32 compiler suitability fro ROS subsystem.
Also please see Acetoline's replies. There are some other quite valuable comments from others.
We are planning to use mingw compiler for our approach.
Even after reading the above mentioned thread, you do not agee with our approach, you are welcome to go ahead with your implementation. In that case I'd suggest that gcc can also generate 16 bit code.
Even in the thread you mentioned, the compiler isn't named 8) .
Maybe you don't know it but you cannot use MinGW gcc to build 16 bit code for 16 bit sections. It's no problem to build 16 bit code for 32 bit sections though.
MinGW's GCC can generate 16 bit code yes - but it's always prefixed for usage inside 32 bit sections so it's unusable for DOS or Win16. The 16 bit GCC from the DJGPP size can produce 16 bit code for plain DOS but it's not suitable for Win16.
IMHO the only open source compiler that supports Win16 and DOS (without extender) is OpenWatcom. A freely available closed source C/C++ compiler is DigitalMars ...
BTW: You don't need a C/C++ compiler when you're using NASM to code some small service functions ...
Regards,
Mark
Maybe you don't know it but you cannot use MinGW gcc to build 16 bit code for 16 bit sections. It's no problem to build 16 bit code for 32 bit sections though.
MinGW's GCC can generate 16 bit code yes - but it's always prefixed for usage inside 32 bit sections so it's unusable for DOS or Win16. The 16 bit GCC from the DJGPP size can produce 16 bit code for plain DOS but it's not suitable for Win16.
IMHO the only open source compiler that supports Win16 and DOS (without extender) is OpenWatcom. A freely available closed source C/C++ compiler is DigitalMars ...
BTW: You don't need a C/C++ compiler when you're using NASM to code some small service functions ...
Regards,
Mark
-
- Posts: 115
- Joined: Wed Jan 05, 2005 10:53 pm
- Location: a thousand miles from Hinterland
- Contact:
No 16-bit code needed whatsoever. The whole subsystem will be 32-bit. The only 16-bit code will (hopefully) be the DOS program you're trying to run.Maybe you don't know it but you cannot use MinGW gcc to build 16 bit code for 16 bit sections. It's no problem to build 16 bit code for 32 bit sections though.
It will be compiled with MinGW because it is what compiles the rest of the OS.
We didn't talk about compilers much because we mostly agreed that it should be MinGW (It's the most obvious solution).
P.S. I've finally mostly settled down in this new city and I've gotten my new computer
I'm working on a small VGA demo (to demonstrate my VGA card emulation routines) right now. I hope to release it in about 2-3 weeks.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.
we shall reinvent the wheel until it turns properly.
For a small - and almost incompatible - DOS16 emulation you might require a 16 bit compiler anyway for FAR CALL (16:16) emulation.AcetoliNe wrote:No 16-bit code needed whatsoever. The whole subsystem will be 32-bit. The only 16-bit code will (hopefully) be the DOS program you're trying to run.
For a DPMI-only (or well known DOS extender) DOS32 emulation, it might be sufficient to use MinGW only ...
For a Win16 subsystem you must create 16 bit DLLs - therefore you should use a 16 bit compiler.
Regards,
Mark
-
- Posts: 115
- Joined: Wed Jan 05, 2005 10:53 pm
- Location: a thousand miles from Hinterland
- Contact:
That's correct. We're not trying to make a Win16 subsystem yet though.For a Win16 subsystem you must create 16 bit DLLs - therefore you should use a 16 bit compiler.
I wish it were that simple. It has lots of complexities that confuse a lot of people.For a small - and almost incompatible - DOS16 emulation you might require a 16 bit compiler anyway for FAR CALL (16:16) emulation.
For a DPMI-only (or well known DOS extender) DOS32 emulation, it might be sufficient to use MinGW only ...
The approach that almost everybody has agreed on is V86 mode. (refer to the thread pointed to by azeemarif).
It's way too much to explain here, but the simple explanation is that even for 16-bit dos apps you only need a 32-bit container where all 16 bit calls (I/O, interrupts, memory... ) get routed to. In essence, your container (the subsystem) is entirely 32-bit, regardless of the dos app being 16-bit. V86 is simply a mechanism for bridging the gap between these two (16-bit calls get translated to 32-bit ones by the CPU, for example).
Therefore, I'm convinced that no 16-bit code would be needed. Maybe a line or two, but not any more.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.
we shall reinvent the wheel until it turns properly.
There is more than one way to skin the cat
[quote]For a Win16 subsystem you must create 16 bit DLLs - therefore you should use a 16 bit compiler. [/quote]
Wine does not and it has a Win16 subsystem. Ie the dlls can be created in anything as the long as the 16 bit code does not know that they were coded in 32 bit.
Sorry to say but mixing 16 and 32 bit compliers will just make building reactos harder just stick to 32 bit and be done. We have to move to 64 bit sometime.
Wine does not and it has a Win16 subsystem. Ie the dlls can be created in anything as the long as the 16 bit code does not know that they were coded in 32 bit.
Sorry to say but mixing 16 and 32 bit compliers will just make building reactos harder just stick to 32 bit and be done. We have to move to 64 bit sometime.
Hmmm ... I'm unsure if that is enough for real (good) 16 bit support. But when you're able to do it without writing additional 16 bit code, I'd really be happy to see it ...AcetoliNe wrote:It's way too much to explain here, but the simple explanation is that even for 16-bit dos apps you only need a 32-bit container where all 16 bit calls (I/O, interrupts, memory... ) get routed to. In essence, your container (the subsystem) is entirely 32-bit, regardless of the dos app being 16-bit. V86 is simply a mechanism for bridging the gap between these two (16-bit calls get translated to 32-bit ones by the CPU, for example).
Therefore, I'm convinced that no 16-bit code would be needed. Maybe a line or two, but not any more.
Regards,
Mark
To support 16bits dos apps alot of thing must change in reactos
example the hole kernel. reactos kernel does not allown any program talk directlly to the hardware. Complete implement 16bit pe header for dos.
and lot of other stuff need also to be change, see mobuils they are trying make a windows 95/98 version, I do not know the staus on that project, reactos are base on NT kernel. It is bad idea even runing dos software or old win16 bits program on a NT kernel.
example the hole kernel. reactos kernel does not allown any program talk directlly to the hardware. Complete implement 16bit pe header for dos.
and lot of other stuff need also to be change, see mobuils they are trying make a windows 95/98 version, I do not know the staus on that project, reactos are base on NT kernel. It is bad idea even runing dos software or old win16 bits program on a NT kernel.
I think you missed a lot of what's been discussed about this. "Well-behaved" win16 apps won't talk to hardware directly, and even if you encounter "ill-behaved" win16 apps which do try to do that, it is simple to just virtualize the hardware on top of the HAL.GreatLord wrote:To support 16bits dos apps alot of thing must change in reactos
example the hole kernel. reactos kernel does not allown any program talk directlly to the hardware. Complete implement 16bit pe header for dos.
and lot of other stuff need also to be change, see mobuils they are trying make a windows 95/98 version, I do not know the staus on that project, reactos are base on NT kernel. It is bad idea even runing dos software or old win16 bits program on a NT kernel.
This is of course necessary in all cases for DOS apps (which you would have read if you had read all the preceding talk on dos/win16 subsystems). You don't need to hack the kernel to allow directly accessing hardware, that would defeat the whole purpose of using an NT kernel in the first place.
I don't see why you keep bringing up Mobius, it is only vaguely related to ReactOS and we can do much more within the scope of our project than they can. As said in the "Win9x kernel" thread, the OS design is stupid and not worth implementing, not even for games.
We can safely create sandbox environments for DOS and Win16 apps, which won't know the difference between that and talking to real hardware. Where's the catch? Only in performance, really. So I don't really get what you're on about .
well writen windows 16 apps yes it posible geting thuse working in reactos with out any real problem. as you said about it. bad writen win 16bits no.
Reactos does not support pe dos header and it is good idea to use dosbox
in reactos, to geting dos program working.
I did only bring up mobilus it is base on dos kernel. so there all old dos or most dos program will work. and old windows 95 drivers. some hardware does only work with win95 or win3.11, for the manufactor did not write a drv for thuse. and some company in sweden can not change the hardware, for it cost to mush, but they want pay less to ms.
you must rember does company that can not change to nt,win2k, winxp, reactos or get new drv to there hardware. But they still buy windows 95 + the special hardware.
Both ReactOS and Moblius are good project. But I am beilve in reactos more that moblius. for reactos are alot better that moblius in many ways.
ReactOS are for the fututer and can know run some games. if you got lucky you can even geting the sound working more or less in reactos.
mf
I hope I was more clear why I do or did bring moblius up.
and windows 16bits apps / dos apps. why I did think it is bad idea
to runing dos apps and some old win16bits apps in reactos direcly.
Reactos does not support pe dos header and it is good idea to use dosbox
in reactos, to geting dos program working.
I did only bring up mobilus it is base on dos kernel. so there all old dos or most dos program will work. and old windows 95 drivers. some hardware does only work with win95 or win3.11, for the manufactor did not write a drv for thuse. and some company in sweden can not change the hardware, for it cost to mush, but they want pay less to ms.
you must rember does company that can not change to nt,win2k, winxp, reactos or get new drv to there hardware. But they still buy windows 95 + the special hardware.
Both ReactOS and Moblius are good project. But I am beilve in reactos more that moblius. for reactos are alot better that moblius in many ways.
ReactOS are for the fututer and can know run some games. if you got lucky you can even geting the sound working more or less in reactos.
mf
I hope I was more clear why I do or did bring moblius up.
and windows 16bits apps / dos apps. why I did think it is bad idea
to runing dos apps and some old win16bits apps in reactos direcly.
Well, it's just about writing a loader and a hugely stubbed subsystem .GreatLord wrote:Reactos does not support pe dos header and it is good idea to use dosbox
in reactos, to geting dos program working.
Nobody said we'd run them natively. Like I said in my previous post, the hardware would need to be abstracted to some generic old hardware (sb16, standard vesa compliant videocard, etc), like DOSBox does, except with the difference of running the actual cpu code natively (instead of emulating).GreatLord wrote:I hope I was more clear why I do or did bring moblius up.
and windows 16bits apps / dos apps. why I did think it is bad idea
to runing dos apps and some old win16bits apps in reactos direcly.
Just to keep my story coherent, AcetoliNe, that IS the general idea, right?
Who is online
Users browsing this forum: No registered users and 41 guests