dencorso

Thanks for looking into it and for your swift reply. You do rock!

@RLoew: Would you please be so kind as to compare Petr's Ndis.VxD 4.0.1114 with the original 4.0.1113 and give us your expert evaluation about the advantages, if any, offered by Petr's patched file? The patched file is downloadable from Petr's original post, quoted above.

Remove the installed driver in Safe Mode. Reboot. Don't let Windows reinstall the same driver, but instead use "have a disk" and point to a folder where you unzipped this driver: Via's SerialATA_V220E.zip (direct download). Reboot and set the BIOS to RAID mode. It should just work.

Norton Ghost 2003 is not free but cheap (on, say, eBay) and would do it nicely. As for LapLink, in case one has the appropriate cable, DOS Interlnk can be used almost as easily. So I think the best suggestion, in fact, would be Ghost 2003 with a LapLinked/Interlnked drive as the destination.

I usually try the QFE first. In case it works OK, I dont even bother to try the GDR.

The idea is to open the machine, just disconnect the HDD from it without actually removing the HDD and, using an el-cheapo PATA/SATA to USB converter, connect it via USB to another machine just for imaging. It's a time proven procedure that works quite well. I do that quite often.

I think that, unless LoneCrusader or someone else pinpoints the condition in which that issue happens, there is no need for screenshots, and we may attribute what he reported to a one-time quirck.

Sorry, I cannot quite reconcile both your reports... I'd understood LoneCrusader found that issue precisely on 95C... Would you both please post screenshots?

Is it maybe the issue "Windows Explorer Reports 4 GB of Files as 0 Bytes" (KB158045), or related to it? BTW, there is also the Copy2GB+ issue (this thread), mentioned in KB318293, which was tackled initially by LLXX, then eventually solved fully by the "Anonymous Patcher"... it's not clear to me whether that issue also exists in Win 95 (most probably) and whether a port of the existing patch to kernel32.dll v. 4.10.0.2225 (available renumbered as v. 4.10.0.2226) to 95 is viable and/or necessary. I consider this patched kernel32.dll a *must* for all 98SE (and the corresponding 4.90.0.3001 for ME) installations, for it unleashes the full 4 GiB capacity of FAT to 98SE (and ME), which are otherwise actually limited to 2 GiB only (although it's controversial whether the corresponding patch is really needed for ME). This particular issue is related to the implementations of _llseek and SetFilePointer. On rereading the thread I pointed to above, I've found out there is also a patched kernell32.dll for 98FE, which I had completely forgotten about. @RLoew: Thanks a lot for releasing the UDF patch as freeware! You do rock!

You should be using MSVCRT.DLL v. 6.1.9848.0, which is findable at MDGx's.

From the present thread and from hdd size limits?, I think I have enough material to create this summary of what we do know at present about the limits of the different programs related to HDD formating, partitioning and maintenance, so here it goes: The limit for NDD32.EXE (up to v. 19.0.1.8, from NSW 2008) is somewhere between 7.8 and 7.9 million clusters, or somewhere between 61.0 and 61.7 thousand sectors per FAT (as I now believe it crashes when reading the FATs to a buffer in memory). The limit for SCANDSKW.EXE (4.90.0.3000) is somewhere between 26.4 and 26.6 million clusters, or somewhere between 206.1 and 207.7 thousand sectors per FAT. It crashed with Marius '95 1 TB raid single partition (link), although 98-Guy has reported it works up to 31.2 million clusters (follow the links inside this post). SCANDISK.EXE from Win ME works, at least, up to 1 TB, according to Marius '95, and to 31.2 million clusters, according to 98-Guy (both these limits are about the same, for a 1 TB partition, using 32 kiB clusters, has about 31 million clusters). NDD.EXE for DOS (2002 ..10E) also is reported by the same users as having the same limits as those of SCANDISK.EXE, but that's now doubtful, because it crashes for wsxedcrfv with 22.9 million clusters. In any case, Marius '95, for whom it worked, said it was very slow, so maybe he just didn't wait enough time for it to crash... FORMAT.EXE works up to, at least 1018 GiB, but above 1TiB a divide error occurs, according to RLoew, in the present thread. And the limit of Petr's fixed FDISK (based on the FDISK contained in this update: KB263044, which has a numerical display bug) is 512 GB, according to Microsoft (KB280737), and confirmed in the present thread. Suitable alternatives are The Ranish Partition Manager, although it is not adequate to format the partitions it creates, because of defaulting to 16 kiB clusters, or the Free FDISK v. 1.2.1, or Symantec's GDISK (not free), or RLoew's RFDISK (not free).

Welcome to MSFN, Chris!

Great! So, now, with both your CDFS patch and your UDF addition patch it's possible to extend DVD support to 95! You do rock!

It seems 45 million clusters chokes NDD.EXE. Did you have HIMEM.SYS loaded when you ran it and SCANDISK.EXE?

Yes, there are. I'd like to know how the DOS programs SCANDISK.EXE (from Win ME or from BHDD31E) and, in case you have it, NDD.EXE (from Norton 2002) behave with your 45 million cluster 750 GB partition. After testing this, you could change the cluster size manually in the BPB of the partition boot record and try FORMAT.COM again: if RLoew is right and FORMAT.COM uses the value present in the BPB, when it finds one, this should cause it to use 32 kiB sectors.

