Ini files. and the 64K filesize limit

In Win9x, the INI files are normally limited to 64K bytes, which normally is
not a big problem. It can be problematic, however, for most CD music
players that rely on an INI file (cdplayer.ini) to store the CD text
(artist, title, etc) information, since once that 64 K filesize is reached
(after playing a whole bunch of different CDs), it hits that limit, and gets
truncated (starting all over again, fresh, with no entries in the new INI
file). I've seen that happen here (using the old MusicMatch Jukebox - a
nice player for its time)

The specific INI file is "cdplayer.ini", found in the \windows directory.

As mentioned, most INI files are under 64 Kbytes anyways, so normally it's
not an issue. And if no minds their CD player just saying Track 1, Track 2,
etc, instead of the artist and title of the tune playing, then it's no big
deal.

Question: was there ever a system file patch to Win98SE that fixed this
issue? By fixed that, I don't mean a "workaround", or something
sidestepping the use of "cdplayer.ini". I mean allowing cdplayer.ini to
exceed 64 K without any issues. (As an aside, Sysedit is limited to 64K,
but one doesn't need to use sysedit here. Also, this 64K limitation seems
to have been dropped in XP)

Guess nobody knows anything about this? (or uses a CD player anymore?)

Bill in Co wrote:
In Win9x, the INI files are normally limited to 64K bytes, which normally
is
not a big problem. It can be problematic, however, for most CD music
players that rely on an INI file (cdplayer.ini) to store the CD text
(artist, title, etc) information, since once that 64 K filesize is reached
(after playing a whole bunch of different CDs), it hits that limit, and
gets
truncated (starting all over again, fresh, with no entries in the new INI
file). I've seen that happen here (using the old MusicMatch Jukebox - a
nice player for its time)

The specific INI file is "cdplayer.ini", found in the \windows directory.

As mentioned, most INI files are under 64 Kbytes anyways, so normally it's
not an issue. And if no minds their CD player just saying Track 1, Track
2,
etc, instead of the artist and title of the tune playing, then it's no big
deal.

Question: was there ever a system file patch to Win98SE that fixed this
issue? By fixed that, I don't mean a "workaround", or something
sidestepping the use of "cdplayer.ini". I mean allowing cdplayer.ini to
exceed 64 K without any issues. (As an aside, Sysedit is limited to 64K,
but one doesn't need to use sysedit here. Also, this 64K limitation seems
to have been dropped in XP)

Bill in Co wrote:

Guess nobody knows anything about this? (or uses a CD player
anymore?)

The Micro$haft reference to this limitation is he

http://support.microsoft.com/kb/78346

The "applies to" section only mentions win-3.x, not win-9x/me.

It has been said that the use of the "INI file" has been strongly
deprecated by Macro$oft starting with Win-95 in favor of storing data in
the registry, and deprecated in .NET in favor of XML .config files.

The KB article above mentions the kernel32 API function call
GetPrivateProfileString as being used to access data in .ini files. The
Windows 9x MSDN Library Documentation does not mention any size limit
for a destination buffer.

A trace of the GetPrivateProfileString API Call shows that it thunks
down to 16-Bit Code. Running the GetPrivateProfileString API Call with
a Destination Buffer size 64K Fails.

This 64kb data-size limit seems to apply to a section within a .ini
file, not the over-all size of the file.

A section is denoted by an identifier or label inside a pair of square
brackets.

If you have a large .ini file, you might want to add some [identifier]
sections inside it to see how your application deals with them.

Or strip out any data you don't need to reduce the size.

I'm not quite sure what function or role your .ini file is providing for
you in terms of playback of music CD's.

Presumably when you insert a music CD into your computer's CD player,
you know what CD you're inserting (ie Artist, Album, etc) and you're
holding the CD jewel case in your hand, so you know what the tracks are
even if your software player doesn't know. And not a lot of commercial
CD's have CD-text information (the vast majority don't).

It's not so much that people don't use a CD player any more, it's more
like they rip CD audio to their hard drive, and in the process obtain
CD-text info from the internet (CDDB) and that's how the CD is
identified and how the tracks are names by the ripping software.

98 Guy wrote in :

It's not so much that people don't use a CD player any more, it's more
like they rip CD audio to their hard drive, and in the process obtain
CD-text info from the internet (CDDB) and that's how the CD is
identified and how the tracks are names by the ripping software.


