Ini files. and the 64K filesize limit

Andrzej P. Wozniak wrote:
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)

Thanks for the info.
It seems I was wrong in thinking it might have been resolved in WinME. I
guess that makes more sense in retrospect, since ME is essentially Win9x at
its core.

Thus, it seems this 64 K filesize limit for INI files wasn't resolved until
XP and later (and also Win2K).

"Bill in Co" wrote in
m:

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


Too many unknowns.. Same player, exactly, on each OS? The only way to be
certain is to trace the files used. No need to go into functions too, unless
coding a precise fix (which I don't know how to do). What matters is that if
you want to replace a sysfile you need to know its name. (I love devilish
jokes). That's not really the point though, if you can be certain that the
player can handle a CDplayer.ini of more than 64KB you're in, somehow, if you
persist in the right direction, which will either be a replacement sysfile
(you might even try a direct transplant from WXP if you can put the original
back from real mode DOS if Bad Things stop rebooting somehow), or it might be
best to look for some tool that is based on intercepting calls to
CDplayer.ini and using its own large file. That's as transparent as it's
likely to get, so any competent fix would be coded along those lines.

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

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


Too many unknowns.. Same player, exactly, on each OS?

YES. The very same player, same edition. No ambiguities there. And to
add to this, keep in mind that I transferred all my Win9x apps over to WinXP
by using Laplink's PC Mover to move stuff over between PCs. There was no
way I was going to reinstall all of my several hundred apps IF I could
successfully avoid it, which I did.

Yes, installing all apps fresh would have been a cleaner approach, but I
didn't feel like spending a year (or so) reinstalling and customizing
everything all over again, and so I largely avoided that problem by using PC
Mover to transfer my programs AND settings from W98SE to XP. It was nice.
:-)

But to summarize, the proof is in the pudding. And the pudding here spoke:
No cdplayer.ini filesize limit issue - when used on XP :-)

The only way to be certain is to trace the files used.

Well, not really, per above. :-)

No need to go into functions too, unless
coding a precise fix (which I don't know how to do). What matters is that
if
you want to replace a sysfile you need to know its name.

Of course. Although since I'm not using my W98 computer very often to play
CDs, I can probably forego going to all this trouble.

(I love devilish
jokes). That's not really the point though, if you can be certain that the
player can handle a CDplayer.ini of more than 64KB you're in,

I am. It's doing it on my XP computer. Q.E.D. :-)

somehow, if you
persist in the right direction, which will either be a replacement sysfile
(you might even try a direct transplant from WXP if you can put the
original
back from real mode DOS if Bad Things stop rebooting somehow), or it might
be best to look for some tool that is based on intercepting calls to
CDplayer.ini and using its own large file. That's as transparent as it's
likely to get, so any competent fix would be coded along those lines.

And it would still be a bit of a PIA. :-)

"Bill in Co" wrote in
news
Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

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


Too many unknowns.. Same player, exactly, on each OS?

YES. The very same player, same edition. No ambiguities there. And
to add to this, keep in mind that I transferred all my Win9x apps over
to WinXP by using Laplink's PC Mover to move stuff over between PCs.
There was no way I was going to reinstall all of my several hundred apps
IF I could successfully avoid it, which I did.

Yes, installing all apps fresh would have been a cleaner approach, but I
didn't feel like spending a year (or so) reinstalling and customizing
everything all over again, and so I largely avoided that problem by
using PC Mover to transfer my programs AND settings from W98SE to XP.
It was nice.
:-)

But to summarize, the proof is in the pudding. And the pudding here
spoke: No cdplayer.ini filesize limit issue - when used on XP :-)

The only way to be certain is to trace the files used.

Well, not really, per above. :-)

