Windows 98 and the 4gb file-size limitation

[Glenn9999]

I don't have any BluRay hardware, but files/content > 4G are nothing new, they also exist on DVD. In the case of DVD, the content is represented in chunks of just under 2G each, and you can copy and play these (*.VOB) files seamlessly with software such as VLC.

Actually this is part of the DVD spec. The files are 1GB a piece, maximum, and are split up into different sections if there is more than one movie. There is nothing special regarding these files from a file allocation perspective. They are individual files with varying sizes and not part of one cohesive unit.

The fact still remains no matter how much people want to dance around it. FAT32 does not support > 4GB and neither does 98.

[jds]

I'm not quite sure I know what you're talking about. All the VOB files I've ever seen on a DVD are exactly 1gb in size. I've never seen them larger than 1 gb, and certainly not more than 4 gb.

I think the answer is very simple: If your file is a movie file (and most likely it is) then convert it to MKV and then use winrar to break it up into smaller pieces (any size you want that is 4 gb or smaller) but tell winrar to use "storage mode" - no compression. VLC will play the file(s) no problem.

Actually this is part of the DVD spec. The files are 1GB a piece, maximum, and are split up into different sections if there is more than one movie. There is nothing special regarding these files from a file allocation perspective. They are individual files with varying sizes and not part of one cohesive unit.

The fact still remains no matter how much people want to dance around it. FAT32 does not support > 4GB and neither does 98.

AFAIK, the maximum size of VOB files on DVD is just under 2G, although the normal practice is for them to be just under 1G.

However, that's not the point. The point is that DVD can already exceed the 4G content barrier and has this scheme of handling such content, with file sizes that are suitable for many O/S including W9X. So :

(1) Does BluRay use a monolithic file for content, or does (can) it support the same scheme as DVD?

(2) If BluRay content is monolithic, why not have an application/utility that translates this content into the "DVD-style" multiple-VOB-file content that can be readily handled and is already supported? Perhaps some existing DVD-copying/ISO-burning software can already do this?

Joe.

[Joseph_sw]

yeah from http://en.wikipedia.org/wiki/Fat32#Directory_table , there not much reserved bytes remain in Directory table to accomdate size > 4 GB

i'm looking at you, useless 6 bytes - last access date/time fields (and 1 byte create time fine resolution).

[Guest wsxedcrfv]

The fact still remains no matter how much people want to dance around it. FAT32 does not support > 4GB and neither does 98.

The fact remains that there is nothing fundamental about the way clusters are chained under FAT32 that limits files to 4 gb. It's only the relatively trivial fact that there are only 4 bytes specified for the file size in the file table that is the limiting factor. Programs like winrar and vlc must obviously have their own internal file-pointers that are larger than 4 bytes, and those programs don't seem to have any problem interacting with win-98's file I/O functions.

yeah from http://en.wikipedia.org/wiki/Fat32#Directory_table , there not much reserved bytes remain in Directory table to accomdate size > 4 GB

i'm looking at you, useless 6 bytes - last access date/time fields (and 1 byte create time fine resolution).

I don't know why someone didn't take the FAT32 filespec and find *ONE* extra byte somewhere in the file table entries to use as the 5'th byte of the file-size parameter. Having 40 bits to code the file-size (instead of 32) would have allowed for a file-size up to 1tb. They could have called it "FAT40", and by and large it would have been 100% backwards compatible with FAT32.

[erpdude8]