Yes, I think that has been a standard way for a while now. I thought about
the CDplayer.ini problem (even looked it up yesterday but was in a deep
three-piper that demanded attention for 36 hours so didn't try to answer).

I think a lot of stuff was limited to 64K. It's the standard 'text control'
limit too, hence the need for small text editors that use more for big files.
INI files were expected to be opened in small editors so that's why the limit
exists.

To work round it neatly enough for seamless operation might not be possible
for CDplayer.ini because to stay compatible with the existing format you'd
need to address a larger file, and invent a way to do it in chunks of 64K
that include a byte that holds a page number, or does something else similar.
Doing this for one tool might break another because that sort of scheme was
never standardised for CDplayer.ini as far as I know.

What might work is something that uses the disk's ID to determine a short-
hand code in CDplayer.ini so a tool can then refer to that to place or fetch
the full strings of text from a larger file, handing them back to the calling
process so that it thinks it's dealing with CDplayer.ini directly. Another
tool seeing CDplayer.ini would render the codes themselves but it wouldn't
break. Question is: did anyone ever make something like this work? I have no
idea because I liked looking at the CD box better than the onscreen text, so
I never got into the habit of using a computerised method, except to tag MP3
or MPC or WV files when I made them. And I'd go to web sites and find
listings or even write them out by hand, I never did this often enough to
find that too hard..

98 Guy wrote in :

This 64kb data-size limit seems to apply to a section within a .ini
file, not the over-all size of the file.


That's interesting but I still think that a total limit of 64K was often
accepted and imposed to make sure that a small text editor could edit
directly. Was it reeally a section size limit, or a start position? Even if
was the size, they had to handle a case where the whole INI file might be one
big section..

Bill in Co wrote:

Guess nobody knows anything about this? (or uses a CD player
anymore?)

You might want to look at this:

http://www.autoitscript.com/forum/to...dini-database/

(Sort of frontend for Cdplayer.ini - but much more!)

98 Guy wrote:
Bill in Co wrote:

Guess nobody knows anything about this? (or uses a CD player
anymore?)

The Micro$haft reference to this limitation is he

http://support.microsoft.com/kb/78346

The "applies to" section only mentions win-3.x, not win-9x/me.

I think it applies to Win9x too, from what I had gleaned elsewhere. But
possibly not WinME (that issue may have been addressed there).

It has been said that the use of the "INI file" has been strongly
deprecated by Macro$oft starting with Win-95 in favor of storing data in
the registry, and deprecated in .NET in favor of XML .config files.

Yeah, I know, MS didn't like it, but a lot of apps use (or used) it, and
it's thus not inconsequential by any means, especially for the Win9x vintage
programs!

The KB article above mentions the kernel32 API function call
GetPrivateProfileString as being used to access data in .ini files. The
Windows 9x MSDN Library Documentation does not mention any size limit
for a destination buffer.

A trace of the GetPrivateProfileString API Call shows that it thunks
down to 16-Bit Code. Running the GetPrivateProfileString API Call with
a Destination Buffer size 64K Fails.

And I do recall reading this about some of those API calls.

This 64kb data-size limit seems to apply to a section within a .ini
file, not the over-all size of the file.

A section is denoted by an identifier or label inside a pair of square
brackets.

If you have a large .ini file, you might want to add some [identifier]
sections inside it to see how your application deals with them.

There are only two sections (one tiny OptionsSettings, and one big one for
the CD tracks), in cdplayer.ini. So for all practical purposes, there
aren't any "sections" within CDplayer.ini (unlike most INI files), and even
creating some separate ones wouldn't solve the problem, since 1) the CD
player wouldn't even know how to use them separately, and 2) they would
eventually fill up anyways.

Or strip out any data you don't need to reduce the size.

And that is what I had to do. But if you do this, you'll have to delete
some previously stored CD information. The end result is this: The CD
player can store its CD track information locally on your HD for a limited
number of CDs. Once cdplayer.ini reaches 64K, the file gets truncated (and
all locally stored CD track info is lost). More on this below...

I'm not quite sure what function or role your .ini file is providing for
you in terms of playback of music CD's.

Presumably when you insert a music CD into your computer's CD player,
you know what CD you're inserting (ie Artist, Album, etc) and you're
holding the CD jewel case in your hand, so you know what the tracks are
even if your software player doesn't know. And not a lot of commercial
CD's have CD-text information (the vast majority don't).

