Can't open more than ~20 files at once?
Mike Fox -- mfox@Matrox.COM
Friday, March 07, 1997
Environment: VC++ 4.2-flat, NT 4.0
Hi,
Could someone please tell me what stupid mistake I'm making here? With the
following code, I am unable to open more than about 236 characters worth of
files at once even though my buffer is 4K in size. GetOpenFileName returns
with no error. Furthermore, it seems that if one of the selected file names
is truncated I get an 'internal' "File not found" error when the list of
files is parsed after hitting Open (and the dialog remains). Interestingly,
if I drop the OFN_EXPLORER flag, I can get up to about 1900 characters
before things barf. It seems like some lower-level function is imposing its
own limit, independently of my actual buffer size. (I know that a more
flexible method is to add my own hook function but the following should
work, right?)
OPENFILENAME ofn;
//set structure to zero
memset(&ofn, 0, sizeof(OPENFILENAME));
char szBuffer[4096];
strcpy(szBuffer, "*.*");
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFile = &szBuffer[0];
ofn.nMaxFile = 4096;
ofn.Flags = OFN_PATHMUSTEXIST |
OFN_FILEMUSTEXIST |
OFN_ALLOWMULTISELECT | // want
multiple selection
OFN_EXPLORER;
if(GetOpenFileName(&ofn))
{
// szBuffer never contains more than ~236 characters
.
}
else
// never called unless I hit Cancel (or exceed 4K)
TRACE("Error in GetOpenFileName!\n");
-mike
mfox@matrox.com
Mike Blaszczak -- mikeblas@nwlink.com
Sunday, March 09, 1997
[Mini-digest: 4 responses]
At 09:02 3/7/97 -0500, Mike Fox wrote:
>Environment: VC++ 4.2-flat, NT 4.0
MFC 4.2-flat isn't compatible with shipping versions of several operating
system components. You need to upgrade your copy of MFC to MFC 4.2b by
installing the patch from the Microsoft website. You can expect seemingly
random things to break here and there as long as you (or your customers)
keep using MFC 4.2-flat against the released version of those operating
system components.
>Could someone please tell me what stupid mistake I'm making here? With the
>following code, I am unable to open more than about 236 characters worth of
>files at once even though my buffer is 4K in size. GetOpenFileName returns
>with no error. Furthermore, it seems that if one of the selected file names
>is truncated I get an 'internal' "File not found" error when the list of
>files is parsed after hitting Open (and the dialog remains).
The problem you're experiencing is a bug in Windows NT. It was fixed in
a service pack release. You can download the service packs from the
Microsoft Web Site. The problem you're experiencing has been described
at least a couple of times before on the list, and I'm pretty sure it is
also ritten up in the Microsoft Knowledge Base.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: jimt1@voicenet.com (Jim Tannenbaum)
Mike,
You are probably doing everything correctly, except trying to open too
many files at once! By convention ANSI C (& derivatives) limit you to 20 or
so files. If you check the source code files (stdio.h &/or files.cpp), you
will find _NFILES defined as 20. As in the max number of files you can open
at one time is 20. You used to need current versions of MASM & the C
compiler to fix and rebuild the libraries. I don't know if this is still a
user option. Last time I did this was in C 7.0 under DOS. Hope this helps.
Jet
>Environment: VC++ 4.2-flat, NT 4.0
>
>Hi,
>
>Could someone please tell me what stupid mistake I'm making here? With the
>following code, I am unable to open more than about 236 characters worth of
>files at once even though my buffer is 4K in size. GetOpenFileName returns
>with no error. Furthermore, it seems that if one of the selected file names
>is truncated I get an 'internal' "File not found" error when the list of
>files is parsed after hitting Open (and the dialog remains). Interestingly,
>if I drop the OFN_EXPLORER flag, I can get up to about 1900 characters
>before things barf. It seems like some lower-level function is imposing its
>own limit, independently of my actual buffer size. (I know that a more
>flexible method is to add my own hook function but the following should
>work, right?)
>
>
> OPENFILENAME ofn;
> //set structure to zero
> memset(&ofn, 0, sizeof(OPENFILENAME));
>
> char szBuffer[4096];
> strcpy(szBuffer, "*.*");
>
> ofn.lStructSize = sizeof(OPENFILENAME);
> ofn.lpstrFile = &szBuffer[0];
> ofn.nMaxFile = 4096;
> ofn.Flags = OFN_PATHMUSTEXIST |
> OFN_FILEMUSTEXIST |
> OFN_ALLOWMULTISELECT | // want
>multiple selection
> OFN_EXPLORER;
>
> if(GetOpenFileName(&ofn))
> {
> // szBuffer never contains more than ~236 characters
> .
> }
> else
> // never called unless I hit Cancel (or exceed 4K)
> TRACE("Error in GetOpenFileName!\n");
>
>
>-mike
>
>mfox@matrox.com
>
>
>
JJM Systems, Inc Phone: (215) 672-3660 Ext 16
1 Ivybrook Blvd, Suite 190 Fax: (215) 672-5702
Ivyland, PA 19874 Net: jimt1@voicenet.com
-----From: David Lowndes
> Environment: VC++ 4.2-flat, NT 4.0
Hi,
Could someone please tell me what stupid mistake I'm making here? With
the
following code, I am unable to open more than about 236 characters
worth of
files at once even though my buffer is 4K in size.
<
Mike,
Get NT4 SP2 (and the hot fixes), this problem with the common Explorer
style dialog was fixed there.
Dave Lowndes
-----From: mzinner@berlin.snafu.de
> Could someone please tell me what stupid mistake I'm making here? With the
> following code, I am unable to open more than about 236 characters worth of
> files at once even though my buffer is 4K in size. GetOpenFileName returns
I just wanted to tell you that I played a lot of time witzh this and
found no way to fix it. I ran into the same limits you did and ended
using the old style dialog to get at least some 1000+ chars.
-manfred
Mike Blaszczak -- mikeblas@nwlink.com
Tuesday, March 11, 1997
[Mini-digest: 4 responses]
>-----From: jimt1@voicenet.com (Jim Tannenbaum)
>You are probably doing everything correctly, except trying to open too
>many files at once! By convention ANSI C (& derivatives) limit you to 20 or
>so files.
This is entirely wrong. The ANSI C standard nor the proposed ANSI C++
standard do not provide or suggest such a limitation.
>If you check the source code files (stdio.h &/or files.cpp), you
>will find _NFILES defined as 20.
This is an implementation-defined constant. Some versions of Visual C++ have
this constant defined to reflect a limitation built into the runtime
libraries,
but that limitation has nothing to do with any ANSI standard or draft. I
can't find this symbol in any 32-bit version of Visual C++; it _was_ around
in some 16-bit versions, but the person who asked this question has nothing
to do with sixteen bits.
You _know_ that this symbol has nothing to do with ANSI because it involves
the C Runtimes and begins with an underline. If ANSI mandated it for the
runtimes, it wouldn't have a beginning underscore.
>As in the max number of files you can open at one time is 20.
>You used to need current versions of MASM & the compiler to fix
>and rebuild the libraries.
No. This isn't even close. Your information is grossly outdated at best.
>I don't know if this is still a user option.
>Last time I did this was in C 7.0 under DOS.
Apparently so. You can write, in five minutes, a program that shows the
number of opened files in Visual C++ 4.2b is really lots closer to
_five hundred_, not twenty. Try this on for size:
#include
void main()
{
FILE* pFile[1024];
int n;
char szName[100];
for (n = 0; n < 1024; n++)
{
printf("File %d\n", n);
sprintf(szName, "%d.FOO", n);
pFile[n] = fopen(szName, "w");
if (pFile[n] == NULL)
{
printf("File %s failed!\n", szName);
break;
}
fprintf(pFile[n], "File named %s\n", szName);
}
int m;
for (m = 0; m < n; m++)
{
fclose(pFile[m]);
}
return;
}
You'll probably find that the failing file is foudn only after
hundreds of files have been opened, and that places the real limit
at tens of dozens higher than twenty.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: Mike Blaszczak
[Mini-digest: 4 responses]
At 09:02 3/7/97 -0500, Mike Fox wrote:
>Environment: VC++ 4.2-flat, NT 4.0
MFC 4.2-flat isn't compatible with shipping versions of several operating
system components. You need to upgrade your copy of MFC to MFC 4.2b by
installing the patch from the Microsoft website. You can expect seemingly
random things to break here and there as long as you (or your customers)
keep using MFC 4.2-flat against the released version of those operating
system components.
>Could someone please tell me what stupid mistake I'm making here? With the
>following code, I am unable to open more than about 236 characters worth of
>files at once even though my buffer is 4K in size. GetOpenFileName returns
>with no error. Furthermore, it seems that if one of the selected file names
>is truncated I get an 'internal' "File not found" error when the list of
>files is parsed after hitting Open (and the dialog remains).
The problem you're experiencing is a bug in Windows NT. It was fixed in
a service pack release. You can download the service packs from the
Microsoft Web Site. The problem you're experiencing has been described
at least a couple of times before on the list, and I'm pretty sure it is
also ritten up in the Microsoft Knowledge Base.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
This performance was not lip-synched.
-----From: jimt1@voicenet.com (Jim Tannenbaum)
Mike,
You are probably doing everything correctly, except trying to open too
many files at once! By convention ANSI C (& derivatives) limit you to 20 or
so files. If you check the source code files (stdio.h &/or files.cpp), you
will find _NFILES defined as 20. As in the max number of files you can open
at one time is 20. You used to need current versions of MASM & the C
compiler to fix and rebuild the libraries. I don't know if this is still a
user option. Last time I did this was in C 7.0 under DOS. Hope this helps.
Jet
>Environment: VC++ 4.2-flat, NT 4.0
>
>Hi,
>
>Could someone please tell me what stupid mistake I'm making here? With the
>following code, I am unable to open more than about 236 characters worth of
>files at once even though my buffer is 4K in size. GetOpenFileName returns
>with no error. Furthermore, it seems that if one of the selected file names
>is truncated I get an 'internal' "File not found" error when the list of
>files is parsed after hitting Open (and the dialog remains). Interestingly,
>if I drop the OFN_EXPLORER flag, I can get up to about 1900 characters
>before things barf. It seems like some lower-level function is imposing its
>own limit, independently of my actual buffer size. (I know that a more
>flexible method is to add my own hook function but the following should
>work, right?)
>
>
> OPENFILENAME ofn;
> //set structure to zero
> memset(&ofn, 0, sizeof(OPENFILENAME));
>
> char szBuffer[4096];
> strcpy(szBuffer, "*.*");
>
> ofn.lStructSize = sizeof(OPENFILENAME);
> ofn.lpstrFile = &szBuffer[0];
> ofn.nMaxFile = 4096;
> ofn.Flags = OFN_PATHMUSTEXIST |
> OFN_FILEMUSTEXIST |
> OFN_ALLOWMULTISELECT | // want
>multiple selection
> OFN_EXPLORER;
>
> if(GetOpenFileName(&ofn))
> {
> // szBuffer never contains more than ~236 characters
> .
> }
> else
> // never called unless I hit Cancel (or exceed 4K)
> TRACE("Error in GetOpenFileName!\n");
>
>
>-mike
>
>mfox@matrox.com
>
>
>
JJM Systems, Inc Phone: (215) 672-3660 Ext 16
1 Ivybrook Blvd, Suite 190 Fax: (215) 672-5702
Ivyland, PA 19874 Net: jimt1@voicenet.com
-----From: David Lowndes
> Environment: VC++ 4.2-flat, NT 4.0
Hi,
Could someone please tell me what stupid mistake I'm making here? With
the
following code, I am unable to open more than about 236 characters
worth of
files at once even though my buffer is 4K in size.
<
Mike,
Get NT4 SP2 (and the hot fixes), this problem with the common Explorer
style dialog was fixed there.
Dave Lowndes
-----From: mzinner@berlin.snafu.de
> Could someone please tell me what stupid mistake I'm making here? With the
> following code, I am unable to open more than about 236 characters worth of
> files at once even though my buffer is 4K in size. GetOpenFileName returns
I just wanted to tell you that I played a lot of time witzh this and
found no way to fix it. I ran into the same limits you did and ended
using the old style dialog to get at least some 1000+ chars.
-manfred
-----From: Mike Fox
Mike,
Thanks for your reply re. my problem opening files. Everything makes sense
now (except why the Canadians ever got rid of Patrick Roy...).
-mike
-----From: Mike Fox
Hi,
Could someone please tell me what stupid mistake I'm making here? With the
following code, I am unable to open more than about 236 characters worth of
files at once even though my buffer is 4K in size. GetOpenFileName returns
with no error. Furthermore, it seems that if one of the selected file names
is truncated I get an 'internal' "File not found" error when the list of
files is parsed after hitting Open (and the dialog remains). Interestingly,
if I drop the OFN_EXPLORER flag, I can get up to about 1900 characters
before things barf. It seems like some lower-level function is imposing its
own limit, independently of my actual buffer size. (I know that a more
flexible method is to add my own hook function but the following should
work, right?)
OPENFILENAME ofn;
//set structure to zero
memset(&ofn, 0, sizeof(OPENFILENAME));
char szBuffer[4096];
strcpy(szBuffer, "*.*");
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.lpstrFile = &szBuffer[0];
ofn.nMaxFile = 4096;
ofn.Flags = OFN_PATHMUSTEXIST |
OFN_FILEMUSTEXIST |
OFN_ALLOWMULTISELECT | // want
multiple selection
OFN_EXPLORER;
if(GetOpenFileName(&ofn))
{
// szBuffer never contains more than ~236 characters
.
}
else
// never called unless I hit Cancel (or exceed 4K)
TRACE("Error in GetOpenFileName!\n");
-mike
mfox@matrox.com
Mike Blaszczak -- mikeblas@nwlink.com
Sunday, March 16, 1997
[Mini-digest: 2 responses]
At 14:08 3/13/97 -0800, Keith Rollin wrote:
>>>-----From: jimt1@voicenet.com (Jim Tannenbaum)
>>>You are probably doing everything correctly, except trying to open too
>>>many files at once! By convention ANSI C (& derivatives) limit you to
20 or
>>>so files.
>>This is entirely wrong. The ANSI C standard nor the proposed ANSI C++
>>standard do not provide or suggest such a limitation.
>Perhaps I'm thinking about something else, but I'm pretty sure the C
>Standard _does_ allow for an upper limit on the number of open files.
>I don't have my copy here with me, but a net-search turns up the following:
> FOPEN_MAX
> [...]
Yep: the C Standard does explain this symbol. But the symbol is just
a mechanism for implementers of a C Runtime Library to express any limit
they might have built into the library.
The standard _doesn't_ enforce a limit, though. That is, the standard says
"if the library has a limit on the number of files which could be opened,
it should express that limit via the FOPEN_MAX symbol". It does _not_ say
what Jim Tannenbaum said; that is, it does _not_ say "the library is limited
to having twenty files open via fopen() at any one time".
> The number of streams that may be open simultaneously is not
> specifed; in ISO C it is given by the value of the macro FOPEN_MAX,
> which must be at least eight...
Right: again, Jim's statement that ANSI C limits the nubmer of open files
is wrong. It is correct that, if such a static limit exists, the
implementation should express that limit via the FOPEN_MAX symbol. Enforcing
the limit and providing a mechanism which a possible limit might be expressed
are two wildly different things.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
One is too many and a million is not enough.
-----From: jimt1@voicenet.com (Jim Tannenbaum)
OK I give up. I thought I remembered it as an ANSI standard. No, I can't
find where I read it. However, The _NFILES constant was defined in MS C 7.0
& it is currently defined in MS VC 1.52. I apologize to all for my mistake
and mis-information.
Thank you (again) to Mike B. and Keith for setting me straight on the standard.
Jet
>>[Mini-digest: 4 responses]
>>
>>>-----From: jimt1@voicenet.com (Jim Tannenbaum)
>>>You are probably doing everything correctly, except trying to open too
>>>many files at once! By convention ANSI C (& derivatives) limit you to 20 or
>>>so files.
>>
>>This is entirely wrong. The ANSI C standard nor the proposed ANSI C++
>>standard do not provide or suggest such a limitation.
>>...
>>.B ekiM
>>http://www.nwlink.com/~mikeblas/
>>These words are my own. I do not speak on behalf of Microsoft.
>> This performance was not lip-synched.
>
>
>Perhaps I'm thinking about something else, but I'm pretty sure the C
Standard _does_ allow for an upper limit on the number of open files. I
don't have my copy here with me, but a net-search turns up the following:
>
> FOPEN_MAX
>
> #define FOPEN_MAX = 8>
>
> The macro yields the maximum number of files that the target
> environment permits to be simultaneously open (including stderr,
> stdin, and stdout).
>
>Additionally, the book I usually thumb through to settle issues like these
("C: A Reference Manual", by Harbison and Steele) says:
>
> The number of streams that may be open simultaneously is not
> specifed; in ISO C it is given by the value of the macro FOPEN_MAX,
> which must be at least eight...
>
>I'm not arguing with the fact that you were actually able to open more than
the specified limit, and agree with the assessment that the problem was with
NT. I'm just trying to comment on the C Standard issue.
>
>--------------------------------------------------------------------------
>Keith Rollin --- Newton Systems Group --- Apple Computer, Inc.
> "Quidquid latine dictum sit, altum viditur."
>
>
>
>
JJM Systems, Inc Phone: (215) 672-3660 Ext 16
1 Ivybrook Blvd, Suite 190 Fax: (215) 672-5702
Ivyland, PA 19874 Net: jimt1@voicenet.com
C. Zhang -- cz17309@goodnet.com
Wednesday, March 19, 1997
All in all, let's fix the problem. WinNT can handle a lot more than 20
files even DOS can do better. The absolute limit for DOS and Win3.X is
250 files. The 20-file limit is set by the C Library. You can remake the
library to increase the file limit. I did it in VC++ 1.52 but not in
VC++ 4.0 or above because opening all those files at once is not a good
practice unless you have to. I downloaded the C run-time library code
from Microsoft and simply recompiled it. You can download the 32-bit C
run-time library from Microsoft and recompile it as well.
Mike Blaszczak wrote:
>
> [Mini-digest: 2 responses]
>
> At 14:08 3/13/97 -0800, Keith Rollin wrote:
>
> >>>-----From: jimt1@voicenet.com (Jim Tannenbaum)
> >>>You are probably doing everything correctly, except trying to open too
> >>>many files at once! By convention ANSI C (& derivatives) limit you to
> 20 or
> >>>so files.
>
> >>This is entirely wrong. The ANSI C standard nor the proposed ANSI C++
> >>standard do not provide or suggest such a limitation.
>
> >Perhaps I'm thinking about something else, but I'm pretty sure the C
> >Standard _does_ allow for an upper limit on the number of open files.
> >I don't have my copy here with me, but a net-search turns up the following:
>
> > FOPEN_MAX
> > [...]
>
> Yep: the C Standard does explain this symbol. But the symbol is just
> a mechanism for implementers of a C Runtime Library to express any limit
> they might have built into the library.
>
> The standard _doesn't_ enforce a limit, though. That is, the standard says
> "if the library has a limit on the number of files which could be opened,
> it should express that limit via the FOPEN_MAX symbol". It does _not_ say
> what Jim Tannenbaum said; that is, it does _not_ say "the library is limited
> to having twenty files open via fopen() at any one time".
>
> > The number of streams that may be open simultaneously is not
> > specifed; in ISO C it is given by the value of the macro FOPEN_MAX,
> > which must be at least eight...
>
> Right: again, Jim's statement that ANSI C limits the nubmer of open files
> is wrong. It is correct that, if such a static limit exists, the
> implementation should express that limit via the FOPEN_MAX symbol. Enforcing
> the limit and providing a mechanism which a possible limit might be expressed
> are two wildly different things.
>
> .B ekiM
> http://www.nwlink.com/~mikeblas/
> These words are my own. I do not speak on behalf of Microsoft.
> One is too many and a million is not enough.
> -----From: jimt1@voicenet.com (Jim Tannenbaum)
>
> OK I give up. I thought I remembered it as an ANSI standard. No, I can't
> find where I read it. However, The _NFILES constant was defined in MS C 7.0
> & it is currently defined in MS VC 1.52. I apologize to all for my mistake
> and mis-information.
>
> Thank you (again) to Mike B. and Keith for setting me straight on the standard.
>
> Jet
>
> >>[Mini-digest: 4 responses]
> >>
> >>>-----From: jimt1@voicenet.com (Jim Tannenbaum)
> >>>You are probably doing everything correctly, except trying to open too
> >>>many files at once! By convention ANSI C (& derivatives) limit you to 20 or
> >>>so files.
> >>
> >>This is entirely wrong. The ANSI C standard nor the proposed ANSI C++
> >>standard do not provide or suggest such a limitation.
> >>...
> >>.B ekiM
> >>http://www.nwlink.com/~mikeblas/
> >>These words are my own. I do not speak on behalf of Microsoft.
> >> This performance was not lip-synched.
> >
> >
> >Perhaps I'm thinking about something else, but I'm pretty sure the C
> Standard _does_ allow for an upper limit on the number of open files. I
> don't have my copy here with me, but a net-search turns up the following:
> >
> > FOPEN_MAX
> >
> > #define FOPEN_MAX = 8>
> >
> > The macro yields the maximum number of files that the target
> > environment permits to be simultaneously open (including stderr,
> > stdin, and stdout).
> >
> >Additionally, the book I usually thumb through to settle issues like these
> ("C: A Reference Manual", by Harbison and Steele) says:
> >
> > The number of streams that may be open simultaneously is not
> > specifed; in ISO C it is given by the value of the macro FOPEN_MAX,
> > which must be at least eight...
> >
> >I'm not arguing with the fact that you were actually able to open more than
> the specified limit, and agree with the assessment that the problem was with
> NT. I'm just trying to comment on the C Standard issue.
> >
> >--------------------------------------------------------------------------
> >Keith Rollin --- Newton Systems Group --- Apple Computer, Inc.
> > "Quidquid latine dictum sit, altum viditur."
> >
> >
> >
> >
>
> JJM Systems, Inc Phone: (215) 672-3660 Ext 16
> 1 Ivybrook Blvd, Suite 190 Fax: (215) 672-5702
> Ivyland, PA 19874 Net: jimt1@voicenet.com
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, March 22, 1997
At 10:00 3/19/97 -0800, C.Zhang wrote:
>All in all, let's fix the problem.
Handing out more confusing information is no way to fix any problem.
>WinNT can handle a lot more than 20
>files even DOS can do better. The absolute limit for DOS and Win3.X is
>250 files. The 20-file limit is set by the C Library. You can remake the
>library to increase the file limit. I did it in VC++ 1.52 but not in
>VC++ 4.0 or above because
Actually, the reason you've not rebuilt the library in VC++ 4.0 or above
is because the limitation doesn't exist in that version of the runtime
library. And that limitation isn't in any newer version of the compiler,
either. Further, I'm pretty sure that the limitation doesn't exist in
any 2.x versions, but I don't have the CDs here at home to double check.
The previous notes I've posted with this subject explain that. The
sample code I wrote and included in one of those notes demonstrates
that the limit doesn't exist. As I said in that note, the limit on open
stream files is 512. With just a couple minutes more research, one
could find that this is the default limit. One can use the
_setmaxstdio() function to increase that limit. The limit can't be
increased past 2048 files.
_setmaxstdio() is documented in the online help.
>opening all those files at once is not a good
>practice unless you have to.
It's not a good practice to use _any_ resource that you don't have to
really use. Only a fool would knowingly allocate memory or files our
brushes or _anything_ that they didn't really need. There are lots of
applications which might require that you have more than twenty files
open. (The librarian, linker and compiler you're using to build
programs are great examples of programs where that might happen, as
a scratch-built database applications.)
>downloaded the C run-time library code
>from Microsoft and simply recompiled it. You can download the 32-bit C
>run-time library from Microsoft and recompile it as well.
You don't have to download the 32-bit runtime library code from Microsoft.
It's right there on the product CD. The only 32-bit version of the product
that didn't have source on the CD was 2.0.
I can't believe the number of incorrect answers this thread has generated.
The confusion surrounding this issue just amazes me. Look, here are the
facts:
In 16-bit versions of the C Runtime library, a limit of 20 open
STDIO files exists. You can rebuild the library following some
instructions available in a KB article to avoid the limitation.
The 16-bit evrsions of the runtime library express the limit
of available files via a preprocessor macro.
In 32-bit versions, no static limit exists in the libraries. The
libraries don't express a preprocessor macro for the limit because
there is no sstatic limit imposed by the libraries. You can use
the _setmaxstdio() function to set the limit if you don't like the
default of 512.
The C language standard does _not_ dictate that there is a limit
on the number of open files. The C language standard _does_ provide
for a preprocessor symbol which library implementers can use
if they do have such a limit and need to express it, but this doesn't
mean that the library actually mandates the limit.
If anyone still doesn't understand what's going on here, write to
me privately and I'll be happy to help. If you want to post bad answers
and misconceptions and incorrect information to the list, go right ahead:
I can't stand writing these corrections anymore.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
One is too many and a million is not enough.
Become an MFC-L member
| Вернуться в корень Архива
|