Jump to content

Stagg0S


SFan00

Recommended Posts

Hi,

I note that ReactOS has achived much in the field of developing an NT /XP like Operatign System which is 'compatible'

with a growing amount of software.

However, there is one block of software ReactOS won't be able to support, and that is software relying on the

older Windows ME ,98 and the prehistoric Windows 3.11x 's eccentric nature.

I would therefore likley to politely request a group of programmers interested in the 'open-source' development the following :

i) RETWOE16.DLL for ReactOS to allow the execution of New Executable type code and the support functions needed

to support the 16 bit support DLL's and modules they call

ii) An extension to the DosBox emulation engine to allow it to run Windows 3.x, Windows 9.x (initally with the presence

of a virtual install of a 'legal' copy of Windows98

iii) StaggOS - A clean room reimplementation of the VMM core of the Windows 3.11 and 9.x, on which WINE code

suitably patched could be used to provide the USER mode. (Alternative : Implement WINE for DOS4GW)

Link to comment
Share on other sites


Be cool if you could get it run ontop of DOS or something just like 9x

We've been talking that topic to death and and it does appear that contrarily to popular belief 9x doesn't run on top of DOS.

I refer you to Matt Pietrek's excellent book Windows 95 System Programming Secrets and Microsoft's own online documentation about that.

Link to comment
Share on other sites

Be cool if you could get it run ontop of DOS or something just like 9x

We've been talking that topic to death and and it does appear that contrarily to popular belief 9x doesn't run on top of DOS.

I refer you to Matt Pietrek's excellent book Windows 95 System Programming Secrets and Microsoft's own online documentation about that.

I doubt all the problems DOS has windows 9x has... THe memory mangament the dealing with higher level memory mangement etc system resources

Link to comment
Share on other sites

Be cool if you could get it run ontop of DOS or something just like 9x

We've been talking that topic to death and and it does appear that contrarily to popular belief 9x doesn't run on top of DOS.

I refer you to Matt Pietrek's excellent book Windows 95 System Programming Secrets and Microsoft's own online documentation about that.

Windows prior to version 3.0 ran over DOS

3.0/3.1 Introduced enhanced mode which is essentialy a DPMI manager and Virtual Machine ( which uses the 386 Linear

Executable for drivers, which are essentialy Ring 0 Library modules, with a defined entry point and call table.)

Thus whilst Windows 95 does indeed use DOS to boot, it does in fact have it's own internal API and system calls

other than the Win32 or Win16 API.

However, IIRC the Dos portion is mantianed in memory so that it can be supplied on request to DOS programs running in a VM.

Windows ME, still has some DOS, but it's only really a Boot Stub.

Windows XP onwards (and NT before it) are a completly different animal as they use a different boot loader

So any interest in starting to write StaggOS? I am no where near able to do this myself..

-------------

From what I can see. this is what happens (from boot) - meaning the components needing to be written are determinable.

(16 bit Real Mode code)

The Boot Sector is loaded from disc which bootstraps IO.SYS (MSDOS.SYS is a text file in 9x series systems. )

IO.SYS reads the Confing.SYS file to load REAL MODE dos drivers and setup the DOS codepages and keyboard,

it loads DRVSPACE.BIN if needed) followed by COMMAND.COM and transfers control.

COMMAND.COM loads Autoexec.BAT and executes it...

Typically the AUTOEXEC.BAT Calls WIN.COM effectivly saying the Real MODE DOS Setup is complete.

WIN.COM - Strictly speaking this should be WIN.EXE, loads and starts HIMEM.SYS, IFSMGR.SYS

and some other support code, before switching to protected mode, loading and starting the Virtual Machine Manager (in VMM32.VXD or WIN386.EXE)

The drivers specfied in the registry and in SYSTEM.INI are loaded in the appropriate order.

The KERNEL,GDI and USER Processes are started, followed by the loading of any user mode drivers (i.e DRV as opposed to 386 or VXD).

WIN.COM's final act before idling or terminating is to start and transfer control to the SHELL process which loads