OK, here is what happens:
You insert a CD the first time, and using CCDB or whatever, its track
information is retrieved, and then stored in "cdplayer.ini", so that the
next time you insert that same CD, the CD player immediately recognizes it,
and displays the track information. (NB: this discussion has nothing to
do with separate, standalone, home CD players)

IF you don't have that cdplayer.ini (or something comparable) capability,
you'll isntead see Track 01, Track 02, Track 03, etc, on your CD player app,
*unless* you let the program go out once again online to CDDB (or whatever),
and redundantly retrieve the same track information once again (this,
assuming you're connected to the Internet, and hopefully not on dial-up!).
Which is a real waste.

It's not so much that people don't use a CD player any more, it's more
like they rip CD audio to their hard drive, and in the process obtain
CD-text info from the internet (CDDB) and that's how the CD is
identified and how the tracks are names by the ripping software.

That's fine the first time. But to have to do this repetitively, each and
every time any CD is inserted (especially a same CD you had played before),
seems ridiculous (and you'd HAVE to be online to get it).

So unless the CD track information is also being stored locally on your
harddrive (as in cdplayer.ini), that is exactly what happens. Which means,
of course, you'd have to be connected to the Internet too, to get this.

Lostgallifreyan wrote:
98 Guy wrote in :

This 64kb data-size limit seems to apply to a section within a .ini
file, not the over-all size of the file.


That's interesting but I still think that a total limit of 64K was often
accepted and imposed to make sure that a small text editor could edit
directly.

Which is what sysedit expects, and can only handle (64K filesize limit).
You remember "sysedit"? The system INI file editor? (kinda like a
dedicated notepad)

Running sysedit, at least as I recall, immediately opened up the four(?)
principal system INI files: Can I remember those? Ugh...

Let's see: from memory, I think it was: windows.ini, system.ini,
control.ini(?),
and something else. I forget now. Well, I'm almost positive the first two
at least are correct, anyways. And I think control.ini is too. But I
think there was another one. I guess I could look, but whatever

Was it reeally a section size limit, or a start position? Even if
was the size, they had to handle a case where the whole INI file might be
one
big section..

Which is essentially is, in the case of cdplayer.ini, as I explained in my
previous reply just now. So you're right - it's a non-solution for this
issue.

98 Guy wrote:
Bill in Co wrote:

Guess nobody knows anything about this? (or uses a CD player
anymore?)

You might want to look at this:

http://www.autoitscript.com/forum/to...dini-database/

(Sort of frontend for Cdplayer.ini - but much more!)

That is an interesting workaround. I'm not sure how flawless it is
practice, but at least it was an idea!

I had thought (hoped) that by now some single system file in Win9x had been
updated by someone to eliminate that 64K INI filesize barrier, but I guess
not.

Those msfn forums authors sometimes posted some of those "updated" system
files (like shell32.dll). However, even replacing shell32.dll might cause
other issues, so who knows. (That's a pretty significant system file
change!).

Or maybe the 64 K max ini filesize code is limited by command.com, in which
case, it's a dead issue. It's not an earth shaking issue for me anyways,
since I spend more time on XP, but it would be nice to know and might be
useful for others out there who are only using Win95 or Win98 and playing
tons of CDs (and not online all the time). And maybe even WinME (not sure
if that 64K INI filesize limitation was removed then, but I had thought I
had seen somewhere that it might have been).

"Bill in Co" wrote in
m:

Running sysedit, at least as I recall, immediately opened up the four(?)
principal system INI files: Can I remember those? Ugh...

Let's see: from memory, I think it was: windows.ini, system.ini,
control.ini(?),
and something else. I forget now. Well, I'm almost positive the first
two at least are correct, anyways. And I think control.ini is too.
But I think there was another one.

Autoexec.bat, Config.sys, System.ini, Win.ini. I like SysEdit,. I rarely see
it but I contemplated including it in my W98 core. At times that quick view
of all four files is exactly what's needed to figure things out.

About that CDplayer.ini, I bet this problem has faced coders and baked
noodles aplenty in the past, and there may well be a way round it. But it
WILL be a workround of sorts, whatever you find. I think the best ones will
likely trake the form of some kind of tiny shell extension that diverts from
CDplayer.ini to a larger file via whatever means is needed to map the data so
the player sees as much data as it needs, within its own limits.