Jump to content

SFan00

Member
  • Posts

    19
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United Kingdom

Posts posted by SFan00

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

  2. 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 :).

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

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

  5. 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 :)

    ----

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

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

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

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

×
×
  • Create New...