[jds]

FYI.

Well, here's a new one (well, I don't recall reading about this anywhere before).

I was investigating reliability of high-capacity Flash drives (I've experienced some occasional problems on my Medion USB stick where an 8K chunk within a file is junk; no errors reported when writing or later, when reading such files) and had copied a large ISO image [edit: I forgot to mention, it exceeded 2G] to my hard drive via Windows Explorer. This is on a W98SE system with the 2G Copy patch applied.

I then tried to run Charles Dye's CHKSUM utility to verify the file from it's CRC32 value. This reported "--------" for the CRC32 and "0005" for the XDIR checksum, and said that 1 error had been encountered while reading the file. Strange. What did this all mean?

Well, what it meant was that Runtime Error 5 (Access Denied) had been encountered when attempting to read the file. Yet, I had run the same CHKSUM utility on a Vista machine with the same file and it had worked OK there. So, the CHKSUM utility itself wasn't the problem.

I then tried other 16 bit applications to access the file in question, and all of them failed with Runtime Error 5 or Access Denied. Even trying the internal "copy" and "type" commands produced the same result.

Finally, I tried the same thing in pure DOS mode. Using MS-DOS 7.10, the same problem occurred. Using FreeDOS 1.0 (using the installation CD as a Live CD), no such problem.

So it seems there's a 2G file size problem in MS-DOS 7.10, which also seems to affect (or perhaps it's yet a separate problem?) all 16 bit applications running under W98SE.

Joe.

[dencorso]

Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

dencorso, on 21 November 2010 - 01:47 PM, said:

jds, on 20 November 2010 - 12:08 AM, said:

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

MDGx, on 02 October 2010 - 02:27 AM, said:

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:
http://www.mdgx.com/xptoy.htm#CRC

[rloew]

dencorso, on 06 December 2010 - 05:32 PM, said:

Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

dencorso, on 21 November 2010 - 01:47 PM, said:

jds, on 20 November 2010 - 12:08 AM, said:

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

MDGx, on 02 October 2010 - 02:27 AM, said:

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:
http://www.mdgx.com/xptoy.htm#CRC

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.
It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

[jds]

dencorso, on 06 December 2010 - 05:32 PM, said:

Did the problem manifest itself in Win98SE, despite the presence of the patches listed in the quote below?

dencorso, on 21 November 2010 - 01:47 PM, said:

jds, on 20 November 2010 - 12:08 AM, said:

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

That's right, those patches are installed (except for 98KRNLUP, since my DLL's seem newer than this). I can copy the file via Windows Explorer and I can open it with HashCalc (SlavaSoft), but any 16 bit application, including COMMAND.COM (eg. 'copy' and 'type') seems to fail.

Quote

Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file?

MDGx, on 02 October 2010 - 02:27 AM, said:

* CRC/MD5/SHA file (PE) checksum tools that work with 9x OSes [free(ware)]:
http://www.mdgx.com/xptoy.htm#CRC

OK, downloaded these MS utilities and they work fine. However, these are 32 bit applications, so these go via the standard Windows functions that have the 2G patch, so that's to be expected.

I tried to induce CRC.EXE to work in pure DOS with the help of the HX Extender, but no luck. They really don't want to work at all in DOS, do you know a way? (Similarly for FCIV.EXE, although I didn't bother trying HX with that.)

BTW, don't forget that the 16 bit CHKSUM utility I use (sort of as a replacement for XDIR;-) worked with that large ISO image under FreeDOS (also under Vista), so the utility itself is fine.

rloew, on 06 December 2010 - 11:34 PM, said:

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.
It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

OK, I tried this and it didn't make a difference. Not surprising, since none of the things I tried would have had any reason to Seek other than from the beginning.

BTW, note that your patched DLL is build 4.10.2225, whereas the version I was using was 4.10.2226. (No idea what that extra build stepping gives.)

Joe.

[PROBLEMCHYLD]

jds, on 08 December 2010 - 02:06 AM, said:

