SweetLow

The package for A20 Line Always On processing (and more) in HIMEM.SYS http://sweetlow.orgfree.com/download/a20alwon.zip Joint work with BolenB As usual - do NOT forget to read readme

Win9x VCACHE Protection Error Fix (.VXD version of CREGFIX.COM), primarily for Windows ME https://github.com/LordOfMice/Tools/blob/master/cregfix.zip I tested it on Windows 98SE so IDK if it actually works on Windows ME.

Yes. With this flag cleared kernel mode code is ignoring the fact that page is read-only and writes on this page successfully.

The best expirience is test it youself if you doubt. But i didn't believe in this fact too: http://forum.ru-board.com/topic.cgi?forum=62&topic=28114&start=5240#17 (translate the P.S. from this post) P.S. And i can demonstrate few other (registry) options which i found when i really need them

Ok, may be in some cases (not my case, NForce2 PCs work with ACPI flawlessly). But in any case "without ACPI" and "setup /i" are NOT the same things.

Why so? The PCs from 98-ME era are supported ACPI that is working in 98-ME, eh.

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