Sorry! Well, its complicated... The MSKB still retrievable is for Win ME only (and the UDF.VxD 4.90.3001 is still available from MS), but the issue fixed by it occurs both on Win ME and in Win 98SE. There never was an MSKB article for Win 98SE, though, AFAIK, but the hotfix containing UDF.VxD 4.10.2223 can be found here. There is no corresponding hotfix for Win 98 FE, that I know of, either because it has not that issue (more probable) or because the fix was simply never made (less probable).

Wonderful! That's great news! You do rock, RLoew! BTW, which one? 4.10.1998, 4.10.2222 or 4.10.2223 (Q310695)?

Great! And yes, the Ranish PM has this strange behaviour of defaulting to 16 kiB clusters... But perhaps FORMAT.COM will change the cluster size, on reformatting. And if it doesn't, do give a try to the famous /Z switch. Well, look unser SCSI, on the device manager. You probably have an entry for yor HDD there, and in its properties you'll see the SATA driver listed. Please do run the Win ME DOS SCANDISK before and after using FORMAT.COM.

Neither I can resist: In a 4.38 GiB DVD, of which one can only use 4 GiB because of Win95 compatibility limitations, 0.38 GiB is already wasted, and surely that's enough space for both the Joliet and UDF structures.

No, it's not. And RLoew, who answered you before myself, did solve the 48-bit LBA problem before LLXX. Then he solved the RAM Limitation problem. He's one of those rare people who, single-handedly, contributed to break some of the worst barriers of Win 9x/ME. If it were feasible, belive me, he'd been working on it already.

I know. I don't want install ExFat. There is no problem with this. It's time to fix Win98Dos and Win98 and make support for use ExFat. Here lies the rub. Blue Ray movies - 6,7,8GB. You know what I mean... Let me translate what RLoew said: [short version] It's *impossible*! [long version] It's *impossible* without a *major* rewrite of the whole OS. And, in case one ever did it, after a rewrite of such magnitude it wouldn't actually even *be* Win 9x anymore. Yes. The sole thing you asked was for someone to create an installable ExFat driver. This is impossible. Then, in your next post you denied this, and instead escalated to a full system rewrite. This, while possible, is improbable and, if done, would result in a totally different OS... That said, I don't see how do you intend to continue this thread...

You asked for ideas, here above are two of them. Good luck! ...and keep us posted on your results.As you can see, there are more than one program called PECh[ec]ksum, and either of them may be viable alternatives.

Sure! I have corrected that now... thanks a lot! Now, your correction prompted me to check it at MDGx's [link], and by doing so I also got the internal file dates for Win 95 RTM, which is Jul 11, 1995. And we know from my previous post that the date of the Joliet Specification [link] is May 22, 1995. Hence Joliet, in fact, preceeds Win 95 RTM by two months. No, actually I did not. But double quotes used in this sense can be missed. So I took some time wondering whether I should reply as I did or not. In the end, I've decided for it, because I think it could help dispel any doubts created by your statements, just in case. I think your point about the burning speeds, in particular, is too important to let doubts any hanging... and a complicated one, too, in that the bus speed, the speed of the processor, the quality and speed rating of the media, and the workload of the machine at the time of burning, all play a part in the resulting success (or failure) of the procedure. No way! That you aren't, for sure! I (and many here, I'm sure) value very much your contributions for your knowledge, experience and, above all, willingness to share and help. You rock! As for the exact nature of LoneCrusader's problem, cdob summarized it quite nicely here: Windows 98 supports UDF and lists UDF names. Windows 95 dosn't support UDF and lists ISO9660 names. He was interested in getting the bootable DVD to work, so he didn't worry too much about the filesystems the mastering software suggested. Neither would I, were I in his place. Then the problem manifested. Had ImgBurn selected ISO9660 and Joliet, there would be no problem at all. But since it was a DVD, its default is to use UDF instead, which turned out to be a bad choice for Win 95. Murphy's law, as always.

Mariah Carey - I Want To Know What Love Is Rare are the occasions a cover is actually better than the original. This is one such case.

With all due respect to you, submix8c, I have to disagree with various parts of your latest post: Yes (to your edit). DVD+R is functionally equivalent to DVD-R, for all purposes, once burnt. No. The track positions are predefined in the blanks already, so changing the speed won't make them closer or more wide apart. 2.4x is a good advice solely for DVD±R DL, while, for plain DVD±R (SL) one can go up to 8x, at least, and still get good results. This is much more dependent on the user's machine actual bus speed than on any other factor, except for el-cheapo media (which can turn even the best hardware into a coaster factory). If you did so, you'd find out that: (i)The original CDFS (a.k.a. ECMA-119 [link] or ISO 9660:1988) is from 1987; (ii)The Joliet Specification [link] is of 1995; (iii)According to the Wikipedia [link]: This implies that even Win 95 supports Joliet from RTM (a.k.a Win 95A). And, in any case, LoneCrusader did all his testing with Win 95C, for which there can be no doubt about it supporting Joliet. So LoneCrusader is right! For the reasons he stated, he does need either Joliet or UDF.