No need to go into functions too, unless
coding a precise fix (which I don't know how to do). What matters is
that if
you want to replace a sysfile you need to know its name.

Of course. Although since I'm not using my W98 computer very often to
play CDs, I can probably forego going to all this trouble.

(I love devilish
jokes). That's not really the point though, if you can be certain that
the player can handle a CDplayer.ini of more than 64KB you're in,

I am. It's doing it on my XP computer. Q.E.D. :-)

somehow, if you
persist in the right direction, which will either be a replacement
sysfile (you might even try a direct transplant from WXP if you can put
the original
back from real mode DOS if Bad Things stop rebooting somehow), or it
might be best to look for some tool that is based on intercepting calls
to CDplayer.ini and using its own large file. That's as transparent as
it's likely to get, so any competent fix would be coded along those
lines.

And it would still be a bit of a PIA. :-)




Then you have your answer. WXP does it with nothing, W98 won't do it with
anything you'll accept. Job done.

Of course. Although since I'm not using my W98 computer very often to
play CDs, I can probably forego going to all this trouble.

(I love devilish
jokes). That's not really the point though, if you can be certain that
the player can handle a CDplayer.ini of more than 64KB you're in,

I am. It's doing it on my XP computer. Q.E.D. :-)

..
..
..

Then you have your answer. WXP does it with nothing, W98 won't do it with
anything you'll accept. Job done.


Got to say I find it interesting that you need to resort to WXP to let you
use a method that pretty much died out with W31... Nearly everyone else went
with a method that isn't limited by standard controls in the OS. I'm not sure
how tag files work with CD's but I bet there is a way. Same as ReplayGain
files don't have to be embedded in the files they belong to. Last time I used
any audip player than used CDplayer.ini at all, never mind depended on it,
was 1998. I ran into the same limits you did, and equally soon decided that
converting the CD tracks to MP3 with a decent sound quality solved far more
things, disk space, convenient access, track names, etc... I've got as pile
of CD's that stands nearly three feet from the floor in a corner not five
feet away, but I rarely have to reach for one of them because I did that
once, extracting copies to save myself the trouble ever since. It also makes
sure by optical drives are in perfect order when that really matters, too.

Lostgallifreyan wrote:
Of course. Although since I'm not using my W98 computer very often to
play CDs, I can probably forego going to all this trouble.

(I love devilish
jokes). That's not really the point though, if you can be certain that
the player can handle a CDplayer.ini of more than 64KB you're in,

I am. It's doing it on my XP computer. Q.E.D. :-)


Then you have your answer. WXP does it with nothing, W98 won't do it with
anything you'll accept. Job done.

For two reasons:
1) I'm using XP much more now, so it's not a big issue for me.
2) All the suggestions proposed are a royal PIA (IMHO) for something so
simple as being able to play a CD of all things! (We're not talking about
reinventing the operating system here to gain some other huge benefits,
afterall - now that might make it different (assuming one is only sticking
to W98, come hell or high water).

Got to say I find it interesting that you need to resort to WXP to let you
use a method that pretty much died out with W31... Nearly everyone else
went
with a method that isn't limited by standard controls in the OS.

I respectfully disagree. Many of the good older CD player apps, like
MusicMatch Jukebox, rely on and use "cdplayer.ini", so it IS an issue. This
didn't die out with Win3.1. This issue *may* have died out since the advent
of XP and later, however - I'd agree with that correction.

I'm not sure
how tag files work with CD's but I bet there is a way. Same as ReplayGain
files don't have to be embedded in the files they belong to. Last time I
used
any audio player that used CDplayer.ini at all, never mind depended on it,
was 1998.

Wow. I'm not sure what CD player you're (occasionally) using now, that
*doesn't* make use of cdplayer.ini, and yet still *retains* and *displays*
the artist and title and track information. (I mean, without having to go
online each time to get it, over and over again). Hmmm. I guess you may
be using some app that creates its own private database for its own
exclusive use.

I ran into the same limits you did, and equally soon decided that
converting the CD tracks to MP3 with a decent sound quality solved far
more
things, disk space, convenient access, track names, etc...

Of course. :-) But there are still some times that I'll play a CD...

I've got as pile
of CD's that stands nearly three feet from the floor in a corner not five
feet away, but I rarely have to reach for one of them because I did that
once, extracting copies to save myself the trouble ever since. It also
makes
sure by optical drives are in perfect order when that really matters, too.

