Re: Current Directory Structure (CDS) limitations

FoxWolfie Galen wrote:
| On Wed, 31 Dec 2008 12:27:19 +0200, Luchezar Georgiev
| <lucho@xxxxxxxxx> wrote:
|
|| However while attempting to delete these directories I got a "4DOS
|| internal stack overflow" at the 16th level. This sets a practical
|| limit of 15 levels for 4DOS, which is more than enough in my opinion
|| for 99.999% of the cases.
|
| You are correct. I always heard people refer to an 8 directory limit,
| but never tested it until just now. I see that I can go to 32 levels.
| Doing a real-world test, I tried to access the files in my browser
| cache from 4DOS. I got mixed results. My browser cache is located at:
|
| C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\
|
| I can go into the directory using 4DOS, but because all the files in
| that directory result in a pathname of over 67 characters, they could
| not be accessed at all, if I booted to plain 4DOS, without Windows.
| When I rebooted under Win98se, and started 4DOS from Windows, I was
| able to access files in directories that were over 100 characters
| deep. 4DOS appears to be smart enough to hook into some Windows LFN
| APIs if it sees them, under Win9x. Seeing this work under Win98se, I
| just had to try it on an NT-based system. I installed 4DOS on my XP
| system and attempted to access anything in a longer-than 67-character
| directory. It failed. I tried with LFN support both on and off. 4DOS
| can see the LFNs, but it cannot access the large number of files that
| are stored in the deeper directories. What works so nicely in Win 9x
| does not work at all in Win XP.
|
| I did *not* see a stack overflow when attempting to delete files or
| directories at any level on any system. I deleted the directories
| using RD, one level at a time, with no errors. As expected, no
| path\filename combination could exceed 67 characters, if I booted
| without Windows, or if I was in XP. TCC/LE had no problem with
| directories that 4DOS could not access in XP.
|
| I just proved to myself that 4DOS likes Win 98, but it doesn't appear
| to like Win XP as much. It still works in XP, but only within certain
| limits, and enabling LFN support does not remove some of those
| limits. Under normal circumstances, I'll still recommend 4NT/TCC/LE
| to people using NT systems, and 4DOS to people using DOS and 9x/ME
| systems. Of course, my recommendations are biased by what has worked
| best for me. Other people's experiences may vary.

AFAIK the problem is that M$ wants people to buy new versions of programs,
and thus provides only very limited DOS emulation in XP via NTVDM. The
primary method to overcome many of the path length and depth limits is
SUBST. It works for 4DOS, and it works for any other DOS program, e.g.,
Lotus Magellan 2.0 and BRIEF.
--
Steve

.

Relevant Pages

  • Re: Thread Limits
    ... Threads are expensive resources in Windows use them sparingly, ... has it's own stack space which limits the number of ... Is there a limit for threads on Windows? ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Thread Limits
    ... Threads are expensive resources in Windows use them sparingly, ... has it's own stack space which limits the number of ... Is there a limit for threads on Windows? ...
    (microsoft.public.dotnet.general)
  • Re: writing overlays with VB6
    ... But there have been aditional limits in windows like system resources which disallowed programs to grow up and use all of the available virtual memory. ... only to find they confer no actual improvement whatsoever. ...
    (microsoft.public.vb.winapi)
  • Re: Virtual memory
    ... limits as recommended? ... |>> Windows help suggests putting the Page file onto the ...
    (microsoft.public.windowsxp.basics)
  • Re: RowFilter and stackoverflow
    ... Although I don't know if the limits of the Expression is documented, ... > What I am doing is for example trying to filter a dataset for certain ... > So I create a dataview and filter the dataview ... >> When it is this and blows up your program because a stack overflow I ...
    (microsoft.public.dotnet.languages.vb)