SFan00

I'll have a look if it's included in the Win 2003 Server PSDK (February 2003) as that's the last one that claims to still support Windows 98. Link for PlatformSDK here : http://www.microsoft.com/msdownload/platfo...e/psdk-full.htm If anyone has an alternative source LMK

Hmm... So is Int30 set as a real mode interrupt or as one in 'protected' mode (i.e via a trap/intterupt gate)? At the very least it presumably locks the context for the duration of the call, and does some parameter translation before doing a linear jump? I would also assume that the return isn't a straightforward IRET as you need to switch back to a 16 bit style environment vs a 32 bit one..

Yes, several. Not usually from user code (yet, define "user code"...), not necessarily just from that era. Find and read: "Calling VxD functions from Win 16 (protected mode) code", in Matt Pietrek, "Windows 95 System Programming Secrets", chap. 6, p. 427-430 (1995); ISBN 1-56884-318-6. BTW, read also J. de Boyne Pollard's "On questions having yes/no answers". OK, thanks for the very prompt response , and reference. I'll try and get a copy because it seems a book like that might solve some other research issues I had .

Hi. In doing some research I came across something in an article I did not understand. According to RBIL ( A published list of intterupt calls for IA32) - INT 0x20 - Vxdcall ( Windows 3.x/Windows 9x) - INT 0x2E - NT syscall ( Windows NT) - INT 0x2F - Multiplexor ( Windows 3.x/ Windows 9x) There are others, however one article claims that INT 0x30 is also connected with VXD's (.386 in Windows 3.x), RIBL claims that INT 0x30 is a PM Callback in Windows 3.1, but doesn't go into any further depth.. Anyone here know what this 'mystery' call is, and perhaps more importantly if it's ever actually used from user code of that era?

This shows how rusty I am 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 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 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..

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

What version of IE do you have installed? Have you tried reinstalling it? Perhaps some graphic filters have been unregistered.... I can't think of anything else. IE 6 patched to the current version Graphics filters sounds possible Is there an unoffical patch I can run ?

Hi Wanted to check some aspect of AVI file handling against an old Borland C++ help file I had. Problem is Winhelp as it currently is in my Windows98 install , REFUSES to show any graphics instead giving a 'cryptic' "Unabel to display graphic" message. i) What is causing this problem? ii) Is there a patch for this?

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)