SweetLow

It is possible before and (much easy to do) WHEN Windows starts. ACPI driver in Win98 supports overriding of ACPI tables through the Registry. 1. mercury did the patch to win.com to run additional software on exiting from Windows which in turn can power off PC 2. without any patch you can do the same thing just running above mentioned software in MS-DOS Mode n.b. - both questions are offtopic for this thread p.s. I edited my previous post

1. Try to access drive from other file manager - far, total comander or else. 2. Is this drive accessible on the same PC from other OS like XP? RLoew did 64-bit LBA patch for SCSI and I wrote driver for the same (USB drives are SCSI from protocol view point), but 500GB drive has to use 32-bit LBA and does not need any patch by default.

>in My Computer First check that CD-ROM drive is present in Device Manager after reboot (better in hardrware tree view mode, of course).

https://github.com/LordOfMice/Tools/blob/master/rmmremove.zip Utilities for removing "bad" DOS (RMM - Real Mode Mapper) drive letters for Windows 9x. Some analogue of "dlmanip delete" for DOS. Contents: RMMFLRM.VXD Delete phantom floppy drive letters. RMMBADRM.VXD Removal of USB drive letters processed by BIOS and visible as a duplicate under Windows 9x after Hand Off for USB controller. RMMLTRRM.VXD & RMMLTRRM.REG Remove any drive letter, including both boot and system letters (if you want to check this), not automatically, but by arbitrary list in the registry (RMMLTRRM.REG). N.B. These tools really delete drive letters, not just masking in Explorer:

I checked ReactOS image - and all is working as expected without any errors: copy and mount of image (on USB NTFS drive, on ATA NTFS drive and on ATA FAT32 drive).

>https://thestarman.pcministry.com/asm/mbr/mystery.htm >but one of our readers finally pointed out that Microsoft did provide a "partial description of the meaning [of these bytes] in KB article 192606 (or the file: MBtFAQ)." JFYI, I am this reader And I know slightly more, of course - the real IOS structure that used for passing these values (signatures and checksums). >Can you detail which cases? Excerpt from your link: >or the first word after the boot code is non-zero, IOS will instead store a checksum of the MBR and the INT 13h unit number, rather than the MBR signature. And as checksum include NT Disk Signature too -> we have unique value of this checksum. >But during setup? I don't see how this can affect setup too (as you), but NT Disk Signature has some impact on Windows 9x. P.S. And what it looks like in reality (with MBR code from NT): int13 = 80h, signature = E6FFB000h, checksum = F601BDECh, flags = 0001h int13 = 81h, signature = E6FFB000h, checksum = BDE79504h, flags = 0001h int13 = 82h, signature = E6FFB000h, checksum = E6233B84h, flags = 0001h Win9x signatures are equal, but checksums are different (and IOS is using checksums (flags = 0001h))

In some cases it is definitely used even on 9x. Not directly but in checksum of zero (MBR) sector.

Ok, could you make minimal .ISO with reproducible problem and put zipped image somewhere to download?

It is NOT the real file system driver. The real Paragon NTFS driver (UFSD.VXD or PNTFS.VXD) is located in %windir%\SYSTEM\IOSUBSYS

>I have NTFS support (Paragon) There are different Paragon NTFS drivers. If you are using UFSD.VXD then try to use PNTFS.VXD

1. I don't have such hardware. 2. It is definitely off-topic for this thread.

Ok, continuing RLoew's work: gpttsd - GPT (GUID Partition Table) TSD (Type-Specific Driver) for Win9x lba64hlp - SCSI LBA 64-bit Helper Driver for Win9x https://github.com/LordOfMice/Tools Do NOT forget to read readme - by default drivers run in the safest but not full power mode.

It simply is not true. google Realtek RTL8168 drivers for Windows 98

Not in VXD. If you have rich API then dealing with memory and files does not differ too much. But the problem with .PDR is location of code that try to touch files. It is DOS driver unlike RamDisk98 which is Windows IOS Port Driver. These are really different things.

If you will try to do this then pay attention on problem of accessing (IFSMgr) files from point where (IOS) requests serviced. There are some notes in IOS Guide about it. P.S. And I can suggest other direction of RAM Port Driver enhancement - using above 4G memory...

>Yes, that I have. But is it working as pure packet driver? Did you test it without any shims (in pure DOS) and have success (like working ping)? >I haven't had very much experience using ODI with Win9x. I'm too, but it is not hard to test. Probably i will try to do this from pure curiosity but not so fast.

No. It is shim Packet Interface -> NDIS2 Interface. But to use shim you need the lower level of shim - packet driver itself ODI is flexible enough and ethernet frame types can be restricted by ODI itself. And it is never be a problem if network protocol does not use all frame types (and IP uses exactly Ethernet_II).

Try new version of above mentioned drivers. It is definitely better (more compatible) for 98SE and will run on 98FE (tested by BolenB, logins and awkduck). And I added USB2.INF from 2007 (as original version of package disappeared from public Internet).

My friend. I think your problem is described by "EHCI Hand Off" keywords.

As usual - take WDMCHECK and check imports of all .SYS to verify that drivers really don't work rather than don't LOAD.

Yes. My friend, any .inf you are using now for USB2.0 support based on my work too

Probably yes and there is user of 98FE who used this version AFAIK but I'm not 100% sure. I personally developed it on 98SE. Never used this so IDK.

JFYI, there is version of USB drivers from post Windows XP SP1/2003 source base adapted for Win 9x...

>Maybe figure out how NTKERN.VXD works? Search for Walter Oney / Programming the Microsoft Windows Driver Model 2nd edition and source code for this book (with updates) and study how WDMSTUB works. >98 does have some WDM driver support in the form of it's NTKERN.VXD Kernel PE Loader supported since original release of Windows 95 (and was used in SCSIPORT.PDR wrapper first).

You will have BSOD on VFAT.VXD initing. All reasonable checks WAS done already ;)