Ini files. and the 64K filesize limit

"Bill in Co" wrote in
:

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.


Does it truncate in a linear way as it fills, or does most-played stuff get
moved to the top of the file? If moved, it's effectively a cache thsat you
can use to enough advantage to minimise the loss to stuff you don't play so
often.

Another trick you can try is to make some basic categorisation of your CD's.
Before playing one, run a batch file for that category, which copies a file
with its track data to CDplayer.ini, after copying out the original to
whatever file it was last copied FROM, etc... You can multiply the capacity
by as many categories as you can figure out and make batch files for. I
remember that at times CDplayer.ini can get borked anyway, and this method
gives some limited protection to the main data copies because if CDplayer.ini
dies you can restore it instead of using its own valid updates to refresh
your data file(s).

it may be possible to code a small tool to automate this too. it takes a
while to spin up a CD, and the ID is taken early, I think. Likely time enough
to fetch the right data file over to CDplayer.ini before CDplayer.ini itself
gets locked and loaded or whatever usually hapens when it's accessed.

Lostgallifreyan wrote:
"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.

Thanks for the correction. My memory was indeed off a bit. :-)

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.

I expect so too. And there was that other one mentioned by 98Guy. But
they're all workarounds. So evidently "simply replacing" (cough) one of
the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing did
for me, for that other problem)

Lostgallifreyan wrote:
"Bill in Co" wrote in
:

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.


Does it truncate in a linear way as it fills, or does most-played stuff
get
moved to the top of the file? If moved, it's effectively a cache thsat you
can use to enough advantage to minimise the loss to stuff you don't play
so
often.

I caught it after the fact, and its size was reduced from 64 KB to about 3
KB when I finally discovered it. I'm pretty sure it was truncated to zero
and then kept adding to it as I played some CDs and finally discovered it.

BTW, it doesn't take a whole bunch of CDs to get to that 64 KB (of text
entries).

As I recall, I roughly estimated the number of CDs (by looking at a full
cdplayer.ini file) at a bit over 100 albums (it was much less than 200 CD
albums).

Of course, that figure will vary a bitwith the amount and length of the
entries in the cdplayer.ini file, but that's in the ballpark.

Another trick you can try is to make some basic categorisation of your
CD's.

UGH! No thanks. :-)

Before playing one, run a batch file for that category, which copies a
file
with its track data to CDplayer.ini, after copying out the original to
whatever file it was last copied FROM, etc...

This (for me) "pre-categorization" would be a non starter.
(ditto on using playlists :-)

You can multiply the capacity
by as many categories as you can figure out and make batch files for. I
remember that at times CDplayer.ini can get borked anyway, and this
method
gives some limited protection to the main data copies because if
CDplayer.ini
dies you can restore it instead of using its own valid updates to refresh
your data file(s).

This would just be too much of a PIA :-)

What is really needed is a completely transparent process, so that when any
previously played (and thus CD texted) CD is put into the player, the CD
player would immediately recognize it. I think that means a bunch of
different ini files (assuming this could be set up right in the first place)
would have to be sequentially copied, one by one, to cdplayer.ini, until the
specific ini file having that album info stored in it appeared (assuming
that could be easily determined programatically).

Then if you change CDs, the whole process would have to run again. UGH!!

And since the CD player can only see and use the one, and only one,
"cdplayer.ini" (which is in the windows directory), this would be a real
PIA.

it may be possible to code a small tool to automate this too. it takes a
while to spin up a CD, and the ID is taken early, I think. Likely time
enough
to fetch the right data file over to CDplayer.ini before CDplayer.ini
itself
gets locked and loaded or whatever usually happens when it's accessed.

This too would be a challenge.

Hmmm, another option might be to let "cdplayer.ini" just reach 64K, and when
it does that, somehow, programmatically, automatically delete a few entries
in cdplayer.ini, to keep the filesize under 64K max each time).

(deleting the first in, last out, entries would I think be preferable to
just deleting CD text info from the end, which might be easier)

There would have to be some programatic test on its filesize of course to
see when its close to reaching its limit.

Osoba podpisana jako 98 Guy w artykule
pisze:

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.

What about newer articles, where the "applies to" section mentions
applications from MS Office 97, 2000, XP (2002), 2003, 2007 in use with
Windows 95, 98, ME, 2000, XP and Vista?

http://support.microsoft.com/kb/140754
http://support.microsoft.com/kb/223019
http://support.microsoft.com/kb/223021
http://support.microsoft.com/kb/224149
http://support.microsoft.com/kb/224169
http://support.microsoft.com/kb/234623

All these KB articles contain info about cause of errors similar to the next
article:
http://support.microsoft.com/kb/235242
/----
You receive an "Error 1913. Could not update the ini file WIN.INI" error
message when you install Office 2000
[...]
This behavior occurs if one of the following is true:
[...]
-or-
The file size of the Win.ini file is greater than or equal to 64 kilobytes
(64 KB).
\----

And here is an extract from the newest, most complete article I've found:
http://support.microsoft.com/kb/291174
/----
The Win.ini file has incorrect, duplicate, or missing entries

You may need to correct the Win.ini file. To complete this procedure, you
need to know the name of your printer driver.

