Is there anything beyond Windows and Linux

wrote in
:

I have no idea if Linux can run off a FAT32 drive, but I'd do the same
in that situation too.

I think Linux has it;s own format.

I already posted about that. Can you see my posts?

Lostgallifreyan wrote:
"Bill in Co" wrote in news:hb2dnTqjI-
:

I think the reason
for this "anomaly" was attibrituted to incorrect use of signed integers
(which are two bytes or 16 bits wide) to store/read data in some cases.

That fits. As with the 48 bit LBA problem, the system might have several
things that need fixing. I always assumed that the shell should be
bypassed,
I just wasn't sure about the main W98 SE shell because I never used it, I
always used the W95 shell which certainly has this restriction.
Fortunately
it usually results in flat refusal to operate on the file, rather than do
so
blindly and corrupt it. The XCOPY command will handle one intact.

I don't recall any damage being done either - like you say, it was just
refusals.

I'm not sure if this was finally fixed in WinME or not (one of the shell DLL
files caused the issue, I think). I never went to WinME, although WinME
offered better USB support. But they stripped down the DOS stuff in WinME,
amongst other things. I'll stick with Win98SE and WinXP for now. :-)

"Bill in Co" wrote in
m:

I'm not sure if this was finally fixed in WinME

Nor me but I'd like to know. WME files have been used to fix things in W98
sometimes.. I think that NUSB draws files from WXP and WME, and I read that
WME has a limited set of DOS commands some pof which can improve on their W98
versions, but I can't remember details. Mostly disk formatting I think, but I
never looked into that because I'd already decided on GDISK. One thing I'd
like to do is totally remove all access to the format functions from the
Windows shell. Having 'format' right next to 'disk information' seems stupid
to me. Never mind that the format dialog defaults to exit, it should have
been harder to get at in the first place. M$ had a really weird habit of
hiding things people needed for safety and good understanding, then putting
truly dangerous tools in easy reach of misfires while reaching for purely
informational ones!

Bill in Co wrote:

I guess a W98 SE shell is ok though.

No, I seem to recall having issues with files larger than 2 GB
with some programs, too, even with Win98SE.

http://support.microsoft.com/?id=318293

=========
Windows 98 Explorer Cannot Copy Large Files

Symptoms:

When you use Windows Explorer to copy a file that has a size of 2
gigabytes (2 GB, or 2,147,483,648 bytes) or larger, the file copy
process does not work, and you receive an error message that is similar
to the following error message:

Error: Cannot create or replace "file name.xxx". The parameter is
incorrect.

Cause:

This problem can occur because of a problem in the versions of the
Shell32.dll file that are included with Windows 98 and Windows 98 Second
Edition. The root cause is a generic file operation which is used by the
shell in Windows 95/98 and Microsoft Windows NT 4.0 which interprets
values that are greater than 2 GB as negative numbers. The problem was
eliminated as part of many changes to the newer shell that comes from
Microsoft Internet Explorer 5 used by Microsoft Windows 2000 and
Microsoft Windows Millennium Edition (Me).

On Windows 98, the Shell32.dll file originates as part of Internet
Explorer version 4.0. On Windows 98 Second Edition, Shell32.dll
originates from Internet Explorer 4.01 Service Pack 2.

Workaround:

To work around this problem, copy the files by using the COPY command
from a command prompt.

Status:

Microsoft has confirmed that this is a problem in the Microsoft products
that are listed at the beginning of this article.

This problem was corrected in Windows Millennium Edition, Windows 2000,
and Windows XP.

Installing a newer version of Internet Explorer does not resolve this
problem, because later versions of Internet Explorer don't update
Shell32.dll on any platform except Windows 2000 and Windows Me.
===============

A win-98 patch was created a few years ago - COPY2GB.EXE

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

http://www.mdgx.com/files/COPY2GB.EXE

Some people usually add the Unofficial Win 9x Stack Corruption
(98KRNLUP.EXE) which installs Krnl386.exe v. 04.10.00.2000, and SHELL98
(Win 9x Explorer Lockups With IE 5.xx/6.xx update) which installs
Shell32.dll v. 4.72.3812.634.

http://www.mdgx.com/files/SHELL98.EXE
http://www.mdgx.com/files/98KRNLUP.EXE

This .2000 version is based on Windows 98/98 SE Cursor + Icon Handling
Security Vulnerability Fix (Q891711 / KB891711.EXE). This .2000 patch
of KRNL386.EXE 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.

We've discussed 98KRNLUP and SHELL98 here before (April 2011).

98 Guy wrote:
Bill in Co wrote:

I guess a W98 SE shell is ok though.

No, I seem to recall having issues with files larger than 2 GB
with some programs, too, even with Win98SE.

http://support.microsoft.com/?id=318293

=========
Windows 98 Explorer Cannot Copy Large Files

Symptoms:

When you use Windows Explorer to copy a file that has a size of 2
gigabytes (2 GB, or 2,147,483,648 bytes) or larger, the file copy
process does not work, and you receive an error message that is similar
to the following error message:

Error: Cannot create or replace "file name.xxx". The parameter is
incorrect.

Cause:

This problem can occur because of a problem in the versions of the
Shell32.dll file that are included with Windows 98 and Windows 98 Second
Edition. The root cause is a generic file operation which is used by the
shell in Windows 95/98 and Microsoft Windows NT 4.0 which interprets
values that are greater than 2 GB as negative numbers. The problem was
eliminated as part of many changes to the newer shell that comes from
Microsoft Internet Explorer 5 used by Microsoft Windows 2000 and
Microsoft Windows Millennium Edition (Me).

On Windows 98, the Shell32.dll file originates as part of Internet
Explorer version 4.0. On Windows 98 Second Edition, Shell32.dll
originates from Internet Explorer 4.01 Service Pack 2.

Workaround:

To work around this problem, copy the files by using the COPY command
from a command prompt.

Status:

Microsoft has confirmed that this is a problem in the Microsoft products
that are listed at the beginning of this article.

This problem was corrected in Windows Millennium Edition, Windows 2000,
and Windows XP.

Installing a newer version of Internet Explorer does not resolve this
problem, because later versions of Internet Explorer don't update
Shell32.dll on any platform except Windows 2000 and Windows Me.
===============

A win-98 patch was created a few years ago - COPY2GB.EXE

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

http://www.mdgx.com/files/COPY2GB.EXE

Some people usually add the Unofficial Win 9x Stack Corruption
(98KRNLUP.EXE) which installs Krnl386.exe v. 04.10.00.2000, and SHELL98
(Win 9x Explorer Lockups With IE 5.xx/6.xx update) which installs
Shell32.dll v. 4.72.3812.634.

http://www.mdgx.com/files/SHELL98.EXE
http://www.mdgx.com/files/98KRNLUP.EXE

This .2000 version is based on Windows 98/98 SE Cursor + Icon Handling
Security Vulnerability Fix (Q891711 / KB891711.EXE). This .2000 patch
of KRNL386.EXE 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.

We've discussed 98KRNLUP and SHELL98 here before (April 2011).

I vaguely recall now. But I do recall the browse DLL file fixes I used
(from IE 5.5) that eliminated that "deleting large number of files hangup"
in Windows Explorer.

I think I also tried the other mentioned suggestions back then (of replacing
shell32.dll, as I recall), but to no avail, whereas replacing the two browse
DLLs with the IE 5.5 versions - DID eliminate the problem. (This particular
bug appeared after upgrading to IE6).

Also worth upgrading was using the WinME defragger. It is much faster than
using the Win98 one.

In message , Bill in Co
writes:
wrote:
[]
Not a problem. I would not have any NTFS drives if I had my choice,
because if I cant access them from Dos, and something fails, I lose my
data.

Just to set the record straight, that's not necessarily true. There are
some utilities available that will allow you to access files on a NTFS
partition, even if you can't boot up into windows. But I'll grant you,
it's not as easy as simply booting to DOS.

snip


Some (all?) of the actual from-DOS such utilities are read-only (and
often don't do long filenames).

FWIW, I've got BartPE installed here (on this XP machine that came as
NTFS): not that it is foolproof as it assumes you can still get as far
as a boot menu. (You can make a bootable CD version too though.) It
gives me a shell that looks vaguely like Windows Explorer, from which I
can do most file operations, including in particular run at least the
..exe in a ERUNT folder if Windows won't boot. (ERUNT is an ERU clone for
NTFS systems: when I asked its author how I could use it if I couldn't
boot to get at the NTFS system, he recommended BartPE.) ERU got me out
of trouble often enough under '9x that I was very pleased to find ERUNT,
but only when that question was answered! (And I have verified that I
_can_ do a restore from it.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

A clean, neat and orderly desk is a sign of a sick mind. (G6JPG's mind is
clearly extremely healthy ...)

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
wrote:
[]
Not a problem. I would not have any NTFS drives if I had my choice,
because if I cant access them from Dos, and something fails, I lose my
data.

Just to set the record straight, that's not necessarily true. There are
some utilities available that will allow you to access files on a NTFS
partition, even if you can't boot up into windows. But I'll grant you,
it's not as easy as simply booting to DOS.

snip


Some (all?) of the actual from-DOS such utilities are read-only (and
often don't do long filenames).

Most. Admitedly, you have to look a bit harder for the ones that have
write access, too, especially if you're looking for a freebie.

But even with DOS in Win9x, if you boot up on a DOS disk or in true DOS
mode, and make changes to the files and their filenames there, you lose the
associated nice long file names you once had in windows, since DOS is
unaware of them, IIRC.

Unless you know of some utility that runs (in true DOS) and somehow avoids
that. How it could be aware of the associated long file names (running in
true DOS) I don't know, but I suppose it's possible - with some special
driver.

FWIW, I've got BartPE installed here (on this XP machine that came as
NTFS): not that it is foolproof as it assumes you can still get as far
as a boot menu. (You can make a bootable CD version too though.)

I seem to recall doing this too, but it's been so long since I even had to
play with that, I've pretty much forgotten. Because I've never had a
catastrophe on this WinXP computer that has necessated me using such (or
accessing the files below windows). I can't say the same about my Win98
computer. :-) But maybe it's because I "messed around" with that computer
a bit more in the early days.