Yes, I know. Same here :-)
I have a nice large library of mp3s, too, and I use them much more than the
CD player. But still, on those rarer occasions, it's nice not to have to
deal with this issue, at all.

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

Wow. I'm not sure what CD player you're (occasionally) using now, that
*doesn't* make use of cdplayer.ini, and yet still *retains* and *displays*
the artist and title and track information. (I mean, without having to go
online each time to get it, over and over again). Hmmm. I guess you may
be using some app that creates its own private database for its own
exclusive use.


Anything that can go to an online database can do it, and cache the fetch so
it doesn't have to repeat. Foobar2000 would do this, but it saves data as
binary which is lousy if you want to edit, reduce, backup or transplant to
another program. This is why I sidestepped the whole nonsense by extracting
to files on the hard disk so they can be tagged in a consistent way.

Foobar2000, 1by1, WinAmp, MPClassic, all play CD's if you want them too, but
I'm not aware of any of those using CDplayer.ini so I guess there might be
several alternatives to solve the problem of displaying track details. The
actual CD access can be bu DShow, WinAmp plugin, or program-specific code.
track data methods might be just as diverse.

You haven't yet said which CD player program you're using, so I have no idea
about that.

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

Wow. I'm not sure what CD player you're (occasionally) using now, that
*doesn't* make use of cdplayer.ini, and yet still *retains* and
*displays*
the artist and title and track information. (I mean, without having to
go
online each time to get it, over and over again). Hmmm. I guess you
may
be using some app that creates its own private database for its own
exclusive use.


Anything that can go to an online database can do it, and cache the fetch
so
it doesn't have to repeat. Foobar2000 would do this, but it saves data as
binary which is lousy if you want to edit, reduce, backup or transplant to
another program.

Yup. But usable, at least, for that one app. So if you have a good CD
player app that works seemlessly with its own database, and which is not
constrained by that 64K limit, that might be the easiest "solution".

This is why I sidestepped the whole nonsense by extracting
to files on the hard disk so they can be tagged in a consistent way.

Foobar2000, 1by1, WinAmp, MPClassic, all play CD's if you want them too,
but I'm not aware of any of those using CDplayer.ini so I guess there
might be
several alternatives to solve the problem of displaying track details. The
actual CD access can be bu DShow, WinAmp plugin, or program-specific code.
track data methods might be just as diverse.

You haven't yet said which CD player program you're using, so I have no
idea
about that.

Sure I did. MMJB (MusicMatch Jukebox). :-)
"1by1" simply uses directories for displaying mp3 ID3tag tag info and
playing *mp3s*.

I don't know how it works with CDs (and the metatag CD text issue, which is
completely different from mp3s, and their ID3 tags).

Ditto on Winamp (which I occasionally use to just play mp3s).

But my assumption is if they can't and don't use "cdplayer.ini", they have
to use a proprietary format database, unique to that one app.

"Bill in Co" wrote in
:

Sure I did. MMJB (MusicMatch Jukebox). :-)


Three times, each time looking like it was past tense, replaced by something
else since, but never mind...

If it can use DShow codecs or WinAmp plugins there's a chance it might have a
way to get text from a local database independently of CDplayer.ini.

Last I heard of Music Match (till this thread) is it was something many
people were kicking out ten years ago in favour of almost anything else
because it wasn't giving them what they wanted. If it hasn't changed usefully
in that time, maybe they were right, and you will do better to cast a wider
net.

Lostgallifreyan wrote:

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.

My strategy there was that if you did have your ini data divided into
two (or more) groups based on the name of the CD or the artist, that you
might not remember where your dividing line was (alphabetically
speaking) as to what custom ini file contained the information that you
were about to call for.

So if you want to play a CD where the title of the CD begins with J,
then you simply run the batch file "playJ". You've already coded that
batch file to copy a specific custom ini file (containing all the "j"
data) over to cdplayer.ini and then launch the CD player.