[except for 98KRNLUP, since my DLL's seem newer than this).

And, what version do you have? Can you share it with us?

[Tripredacus]

This is interesting, I never really thought about it. I used to maintain USB keys that booted and allowed for BIOS updates and using Ghost clients. Originally we used the Win98 bootfiles that is in every version of Windows format tool since 98, but had to go to DOS 7.1 in order for certain NDIS drivers to load properly. We didn't run into any problems with creating these keys until we tried 4GB and 8GB keys. All the normal ones were 1GB keys and they always worked fine. Now it seems that USB Keys under 4GB are becoming a rarity.

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

[whatever420]

rloew, on 06 December 2010 - 11:34 PM, said:

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.
It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Hi rloew...

I think there may be a bug in your KERNEL32 2GiB Bug Fix Patch...

Yesterday, I updated the old COPY2GB KERNEL32.DLL to your version...

When I went to use VideoReDo Plus (a video editing app), it kept crashing with an error involving msvcr80.dll...

Using Dependency Walker, it showed that msvcr80.dll is linked to KERNEL32.DLL...

I switched back to the old COPY2GB KERNEL32.DLL and after a reboot, VideoReDo Plus ran fine...

Just thought I'd let you know...

[rloew]

jds, on 08 December 2010 - 02:06 AM, said:

OK, I tried this and it didn't make a difference. Not surprising, since none of the things I tried would have had any reason to Seek other than from the beginning.

BTW, note that your patched DLL is build 4.10.2225, whereas the version I was using was 4.10.2226. (No idea what that extra build stepping gives.)

Joe.

I don't know what applications use the other Seek Modes other than some of mine but there probably are some.

The underlying DLL is the same. The Author of COPY2GB bumped up the Version Number.

[dencorso]

RLoew is right, of course. The COPY2GB patched kernel32.dll v. 4.10.0.2226 is based on Microsoft's hotfix kernel32.dll v. 4.10.0.2225 (from KB320798).
Both LLXX and the anonymous patcher have produced patches derived from kernel32.dll v. 4.10.0.2225, just as RLoew did now. For the record, here's a link to the original thread this matter was discussed in. Thank you, RLoew, for looking into this matter. You do rock!

Tripredacus, on 08 December 2010 - 11:11 AM, said:

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

No. That's not the case. I do have three 8 GiB, one 16 GiB and one 32 GiB pendrives and one 16 GiB plus two 32 GiB SDHC cards, and all of them boot perfectly with DOS 7.10 our DOS 8.0. One of the 8 GiB pendrives is an OCZ ATV Turbo, while all the others are Corsair Voyager (normal or GT) and the SDHC cards are SanDisk Extreme III (class 6 or 10), in case that may be relevant.

[rloew]

whatever420, on 08 December 2010 - 03:47 PM, said:

rloew, on 06 December 2010 - 11:34 PM, said:

I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File.
It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Hi rloew...

I think there may be a bug in your KERNEL32 2GiB Bug Fix Patch...

Yesterday, I updated the old COPY2GB KERNEL32.DLL to your version...

When I went to use VideoReDo Plus (a video editing app), it kept crashing with an error involving msvcr80.dll...

Using Dependency Walker, it showed that msvcr80.dll is linked to KERNEL32.DLL...

I switched back to the old COPY2GB KERNEL32.DLL and after a reboot, VideoReDo Plus ran fine...

Just thought I'd let you know...

Try Downloading it and testing it again. I have updated it.
If it still doesn't work please post some more details on the errors.

[jds]

PROBLEMCHYLD, on 08 December 2010 - 09:43 AM, said:

jds, on 08 December 2010 - 02:06 AM, said:

[except for 98KRNLUP, since my DLL's seem newer than this).

And, what version do you have? Can you share it with us?

On closer inspection ... the dates are newer, but the files are the same - except for 'advpack.dll' which is 6.00.2900.2180 (rather than 5.00.2013.1301).

Tripredacus, on 08 December 2010 - 11:11 AM, said:

This is interesting, I never really thought about it. I used to maintain USB keys that booted and allowed for BIOS updates and using Ghost clients. Originally we used the Win98 bootfiles that is in every version of Windows format tool since 98, but had to go to DOS 7.1 in order for certain NDIS drivers to load properly. We didn't run into any problems with creating these keys until we tried 4GB and 8GB keys. All the normal ones were 1GB keys and they always worked fine. Now it seems that USB Keys under 4GB are becoming a rarity.

I never put 2 and 2 together and figured out why the 4GB+ USB Keys wouldn't boot into DOS 7.1 until I read this. If 1 and 2GB Keys end up going the way of the Altair, do you suppose there could be a way to fix this, at least for DOS 7.1?

No, there's no problem using the Panasonic + Various (eg. Adaptec) combination drivers for DOS, with USB drive partitions up to 64G. The issue here relates to individual files in the 2G-4G size range. BTW as you no doubt know, Ghost will split its image files so they don't exceed 2G [edit: I got that wrong, the split is just under 4G; I think Ghost works at a lower level and hence avoids this 2G bug].

rloew, on 08 December 2010 - 04:30 PM, said:

The underlying DLL is the same. The Author of COPY2GB bumped up the Version Number.

Cool. Thanks for the clarification and thanks for the patch, Mr. Loew.

dencorso, on 08 December 2010 - 06:05 PM, said:

Both LLXX and the anonymous patcher have produced patches derived from kernel32.dll v. 4.10.0.2225, just as RLoew did now.

Sigh! I miss her.

Joe.

This post has been edited by jds: 14 December 2010 - 07:55 PM

[whatever420]

rloew, on 08 December 2010 - 11:50 PM, said:

Try Downloading it and testing it again. I have updated it.
If it still doesn't work please post some more details on the errors.

Sorry rloew... I'm still experiencing the same crash .

See the attached file for a basic picture of the crash message and a Dr. Watson crash log...

Attached File(s)

•  kern_crash.7z (70.09K)
  Number of downloads: 6

[rloew]

whatever420, on 10 December 2010 - 05:07 PM, said:

rloew, on 08 December 2010 - 11:50 PM, said:

Try Downloading it and testing it again. I have updated it.
If it still doesn't work please post some more details on the errors.

Sorry rloew... I'm still experiencing the same crash .

See the attached file for a basic picture of the crash message and a Dr. Watson crash log...

Try this experimental file.

[MDGx]

wsxedcrfv, on 11 December 2010 - 09:00 AM, said:

> While not mandatory, I usually add the Unofficial Win 9x Stack Corruption (98KRNLUP.EXE)
> which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Just a quick question. What's the source of 98KRNLUP.exe (Krnl386.exe V .2000) ?

Microsoft?

This is the text file that pops up whenever one installs 98KRNLUP.EXE:

Quote

Unofficial Windows 98/98 SP1/98 SE KRNL386.EXE 4.10.2000 Fix

EXTREMELY IMPORTANT:
You MUST REBOOT at END of INSTALL to complete properly!
Do NOT install MORE THAN ONCE WITHOUT REBOOTING AFTER FIRST INSTALL!

Everything here applies only to English editions.

This fix/update is cumulative. This means it includes ALL BUG fixes from all previous official + unofficial patches/(hot)fixes/updates. Do NOT replace with ANY other older file version(s) UNLESS having problems with current file version(s).

NOTE:
Provided 'as is', without any warranties, expressed or implied.
Use at your own risk!

INSTALL:
This Fix installs KRNL386.EXE 4.10.2000 into %windir%\SYSTEM [%windir% = usually C:\WINDOWS].

MORE INFO:
KRNL386.EXE 4.10.2000 prevents a rare, but then very often fatal case of stack corruption when certain KERNEL APIs are called.
The only connection to KB891711/Q891711/U891711 is that these 16-bit binaries call at least one of those KERNEL APIs. However, many of the serious problems people reported with KB891711.EXE 4.10.2222 were most likely caused by a buffer overflow condition on the 16-bit stack of KB891711.EXE.
The problems that still occured with KB891711.EXE 4.10.2223 but were much, much less common, were most likely caused by the stack corruption bug in KRNL386.EXE.

This fix was created by an anonymous author, based on the official file from MS.
All I did was to create the IExpress installer, and made up the text file.

HTH

[whatever420]

rloew, on 11 December 2010 - 12:51 AM, said:

Try this experimental file.

Well rloew, I have bad news and good news...

The bad news is... my internet connection stinks...

The good news is... I had no crash when starting VideoReDo Plus .

Keep up the great work!

[rloew]

whatever420, on 12 December 2010 - 05:28 PM, said:

rloew, on 11 December 2010 - 12:51 AM, said:

Try this experimental file.

Well rloew, I have bad news and good news...

The bad news is... my internet connection stinks...

The good news is... I had no crash when starting VideoReDo Plus .

Keep up the great work!

Correction: Bad news and bad news.

Apparently VideoReDo is not compatable with the function extensions I added. The experimental file I posted has my code in it but disabled the function extensions. VideoReDo probably attempts to do a relative seek to a point before the beginning of a file, expecting it to fail. With my extensions, a 32-Bit Seek before the start of a file is now treated as a Seek to a point nearly 4GiB after and does not fail. Unfortunately there is no way to distinguish between these situations without limiting the ability to handle files up to 4GiB. I don't know if it is VideoReDo or MSVCR80 that needs fixing. I don't have either one.

I noticed that a number of people downloaded the Experimental File I posted. It was intended as a test only and the Patch is non-functional. Only the current file on my Website is functional.

[dencorso]

No. It's an original mod by the anonymous patcher, based on his own reverse engineering of the Krnl386.exe V .1999 (which is by MS and has a KB).
Later, when I get home I'll post you the kb number.
But the anonymous patcher, just like LLXX and RLoew, is a quite trustworthy source, although his documentations are scanty. What worries you?

[whatever420]

rloew, on 13 December 2010 - 12:57 AM, said:

Correction: Bad news and bad news...
...The experimental file I posted has my code in it but I disabled the function extensions...

Awwwwwww RATS!

and I would have gotten away with it too... if it hadn't been for those pesky KIDS!

This post has been edited by whatever420: 13 December 2010 - 04:58 PM