DOS subsystem already dicussed in detail

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

azeemarif
Posts: 25
Joined: Fri Dec 31, 2004 8:53 am

DOS subsystem already dicussed in detail

Post by azeemarif »

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.
mjs
Posts: 47
Joined: Sat Feb 19, 2005 9:03 pm

Post by mjs »

Sorry, but it wasn't discussed in detail because the compiler wasn't specified *g*. Which compiler should be used?

Regards,
Mark
azeemarif
Posts: 25
Joined: Fri Dec 31, 2004 8:53 am

Post by azeemarif »

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.
mjs
Posts: 47
Joined: Sat Feb 19, 2005 9:03 pm

Post by mjs »

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
AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

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.
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.
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 :D
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.
mjs
Posts: 47
Joined: Sat Feb 19, 2005 9:03 pm

Post by mjs »

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 small - and almost incompatible - DOS16 emulation you might require a 16 bit compiler anyway for FAR CALL (16:16) emulation. :P

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
AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

For a Win16 subsystem you must create 16 bit DLLs - therefore you should use a 16 bit compiler.
That's correct. We're not trying to make a Win16 subsystem yet though.
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 ...
I wish it were that simple. It has lots of complexities that confuse a lot of people.
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.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

There is more than one way to skin the cat

Post by oiaohm »

[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.
azeemarif
Posts: 25
Joined: Fri Dec 31, 2004 8:53 am

Post by azeemarif »

AcetoliNe:

P.S. I've finally mostly settled down in this new city and I've gotten my new computer Very Happy
Welcome back AcetoliNe and thanks for explaining the concept to "mjs".
He seemed too stuck to his own view-point that it was hard to convince him :)
mjs
Posts: 47
Joined: Sat Feb 19, 2005 9:03 pm

Post by mjs »

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.
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 ...

Regards,
Mark
GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

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.
uniQ
Posts: 246
Joined: Sat Dec 04, 2004 8:58 am

Post by uniQ »

GreatLord wrote:It is bad idea even runing dos software or old win16 bits program on a NT kernel.
That's strange, I do it regularly with few problems.

-uniQ
Coming on, coming up, let me help ROS and I'll be able to look @ a life well used.
mf
Developer
Posts: 368
Joined: Mon Dec 27, 2004 2:37 pm
Location: Eindhoven, NL
Contact:

Post by mf »

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.
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.
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 :).
GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

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.
mf
Developer
Posts: 368
Joined: Mon Dec 27, 2004 2:37 pm
Location: Eindhoven, NL
Contact:

Post by mf »

GreatLord wrote:Reactos does not support pe dos header and it is good idea to use dosbox
in reactos, to geting dos program working.
Well, it's just about writing a loader and a hugely stubbed subsystem :lol:.
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.
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).

Just to keep my story coherent, AcetoliNe, that IS the general idea, right?
Post Reply

Who is online

Users browsing this forum: No registered users and 41 guests