I think it's due to two things: one, just mentioned, and two, that WinXP is
more robust and bulletproof, especially in terms of handling those old 16
bit apps and sneaky accesses to the hardware, that are pretty much blocked
or sealed off in XP. Of course, there was a price to pay for that
"protection", in terms of what would still run (or even install for that
matter) on WinXP. In fact, I can't recall the last time I had a blue screen
on this XP computer, but I had *quite* a few with the Win9x computers, and
the software I was then using.

It gives me a shell that looks vaguely like Windows Explorer, from which
I can do most file operations, including in particular run at least the
.exe in a ERUNT folder if Windows won't boot. (ERUNT is an ERU clone for
NTFS systems: when I asked its author how I could use it if I couldn't
boot to get at the NTFS system, he recommended BartPE.) ERU got me out
of trouble often enough under '9x that I was very pleased to find ERUNT,
but only when that question was answered! (And I have verified that I
_can_ do a restore from it.)

I have found ERUNT (in WinXP) very handy, on a few occasions. Using ERUNT
in WinXP is comparable to running "scanreg" and "scanreg /restore" in Win98;
it saves and/or restores the registry, and its associated files (and that's
all). I've certainly used it more often than "System Restore", but the
latter is even more "thorough" in what it can restore, if the need ever
arises. (But if it gets that bad, you'd be better off restoring from a
backup image. :-)

I don't recall using ERU in Win98. Just "scanreg /restore", when something
went amiss. Not sure what the difference is there. Or maybe using ERU in
Win98 is the same thing(?). Or, perhaps ERU was primarily for Win95?

Bill in Co wrote:

I think I also tried the other mentioned suggestions back then (of replacing
shell32.dll, as I recall), but to no avail, whereas replacing the two browse
DLLs with the IE 5.5 versions - DID eliminate the problem. (This particular
bug appeared after upgrading to IE6).

Yes.

I have Browseui.dll (version 6.00.2800.2007 xpsp2.100414-1536
10/16/2010) on my system.

Also worth upgrading was using the WinME defragger. It is much
faster than using the Win98 one.

I don't know about speed, but the Win-ME defrag files (diskmaint.dll and
scandskw.exe) have the advantage that they can handle a volume with more
clusters than the win-98 version of those files. I discovered that when
I was experimenting with running win-98 from FAT32 drives formatted with
custom cluster size, which resulted in having upwards of 40 million
clusters on a drive (and in one case, 120 million clusters on a 500 gb
hard drive formatted as a single volume with 4kb clusters).

Bill in Co wrote:

But even with DOS in Win9x, if you boot up on a DOS disk or in true
DOS mode, and make changes to the files and their filenames there,
you lose the associated nice long file names you once had in windows,
since DOS is unaware of them, IIRC.

Look up something called "DOS 7.1".

I think it includes something called LFNDOS or DOSLFN. Gives you
long-file-name functionality when booted into DOS.

The DOS files that come as part of Win-98se was never packaged by
Micro$haft as a separate, stand-alone product. Someone took those core
DOS files and added all of the missing utility programs from (I believe)
DOS 6.22 as well as a bunch of third-party shell applications and
packaged it all up into something that was called DOS 7.1.

The ideal starting point for an installation of XP would be to format a
hard drive with FAT32 using a utility that allows you to set the cluster
size. That accomplishes giving you 4kb cluster size regardless the size
of the volume you intend to install XP on. Next would be to download
the DOS 7.1 package from the web and install it on the drive. Once the
drive can boot into DOS, then install XP (but don't let it change the
file system). I did this on a netbook about 3 years ago, and in the
autoexec or config.sys I give myself the choice to boot into DOS or XP
when the system starts. If I don't make a choice within 5 seconds it
boots into XP. (I tried to install win-98 on the netbook instead of XP,
but just couldn't get it working in terms of video drivers).

I think it's due to two things: one, just mentioned, and two, that
WinXP is more robust and bulletproof, especially in terms of handling
those old 16 bit apps and sneaky accesses to the hardware,

Getting around direct hardware access in XP is easy with "Port-Talker"
(or is it Port-talk?).

One other interesting thing about XP vs Vista and 7 is that you can run
a DOS window in full-screen mode in XP, but you can't do that in Vista
or 7. By full-screen, I mean no visible window box.

"J. P. Gilliver (John)" wrote in
:

Some (all?) of the actual from-DOS such utilities are read-only (and
often don't do long filenames).


Those two things are easily combined, but getting write access to NTFS
doesn't come for free. I set up a real mode recue partition with Datalight
network stack and FTP server and client, and for NTFS I used NTSF4DOS (I
think, I later removed it), and DOSLFN for the longname read/write access.