NOTE: This cause does not apply to Windows Vista, to Microsoft Windows 2000,
or to Microsoft Windows XP. The Win.ini file is used in Microsoft Windows 98
and in Microsoft Windows Millennium Edition (Me) to load certain settings
for the system. In Windows Vista, in Microsoft Windows 2000, and in
Microsoft Windows XP, the Win.ini file is used for backwards compatibility.

1. Click Start, point to Find, and then click Files or Folders.
2. In the Named box, type Win.ini.
3. In the Look in box, click your local hard drive, and then click Find Now.
The Win.ini file is displayed at the bottom of the Find dialog box.
4. Check the file size in the Size column. If it is larger than 64 kilobytes
(KB), the Win.ini file is considered large.
\----

Still not win-9x/me problem?

To be clear, file size limit is just a consequence of a section size limit.
API calls described earlier in this thread allow to open 64 KB of a section
already *existing* in ini file. If you want to create a *new* section, the
same API calls will try to open 64 KB of a whole ini file.

--
Andrzej P. Woźniak (swap z-h in address)

"Bill in Co" wrote in news:io-
:

I expect so too. And there was that other one mentioned by 98Guy. But
they're all workarounds. So evidently "simply replacing" (cough) one of
the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing did
for me, for that other problem)


Any chance of running eiother Dependency Walker or FileMon on your system and
using Profile or Capture respectively to find out all the sysfiles used to
access CDplayer.ini? I don't know enough to code an answer but it might be
useful to know if it's a capacity problem, or just an addressing one. If
players use the file directly and not via the OS, you couldn't solve this
with a replaced sysfile anyway, but it might be easier to solve directly.


Or you might find a player that can keep its own kind of record based on the
CD's ID. So long as it either makes import easy, or avoids binary data,
transferring your current file content should be easy enough.

One work-around for cdplayer.ini is that you sort the contents
alphabetically (by artist, Album name, etc) and you have several files
(ie - cdplayer-A-to-K.ini, cdplayer-L-to-Z.ini) and you move the
contents into their respective files by sorting alphabetically. You
keep each file to 64kb or less.

Then when you want to play a certain CD, you have a batch file that
copies the relavent alpha-sorted ini file to the "real" cdplayer.ini and
then launches the cd player.

So you might have 26 batch files, such as:

playA.bat
playB.bat
playC.bat
(etc)

So most of them would have the same content:

======
copy cdplayer-A-to-K.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======

or

======
copy cdplayer-L-to-Z.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======

98 Guy wrote in :

So you might have 26 batch files, such as:

playA.bat
playB.bat
playC.bat
(etc)


He vetoed my idea. He's not going to go for THAT.

Lostgallifreyan wrote:
98 Guy wrote in :

So you might have 26 batch files, such as:

playA.bat
playB.bat
playC.bat
(etc)


He vetoed my idea. He's not going to go for THAT.

I think I'd rather give up playing CDs altogether if it came down to that.
:-)

98 Guy wrote:
One work-around for cdplayer.ini is that you sort the contents
alphabetically (by artist, Album name, etc) and you have several files
(ie - cdplayer-A-to-K.ini, cdplayer-L-to-Z.ini) and you move the
contents into their respective files by sorting alphabetically. You
keep each file to 64kb or less.

Then when you want to play a certain CD, you have a batch file that
copies the relavent alpha-sorted ini file to the "real" cdplayer.ini and
then launches the cd player.

So you might have 26 batch files, such as:

playA.bat
playB.bat
playC.bat
(etc)

So most of them would have the same content:

======
copy cdplayer-A-to-K.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======

or

======
copy cdplayer-L-to-Z.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======

I think I'd rather give up playing CDs altogether if it came down to having
to do this. :-)

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

I expect so too. And there was that other one mentioned by 98Guy. But
they're all workarounds. So evidently "simply replacing" (cough) one
of
the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing
did
for me, for that other problem)


Any chance of running eiother Dependency Walker or FileMon on your system
and
using Profile or Capture respectively to find out all the sysfiles used to
access CDplayer.ini?

Interesting idea. :-) More below.

I don't know enough to code an answer but it might be
useful to know if it's a capacity problem, or just an addressing one. If
players use the file directly and not via the OS, you couldn't solve this
with a replaced sysfile anyway, but it might be easier to solve directly.

Well, it *does* seem the issue is tied into the OS. How do I know that?
Well, I have successfully used 64K cdplayer.ini on my XP system, that's
how. Since it appears to be a non-issue there, I guess we know the answer.
:-)

Or you might find a player that can keep its own kind of record based on
the
CD's ID. So long as it either makes import easy, or avoids binary data,
transferring your current file content should be easy enough.

I think there are some CD player apps that do something similar to this -
use their own database, and sidestep the problem altogether. Unfortunately
a fair amount don't, however, including my beloved old version of MMJB
(MusicMatch Jukebox) - beloved before it got taken over by another company
and went downhill from then on. (can't recall who, but do recall it
happened).

Just for the record, anybody using a CD player app on Win9x that uses
"cdplayer.ini" to get and store the track info (which I think is a lot, if
not the majority of them), is gonna run into this problem, once they play
around 200 (or less, likely), different CDs, as already mentioned.
Granted, it's not the end of the world, but it is a bit of a PIA.