[

I don't know why someone didn't take the FAT32 filespec and find *ONE* extra byte somewhere in the file table entries to use as the 5'th byte of the file-size parameter. Having 40 bits to code the file-size (instead of 32) would have allowed for a file-size up to 1tb. They could have called it "FAT40", and by and large it would have been 100% backwards compatible with FAT32.

but then again, who's gonna actuallly implement a so-called "FAT40" file system into a win9x system?

not a simple thing to do.

[Glenn9999]

but then again, who's gonna actuallly implement a so-called "FAT40" file system into a win9x system?

not a simple thing to do.

And actually impossible because Microsoft isn't open sourcing the win9x source, and therefore no one generally knows how things are linked in all the code or the programs. So all would need reviewed. And you'd still break programs because some programs link the libraries into their program (e.g. Kernel32.lib) and don't call the DLLs.

[rloew]

but then again, who's gonna actuallly implement a so-called "FAT40" file system into a win9x system?

not a simple thing to do.

And actually impossible because Microsoft isn't open sourcing the win9x source, and therefore no one generally knows how things are linked in all the code or the programs. So all would need reviewed. And you'd still break programs because some programs link the libraries into their program (e.g. Kernel32.lib) and don't call the DLLs.

KERNEL32.LIB is an Interface to KERNEL32.DLL, not a replacement, so Programs using KERNEL32.LIB would not be affected differently.

[rloew]

The fact still remains no matter how much people want to dance around it. FAT32 does not support > 4GB and neither does 98.

The fact remains that there is nothing fundamental about the way clusters are chained under FAT32 that limits files to 4 gb. It's only the relatively trivial fact that there are only 4 bytes specified for the file size in the file table that is the limiting factor. Programs like winrar and vlc must obviously have their own internal file-pointers that are larger than 4 bytes, and those programs don't seem to have any problem interacting with win-98's file I/O functions.

Windows 98, like NT, has a 64-Bit SetFilePointer Call, but in 9x it is restricted to 32-Bits.

yeah from http://en.wikipedia.org/wiki/Fat32#Directory_table , there not much reserved bytes remain in Directory table to accomdate size > 4 GB

i'm looking at you, useless 6 bytes - last access date/time fields (and 1 byte create time fine resolution).

I don't know why someone didn't take the FAT32 filespec and find *ONE* extra byte somewhere in the file table entries to use as the 5'th byte of the file-size parameter. Having 40 bits to code the file-size (instead of 32) would have allowed for a file-size up to 1tb. They could have called it "FAT40", and by and large it would have been 100% backwards compatible with FAT32.

Making FAT40 would not be very difficult, but it would be useless in Windows 9x without reworking a significant amount of the I/O Subsystem.

[Guest wsxedcrfv]

Making FAT40 would not be very difficult, but it would be useless in Windows 9x without reworking a significant amount of the I/O Subsystem.

Giving win-9x the ability to read/write files larger than 4gb first requires a change to FAT32 to allow for storage of files larger than 4 gb. And I agree that in the end it might not be possible for win-9x to utilize such a modified version of FAT32.

But I wonder if, say, Win-XP or the various public domain versions of Linux / Unix might be able to be modified to use the modified FAT32? Any reason why not?

Would make a great source-forge project I would think, given that FAT32 is a simple and low-overhead file system and is so common for thumb drives, and is (arguably) public domain.

[Glenn9999]

KERNEL32.LIB is an Interface to KERNEL32.DLL, not a replacement, so Programs using KERNEL32.LIB would not be affected differently.

How come the LIB is roughly the same size as the DLL? All the other LIB files I've found from Microsoft are functional code libraries linked INTO the EXE (using the .H file as a guide) and not simple interfaces. Why would that case be any different.

Would make a great source-forge project I would think, given that FAT32 is a simple and low-overhead file system and is so common for thumb drives, and is (arguably) public domain.

Actually that brings up the other major problem. Microsoft would disagree with that assessment, especially considering that they have been suing other companies that have used and adapted FAT32 for their own purposes (the phrase "vigrously defend" definitely is true). Such a project would have a lawsuit on it so fast from Microsoft that the participants heads would spin for days.

[rloew]

Making FAT40 would not be very difficult, but it would be useless in Windows 9x without reworking a significant amount of the I/O Subsystem.

Giving win-9x the ability to read/write files larger than 4gb first requires a change to FAT32 to allow for storage of files larger than 4 gb. And I agree that in the end it might not be possible for win-9x to utilize such a modified version of FAT32.

But I wonder if, say, Win-XP or the various public domain versions of Linux / Unix might be able to be modified to use the modified FAT32? Any reason why not?

I've already done Patches to Windows XP FAT Filesystems, such as adding support for 256 and 512 Sector Clusters. So it probably is possible.

Doesn't help anyone in this subforum though.

KERNEL32.LIB is an Interface to KERNEL32.DLL, not a replacement, so Programs using KERNEL32.LIB would not be affected differently.

How come the LIB is roughly the same size as the DLL? All the other LIB files I've found from Microsoft are functional code libraries linked INTO the EXE (using the .H file as a guide) and not simple interfaces. Why would that case be any different.

The copy of KERNEL32.LIB I have is 177KB, less than half the size of KERNEL32.DLL. I would think that the LIB FIles with the same base name as System DLLs are Interfaces as well. KERNEL32.LIB might actually code some of the purely User Mode Code provided in KERNEL32.DLL, but I doubt that it could handle any Code that interfaces the KERNEL or requires internal System tables.

Edited March 31, 2011 by rloew

[Glenn9999]

The copy of KERNEL32.LIB I have is 177KB, less than half the size of KERNEL32.DLL. I would think that the LIB FIles with the same base name as System DLLs are Interfaces as well. KERNEL32.LIB might actually code some of the purely User Mode Code provided in KERNEL32.DLL, but I doubt that it could handle any Code that interfaces the KERNEL or requires internal System tables.

The DLL files I'm sure have overhead. But what I'm saying is the LIB is *literally* the same code of the DLL. You DO NOT need the DLL if you link the program with the equivalent lib. If you don't believe me, then explain what this does and why, especially since the same claim is made there.

http://www.tucows.com/preview/218911

[rloew]

The copy of KERNEL32.LIB I have is 177KB, less than half the size of KERNEL32.DLL. I would think that the LIB FIles with the same base name as System DLLs are Interfaces as well. KERNEL32.LIB might actually code some of the purely User Mode Code provided in KERNEL32.DLL, but I doubt that it could handle any Code that interfaces the KERNEL or requires internal System tables.

The DLL files I'm sure have overhead. But what I'm saying is the LIB is *literally* the same code of the DLL. You DO NOT need the DLL if you link the program with the equivalent lib. If you don't believe me, then explain what this does and why, especially since the same claim is made there.

http://www.tucows.com/preview/218911

With that tool, you can make a LIB that has the Functionality of a DLL. It is not the same as the LIB Files suppliend with MSVC.

As I said before, you cannot make LIBs out of core System DLLs. Your system will not boot without KERNEL32.DLL present.

[Guest wsxedcrfv]

All the various 64-bit file I/O functions (fseek64, lseek64, etc) are listed as being compatible with win95 and up, at least as far back as Visual Studio 6.

[rloew]

All the various 64-bit file I/O functions (fseek64, lseek64, etc) are listed as being compatible with win95 and up, at least as far back as Visual Studio 6.

Windows 9x allows you to use 64-Bit Seek arguments to make the API consistent with NT Versions. Unicode File functions are "supported" also, but contain only stubs that do nothing.

SetFilePointer will return an error if the argument is outside the 32-Bit limit.