Re: [Freedos-devel] IFS API
On 2/23/2023 9:44 AM, Liam Proven wrote: On Wed, 22 Feb 2023 at 23:12, Ralf Quint wrote: I was jogging my memory a bit, and there was a specially NLM that needed to be loaded on NW3.12 and NW 4.0 at least to get "long filename support". That's right. I believe it was called `OS2.NLM` because the support Novell had already implemented for OS/2's long file names worked fine for newer clients as well. Well, it was OS2.NLM for Netware 3.1x up to 4.10, for 4.11, they named it LONG.NLM. I think starting with Netware 5.0, it was a build-in module, no need to load a special name space anymore. But by that time, the easy use of Netware was gone IIRC, and this is fainter, there was a different `MAC.NLM` for classic MacOS support, which did rather more -- both data and resource forks -- and you were recommended _not_ to try to use that one. Yeah, that one I remember wasn't very popular, when thinking about that one, actually old "MC Hammer" comes into my head, "can't touch that"... 😛 AIUI, Netware's native filesystem didn't actually have subdirectories. It was flat and used hashing to simulate a hierarchical filesystem for clients. Don't recall anything like this. Also hard to imagine, given the way how they handled permissions. After all, you wouldn't even see sub directories you didn't have the rights to access (one of the stupid things in Windows,). IIRC, when trying once to do some data recovery on a Netware drive with the help of some folks at Compaq, it was very similar to a FAT filesystem. Novell never published any technical info about the file system and the guys at Compaq could only give me hints over the phone, they had tech info from Novell but were not allowed to share anything in hard copy from that... A low-priority task for me is to get a Netware server running again. I have a copy of Netware 6.8 SP $last sitting around somewhere, but foolishly, when I worked for Micro Focus, I failed to obtain a staff licence key for it. >_< I never used anything past 4.11, they tried to compete too much with NT Server at that time already and everything from 5.0 and up was a hot mess. Might have to check if anyone ever continued to work on MARSNWE, which looked promising for a while until the original author dropped it. Just saw that a couple of years ago, it had been put up on GitHub (GitLab?) Have a server (I think it's a 486 with 16MB RAM and something like a 1.2GB data drive), running a 10 user Netware 3.12, sitting hidden in my storage, something like this would be a great "companion" to FreeDOS... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
> But being MS-DOS 5.0 published when it was, after the quarrel with > IBM, I can just speculate that if MS-DOS 5.0 needed more > conventional memory, IFS would have been one of the first things to > go. Which is a pity, because from those articles one can infer that > it tried to make mounting file systems less reliant on MS-DOS > internal structures. A good idea for which your 16-bit PC has not > enough memory :) I'm doing experiments with my TSR's that allow them to use MUCH less memory than normal by putting parts of themselves into EMS or DPMS memory. Using these methods, it's possible to make even a really big, complicated TSR or device driver require only a few kB of Conventional or Upper Memory. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, El jue, 23 feb 2023, 0:19, Bret Johnson escribió: > > Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC > > functions seem to be entangled with the network redirector > > functions: > > > > http://www.ctyme.com/intr/int-2f.htm > > > > Apparently, these functions would be made available by IFSFUNC.EXE > > (curiously not provided by kernel itself). > >... > > My conclusion would be that it looks like an alternative > > functionality update to the network redirector itself (and not > > something entirely unrelated), that tried to solve some of the > > previous problems and/or tried to be more abstract and less tied to > > internal DOS structures, that was implemented only in DOS 4.0, > > probably to try and make HPFS available for DOS, but that was later > > abandoned (due probably to high memory requirements) in favour of > > maintaining the old redirector). > > That's kind of an interesting take, but it's ultimately not what I would > like to see. I would like things to be "embedded" as a kernel extension so > additional drives can simply be "plugged in". That's how my USBDRIVE > program currently works. > > What I do with USBDRIVE is "inject" the USB drive information into the > various DOS tables (like the CDS & DPB structures) and the device driver > chain as needed. DOS itself already knows how to process FAT12/FAT16 and > (in some cases) FAT32 partitions/disks. I leverage that capability so that > the USB driver doesn't need to handle it. The USB driver basically just > gives DOS access to the sectors and DOS processes the data that's in the > sectors. As USB disks get plugged and unplugged the various DOS tables get > updated but DOS already knows how to handle that (DOS can handle removable > disks with different sizes that all use the same drive letter). > > I would like to see a similar setup for additional drive formats (like > exFAT or HPFS or NTFS or UDF or whatever). Something where the driver has > "slots" that different disks can be "plugged" into in real time and the > software automatically adjusts itself to the disk that's currently > installed. I've not studied the network director to know if something like > that is even possible, but is what' I'd _like_ to see for future > flexibility and compatibility. > Well, I think it's hard to know which were the extra features of IFS over the already existing network redirector. This feature (I would include it as hot plug'n play) could be one, because it's probably IFS which increased a lot the conventional memory consumption of MS-DOS 4 over 3.x. However I find it unlikely. My bet is that IFS included the minimum necessary to mount HPFS in DOS. In one of the aforementioned articles, there's a funny comparison between MS-DOS 4/5 and Windows Vista/7. The former being undeservedly guilty of horrible memory consumption and the latter seen as a leaner savior. I can't know the story from my own experience, because I jumped from MS-DOS 3.30 to 6.00 (yeah I lived DOUBLESPACE and not DRIVESPACE). But being MS-DOS 5.0 published when it was, after the quarrel with IBM, I can just speculate that if MS-DOS 5.0 needed more conventional memory, IFS would have been one of the first things to go. Which is a pity, because from those articles one can infer that it tried to make mounting file systems less reliant on MS-DOS internal structures. A good idea for which your 16-bit PC has not enough memory :) > *** > > As an aside, I'm wondering if anybody has a "fool-proof" test for FAT32 > capability in the kernel. In USBDRIVE what I currently do is go through > all the drive letters and see if any of them responds correctly to INT > 21.7302h (Get Extended BPB). This test works if there is at least one > existing FAT32 drive letter, but will fail if there are no actual FAT32 > partitions even if the kernel supports FAT32. I don't know of a direct or > fool-proof way to detect FAT32 support, but maybe somebody else has come up > with something. > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
On Wed, 22 Feb 2023 at 23:12, Ralf Quint wrote: > > I was jogging my memory a bit, and there was a specially NLM that needed > to be loaded on NW3.12 and NW 4.0 at least to get "long filename > support". That's right. I believe it was called `OS2.NLM` because the support Novell had already implemented for OS/2's long file names worked fine for newer clients as well. IIRC, and this is fainter, there was a different `MAC.NLM` for classic MacOS support, which did rather more -- both data and resource forks -- and you were recommended _not_ to try to use that one. AIUI, Netware's native filesystem didn't actually have subdirectories. It was flat and used hashing to simulate a hierarchical filesystem for clients. A low-priority task for me is to get a Netware server running again. I have a copy of Netware 6.8 SP $last sitting around somewhere, but foolishly, when I worked for Micro Focus, I failed to obtain a staff licence key for it. >_< -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
>> I don't know of a direct or fool-proof way to detect FAT32 support, >> but maybe somebody else has come up with something. > > I believe DJGPP utils (2.04 beta or newer, e.g. 2.05 current) use > the naive method of "only assume FAT32 if DOS version is 7". (By > this I mean "du.exe","df.exe" etc. will then use INT 21h, 7303h.) That was the way I tried it at first, too, and it really doesn't work. FAT32 first showed up in Windows 95B (not Windows 95) so the DOS version test doesn't work reliably. Relying on a DOS version for specific features or internal structure characteristics just generally isn't very reliable, except with early versions of DOS where MS and IBM were the only manufacturers. As more competitors entered the fray identifying the specific manufacturers and versions and their compatibilities became almost impossible. It's even worse now with the advent of Virtual Machines. > "INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE" > * http://www.delorie.com/djgpp/doc/rbinter/id/40/32.html I just did a little bit of testing with that one and it has some potential. At least under MS-DOS 7.1 (Windows 98) and FreeDOS 1.3, it returns valid information even for FAT16 partitions. But under DOSBox it returns an error even when accessing a real FAT32 partition. I'll need to experiment with that one a little more -- it may be a better option than what I'm doing now, or I may need to do multiple tests. > What about INT 21h, 71A0h? (Admittedly, it may assume the Win95 LFN > API is available.) > >"INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION" > * http://www.delorie.com/djgpp/doc/rbinter/id/23/32.html That is actually an LFN function, not a FAT32 function. A lot of people think LFN and FAT32 are "cousins" since they both showed up at around the same time, but you can have one without the other. Even a floppy disk (FAT12) can have LFNs. Also, not all LFN features are supported by all LFN drivers. I think INT 21.71A0 may only be supported by Windows itself and not by the "aftermarket" LFN drivers (DOSLFN, LFNDOS, StarLFN, etc.), but don't know for sure. The way I detect LFN support is with INT 21.7147 (LFN - Get Current Directory) which seems to work with all LFN drivers. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
