SFan00
Content Type
Profiles
Forums
Events
Posts posted by SFan00
-
-
INT 30 is one of two ways I have found that Windows uses to allow V86 code (16-Bit Programs and Real Mode Drivers) to call Protected Mode functions.
Of the four methods I use to enter RING 0 from 16-Bit Code in my RAMDISKs, this is the only one that does not require prior setup or kernel-mode files.
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..
0 -
Anyone here know what this 'mystery' call is, and perhaps more importantly if it's ever actually used from user code of that era?
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 .
0 -
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?
0 -
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.SYSand 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 loadsthe 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..
0 -
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
----
0 -
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 ?
0 -
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?
0 -
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)
0 -
<DELETED>
0 -
-
Hi,
been trying to track down the 98DDK which was for a while on
the MSDN site but seems to have been a casulty of the end of
Windows 9x support.
Any ideas on how to get hold of it, as it was at one point
available as a no-charge download?
0 -
<DELETED>
0 -
<deleted>
0 -
<DELETED>
0 -
<DELETED>
0 -
<DELETED>
0 -
<DELETED>
0 -
BTW Would also be nice to know if there is a location where
all the Windows98 'offical' updates are, so that I can put these
into my 98SE install from clean....
0
How to obtain the thunk compiler documentation?
in Windows 9x/ME
Posted
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