Has anyone thought of ever making a DOS-based OS, which switches to protected mode when it starts up automatically after DOS? I know that's how the Windows 9x/ME line worked.

The reason I'm asking is that some Windows 9x apps might not work correctly on Windows XP, and I was thinking it would be cool to work on a Windows 9x clone of sorts. I know that there's a group doing that for XP and NT based machines with ReactOS, but for this nothing has been done that I'm aware of.

Any ideas?

P.S. - Sorry if this is in the wrong forum, but I saw the DOS dead for some time and figured this would be a good way to "revive" it.

You'd perhaps start from some True DPMI host - since Win9x was also based on it.
That means starting up from just a bare DOS extender project (something I once was doing).

rhyno_dagreat: Looks like a nice idea rhyno_dagreat! I know nothing about OS creation, but I could take some time to learn and help the project.

BTW... is ReactOS already usable? We really need a XP substitute too if Vista becomes too much used.

ReactOS is currently in an alpha state, version 0.3.3. Many programs already work well under it. Still, I'd wait until a stable version came out (or at least a beta that's pretty stable) before using ROS on a non-test PC (don't know how stable ROS currently is or that much about it, for that matter).

Actually, ReactOS began as FreeWin95 and later changed its target to NT. So early development of ROS would be like something you described above, but before 1997, when they changed to NT, they didn't release any software, so there is not code from that.

There was another clone of windows 95 attempted, called Freedows (see http://en.wikipedia.org/wiki/Freedows_OS), but it was suspended in 2002. Don't know if they released any running code.

DexOS can be run from MS-Dos, all you do is run kernel32 exe from Dos (not a windows dos), you can even go back to dos to run dos programs or exit to dos.
If you stick kernel32 into dos's autoexe.bat, it will go from dos to DexOS on bootup.

It also a easy way to run DexOS from a hdd drive, just put a dos partion formated to fat16 and you can run DexOS from hdd.

rhyno_dagreat wrote:

> The reason I'm asking is that some Windows 9x apps might not work
> correctly on Windows XP

And Vi$ta/XP apps no longer work on ME/98SSE/NT4

> and I was thinking it would be cool to work on a Windows 9x clone of sorts.

Maybe HX-DOS Extender ?

It's DOS-based unlike ME/NT crap ...

> for some time and figured this would be a good way to "revive" it

yeah

"dexos" is a good start i think.
but need a no-name dos based os i suppose.
something like "dos"
a generic basis for asm/else development, easy to install, very very easy to install and mega easy to install and use?
cause os is not a goal, it's a tool

Ya, I've been working on a floppy disk format program for DexOS. Right now it formats floppies from MS-Dos DR-Dos or FreeDos. It can format a floppy as a DexOS boot disk. It works, but is a bit big and sloppy right now. I also at some point need to replace the bios calls with code, so it will also work under some flavors of Windows and under DexOS I should have something, not to ugly, that I can post for download in about a week, weather and work permitting

.

> I also at some point need to replace the bios calls with code,
> so it will also work under some flavors of Windows and under DexOS

DexOS = Windows ?

Anyway, BIOS is good under DOS (directly) and DexOS (need switch to RM). I have no clue what code you have in mind working under some (64-bit ? UNT-based ?) flavors of

DexOS is a 32bit DOS http://www.dex4u.com/ . It supports a few functions, most of the dos command line functions and loads / runs programs from the command line like old 16 bit dos's did, except it's 32 bit (so it doesn't run old dos programs).

I need to write code that does what some of the bios calls do, because Windows gets picky about letting you use some of those calls directly. To run the program under DexOS I need to change the over all program to 32 bit and write 32 bit code to do what the 16 bit code in the bios does, since jumping back and forth between 16 bit and 32 bit is a pain and slower. I guess another option would be to drop into 16 bit mode at the start of the program and jump back to 32 bit on exiting back to DexOS, that way the dos and dex ver are nearly the same. So the code I'm talking about is basically just doing what the bios would have done if I had been able to call it, like I do in the Dos ver.

What do you mean? If you're talking about running stuff under NTVDM, using in/out commands instead of BIOS won't help, as it to is emulated (NT doesn't let you do sector access to HD using int 13h, and I don't think it will let you using ports either). You must understand that is an app uses in/out in NTVDM (or DOSemu, or any other vm86 mode DOS emulator), the hardware access does not happen directly, rather, it is trapped by the OS, which then decides if to allow it, emulate it, do nothing, or display an error and exit. If you're talking about Win32 apps, you can't use BIOS, you have to use Win32 API.

Yes, you can't use bios under windows. Yes under the NT branch of windows you can't get at the hardware with out writing drivers that basically become part of the OS. As far as I know the other flavors of windows will let you play with the ports directly, that's what I plan to do or at least try and do. No interest in trying to write drivers for the NT branch of windows, so it will only work on the older flavors of windows, if it works at all I know, not going through windows isn't playing nice and windows can bite you some times when you don't play nice.....

True, but there are drivers (like giveio.sys and UserPort) that you can download off the internet that allow user-mode processes I/O port access.

roboman wrote:

> I know the other flavors of windows will let you play with the ports
> directly, that's what I plan to do or at least try and do.

Very limited and not useful.

System86 wrote:

> True, but there are drivers (like giveio.sys and UserPort) that you can
> download off the internet that allow user-mode processes I/O port access.

Maybe true ... but this doesn't fix roboman's missassumption that he has same problems under DexOS and "Windows" ... BTW, DexOS apps won't run in ANY "flavor"

I guess I wasn't clear. The assumption was that both DexOS and Windows don't let a person directly use the system bios. Given that assumption, any dos programs needing to be translated from dos will need to not only be changed over to 32 bit, they will also need to have any bios calls taken care of by the program itself. Probably vastly different answers required, but looks like the same basic problem. And yes I'm very aware that dexos aps only run in dexos, dos aps run in dos and once in a while in windows, linux aps mostly only run in linux, and windows aps only sometimes work in windows, never in dos, never in dexos and only when you are lucky in wine.
Thanks for the heads up on the port drivers.

Use Win32 API for Windows. For DexOS, here is the function table, and a tutorial is here.

DOS386 I do not know why you post, you never help, you post in riddles.
You think the only good thing in the world is that buggy freedos.
Why do you wast your time posting S**T, instead why not code something, if you can.
Or F***OFF and play with your buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
buggy freedos.
bugs life sponsored by FreeDos.

haha, Dex exploded He contributed code recently if I remember right (the GetDiskFreeSpaceEx?).

But yes DOS386, you often post very brief responses that looks like riddles, please be free to express yourself with many words as necessary, no need to keep 640 KB limitation

NOT true. And, even worse, you exploded on a false positive

My statement was NOT a complaint against DexOS, I consider it as feature, not as bug, or, at least, I would consider it a feature if you were less rude and DexOS was an option for me then



Oh thanks



This is definitely a desperately rude and disgraceful statement ... at least, I had contributed 2 patches to DexOS kernel ... before you became rude



COOL. 22 times the same stupid claim, you could have also increased text size or quality of the colour (e.g. RED) ...

You know, DexOS is 32-bit, written in FASM, ... but it is immature, incomplete and desperately buggy ... so you can work on making it better, or you can continue with stupid attacks against "buggy FreeDOS", if you think to attract more users and developers to DexOS this way.

YES, FreeDOS has some bugs left, but it has complete file I/O (DexOS hasn't), supports subdirectories (DexOS doesn't), has some HL compilers (DexOS has none) ... said one time, I have no need to repeat myself for no reason

Make DexOS better or try to make FreeDOS bad ... it's your choice

First, because something does not run in the same way has Dos, does not mean its buggy, unless its a Dos clone (which is why freedos is buggy).
Second anything that runs fine on Ms Dos, but not on FreeDos, say to me that freedos is buggy, as it should emulate MS-Dos.

Also all of the things you say are not in DexOS are, so it shows what you know.

Why do you wast your time saying bad thing about other OS, when FreeDos as so many bugs to fix.
So remember, freeDos is Dead and get over it