the remaining portions (typically Explorer.EXE or PROGMAN.EXE) before idling..

Congratualtions you have booted :)

----

Link to comment
Share on other sites

(16 bit Real Mode code)

The Boot Sector is loaded from disc which bootstraps IO.SYS (MSDOS.SYS is a text file in 9x series systems. )

IO.SYS reads the Confing.SYS file to load REAL MODE dos drivers and setup the DOS codepages and keyboard,

it loads DRVSPACE.BIN if needed) followed by COMMAND.COM and transfers control.

COMMAND.COM loads Autoexec.BAT and executes it...

Typically the AUTOEXEC.BAT Calls WIN.COM effectivly saying the Real MODE DOS Setup is complete.

AUTOEXEC.BAT does not call for WIN.COM, this is for sure. I think IO.SYS has a way of instructing COMMAND.COM to load it or not.

WIN.COM - Strictly speaking this should be WIN.EXE, loads and starts HIMEM.SYS, IFSMGR.SYS

and some other support code, before switching to protected mode, loading and starting the Virtual Machine Manager (in VMM32.VXD or WIN386.EXE)

HIMEM.SYS, IFSMGR.SYS and SETVER.COM are loaded automatically by IO.SYS, after loading everything in CONFIG.SYS, if it isn't loaded already.

The drivers specfied in the registry and in SYSTEM.INI are loaded in the appropriate order.

The KERNEL,GDI and USER Processes are started, followed by the loading of any user mode drivers (i.e DRV as opposed to 386 or VXD).

DRVs are user-mode drivers? AFAIK, they are WDM ones, and not necessarily user mode, but I can be wrong.

WIN.COM's final act before idling or terminating is to start and transfer control to the SHELL process which loads

the remaining portions (typically Explorer.EXE or PROGMAN.EXE) before idling..

Congratualtions you have booted :)

AFAIK, WIN.COM's role is done ages ago... as soon as the protected mode kernel is loaded, I think.

Link to comment
Share on other sites

This shows how rusty I am :(

(16 bit Real Mode code)

The Boot Sector is loaded from disc which bootstraps IO.SYS (MSDOS.SYS is a text file in 9x series systems. )

IO.SYS reads the Confing.SYS file to load REAL MODE dos drivers and setup the DOS codepages and keyboard,

it loads DRVSPACE.BIN if needed) followed by COMMAND.COM and transfers control.

COMMAND.COM loads Autoexec.BAT and executes it...

Typically the AUTOEXEC.BAT Calls WIN.COM effectivly saying the Real MODE DOS Setup is complete.

AUTOEXEC.BAT does not call for WIN.COM, this is for sure. I think IO.SYS has a way of instructing COMMAND.COM to load it or not.
WIN.COM - Strictly speaking this should be WIN.EXE, loads and starts HIMEM.SYS, IFSMGR.SYS

and some other support code, before switching to protected mode, loading and starting the Virtual Machine Manager (in VMM32.VXD or WIN386.EXE)

HIMEM.SYS, IFSMGR.SYS and SETVER.COM are loaded automatically by IO.SYS, after loading everything in CONFIG.SYS, if it isn't loaded already.

HMM, I've seen installs which have explict HIMIEM.SYS loads, as well as sometimes loading EMM386.EXE as well

especially on Win 3.X installs.... Not sure if IFSMGR.SYS loads on stuff pre 1995. NOTE .SYS here means DOS

.SYS, NOT 32-bit WDM drivers that are 32 bit PE format.

Right, so that means I can't just use the Freedos IO.SYS+MSDOS.SYS hmm...

Is there an open source replacement that can be patched to load an equivilant...

I am asusming that what IFSMGR.SYS does is provide some REAL MODE side services to IFSMGR.VXD later on?

Where if present (does DRVSPACE/DBLSPACE.BIN) get loaded? IO.SYS

The drivers specfied in the registry and in SYSTEM.INI are loaded in the appropriate order.

The KERNEL,GDI and USER Processes are started, followed by the loading of any user mode drivers (i.e DRV as opposed to 386 or VXD).

DRVs are user-mode drivers? AFAIK, they are WDM ones, and not necessarily user mode, but I can be wrong.

DRV are in effect DLL, and thus use a DriverProc entry IIRC, (A Lot of these are 16 bit in Windows 95/98 one exception IIRC being Winspool.DRV-Which manages printing to local ports)

WDM drivers are based on the NT style of access and are ussaly in System32 with a .SYS extension I know it's

confusing.

.386 drivers are LE type 'Virtual Devices' for Windows 3.x

.VXD are the Virtual Devices for Windows 95/98/ME with the exception of VMM32.VXD which is a rather special

peice of coding :(

WIN.COM's final act before idling or terminating is to start and transfer control to the SHELL process which loads

the remaining portions (typically Explorer.EXE or PROGMAN.EXE) before idling..

Congratualtions you have booted :)

AFAIK, WIN.COM's role is done ages ago... as soon as the protected mode kernel is loaded, I think.

Hmm, As in as soon as VMM gets control? KRNL386.EXE is 16 bit code, KERNEL32.DLL is 32 bit... Which is loaded?

OK...

Can you explain in more detial?

StaggOS's reference compiler was planned to be OpenWatcom as it's about the only 'open source' compiler

that can handle LE/LX, It's not ideal because as I understood it there was some Visual /MASM specfics in

the 98/ME DDK..

Edited by SFan00
Link to comment
Share on other sites

I'm not sure I can give you more details... I'm not an expert

AUTOEXEC.BAT does not call for WIN.COM, this is for sure. I think IO.SYS has a way of instructing COMMAND.COM to load it or not.

My bad, this is only for Windows 95 and upwards. Windows 3.11 gets loaded either in AUTOEXEC.BAT or manually by the user.

HMM, I've seen installs which have explict HIMIEM.SYS loads, as well as sometimes loading EMM386.EXE as well

especially on Win 3.X installs.... Not sure if IFSMGR.SYS loads on stuff pre 1995. NOTE .SYS here means DOS

.SYS, NOT 32-bit WDM drivers that are 32 bit PE format.

I think IFSMGR.SYS needs to be loaded for Windows for Workgroups 3.11, and needs to be explicitly in CONFIG.SYS. IO.SYS from MS-DOS 7.0 (Windows 95) and newer loads it automatically if it isn't loaded in CONFIG.SYS. Note that HIMEM.SYS also needs to be there in pre-Windows 95 systems, since it will not be loaded automatically either.

Right, so that means I can't just use the Freedos IO.SYS+MSDOS.SYS hmm...

Is there an open source replacement that can be patched to load an equivilant...

I am asusming that what IFSMGR.SYS does is provide some REAL MODE side services to IFSMGR.VXD later on?

Loading IFSMGR.SYS per se is the least of your problems, since you can just load it in CONFIG.SYS, if necessary. Windows uses undocumented DOS stuff only present in MS-DOS 7.0 and up.

Where if present (does DRVSPACE/DBLSPACE.BIN) get loaded? IO.SYS

AFAIK, yes, even before CONFIG.SYS, I guess. But only if DrvSpace/DblSpace are enabled in MSDOS.SYS, I think. Either way, it is not essential. No one should be using these nowadays, specially because floppies compressed with DriveSpace won't be readable on anyting other than Win9x-ME.

DRV are in effect DLL, and thus use a DriverProc entry IIRC, (A Lot of these are 16 bit in Windows 95/98 one exception IIRC being Winspool.DRV-Which manages printing to local ports)

WDM drivers are based on the NT style of access and are ussaly in System32 with a .SYS extension I know it's

confusing.

Oops, my bad... horrible mistake.

Hmm, As in as soon as VMM gets control? KRNL386.EXE is 16 bit code, KERNEL32.DLL is 32 bit... Which is loaded?

OK...

Can you explain in more detial?

No idea... the only thing I know is that in Windows 3.11 you could go to Windows system directory and start WDOSX.EXE directly and enter Windows in standard mode, only that there would be no support for running DOS apps, because that needed another program WIN.COM loaded before loading WDOSX.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...