Re: [Freedos-devel] Needs testing: SJGPlay

[Michael Brutman]

In the year 2023 does FreeDOS really need a command line utility to tell a
CD-ROM to play a music track?

Except for the novelty of it, I don't know anybody who would listen to
music this way.  It's an anachronism from the mid 1990s.


Mike
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Rugxulo]

Hi,

On Sun, Feb 19, 2023 at 7:39 PM Aitor Santamaría  wrote:
>
> Does anyone know if the IFS (Installable File System) API is documented 
> anywhere?

I have no idea if this link will help you, but I'm mentioning it "just
in case" (because it sounds useful and impressive).

* https://ecsoft2.org/ihpfs

Basically, it's a read-only HPFS driver for DOS (last updated by Veit
Kannegieser).


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] More on Packages

[Rugxulo]

Hi,

On Mon, Feb 20, 2023 at 1:37 PM  wrote:
>
> Other possible new packages to consider for inclusion (or at least watch):
>
> 386SWAT - GPLv3, Debugger (may require someone to compile)
> https://github.com/sudleyplace/386SWAT

You mean the old compile isn't sufficient? (IIRC, it was on his website.)

> GW-BASIC - MIT License, Microsoft’s original 1983 version
> https://github.com/microsoft/GW-BASIC

Personally, I would rather have a package for P5 Pascal. (Although
both is fine, too.)
(But my .ZIP was old 1.1, and I never got around to testing or
building 1.4 for us. No huge differences, just better error-checking,
supposedly.)

> DIFPAT, GPLv2, DIFF and PATCH Utilities
> https://github.com/deverac/difpat

Haven't tried these. Usually I just use the 32-bit DJGPP builds of the
GNU ones. If these are really 16-bit, that'd be cool. (There are other
tools in the wild, too, especially for non-text binaries.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Needs testing: SJGPlay

[Rugxulo]

Hi again,

On Mon, Feb 20, 2023 at 7:31 PM Rugxulo  wrote:
>
> On Sun, Feb 19, 2023 at 3:58 PM Jim Hall  wrote:
>
> I haven't checked the new sources (IIRC, it was said to be BASIC ...
> PowerBASIC??). Does it also include ACD kit (or whatever third-party
> lib)?

This release does not include the sources to "ACDkit", only binary
files (libs, etc). Can this be fixed? Who wrote ACDkit? Where is it
currently found? What is the license? (Do we need a replacement? It
can't be THAT hard!)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Rugxulo]

Hi,

On Mon, Feb 20, 2023 at 6:41 PM Ralf Quint  wrote:
>
> (just for example, DOS maintains
> only one single date for a file, "Time modified", while on NTFS and
> OS/2, you have additionally, "Time created", "Time access" as well.

Some OSes do update "time created" for FAT. (There was a patch for the
FreeDOS kernel in recent years, but I can't remember if it was ever
officially included.) IIRC, "ctime" wasn't normally available to DOS
itself unless DOSLFN (or similar) was loaded. I think (once loaded)
DJGPP utils would then read it correctly. I did vaguely find that
useful sometimes.

But "access time" is often shunned as wearing out the drive for little
reason, so (naively) I thought most Linux distros mounted as
"noatime".


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Needs testing: SJGPlay

[Rugxulo]

Hi again,

On Mon, Feb 20, 2023 at 7:31 PM Rugxulo  wrote:
>
> On Sun, Feb 19, 2023 at 3:58 PM Jim Hall  wrote:
> >
> I used to use SJGPlay a lot (back in the day). I loved it. But I
> haven't tried again in many years.
>
> > Could anyone with a CD player and a sound card on their computer
> > please test SJGPlay with actual music CDs

I found some old 2007 emails I sent him:

>>> I can't get SJGPlay for DOS to work under XP. Windows 95/95 no problem. Ah, 
>>> the price of progress.
>>> Freebasic looks interesting. I should try compiling SJGPlay with it someday.

The old .EXE worked fine (years ago), so unless something changed
(i.e. recompiled with different tools), then it shouldn't be a
problem.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Needs testing: SJGPlay

[Rugxulo]

Hi,

On Sun, Feb 19, 2023 at 3:58 PM Jim Hall  wrote:
>
> I wanted to start a new thread for this request. Based on the
> discussion from the "FreeDOS package issues" thread, Jerome identified
> that the CDP package didn't include source code. Robert suggested
> SJGPlay as a replacement.

I used to use SJGPlay a lot (back in the day). I loved it. But I
haven't tried again in many years. (I liked the karaoke aspect even if
I don't sing.) It was very well made.

> Could anyone with a CD player and a sound card on their computer
> please test SJGPlay with actual music CDs and comment here if SJGPlay
> works well. (I don't have a CD drive on any of my computers, so I
> can't test this myself.)

I haven't checked the new sources (IIRC, it was said to be BASIC ...
PowerBASIC??). Does it also include ACD kit (or whatever third-party
lib)?

(Eric's CDROM2 is maybe too minimal, but I still found it cool.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/20/2023 1:52 PM, Aitor Santamaría wrote:

Hello Eric,

More than useable, it was just a question of historical curiosity.

In a very long time ago posted thread  (I haven't tested myself) it 
was suggested that the redirector API does not work well with LFNs. I 
am not suggesting that the unmaintained DOS IFS would do, but I was 
curious to know how do these two different approaches to third party 
filesystems (redirector and IFS) compare to each other, and how they 
both deal with: LFNs, case sensitivity, unicode names, big files, and 
a long etc.


That is not very surprising, as the DOS network redirector was devised 
well before long filenames became a thing with Windows 95B. And I do 
recall that even with MS-DOS and early Windows clients, there were 
filename issues when accessing OS/2, as that was IIRC one of those 
"extended attributes" that OS/2 introduced, similar to what at the same 
time became the additional attributes supported by NTFS on Windows NT 
4.0 and subsequent Windows versions... (just for example, DOS maintains 
only one single date for a file, "Time modified", while on NTFS and 
OS/2, you have additionally, "Time created", "Time access" as well. And 
of course all the permission stuff, which just didn't exist in DOS as a 
single user, single tasking OS...



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/20/2023 1:03 PM, Eric Auer wrote:


Hi! As we have various drivers which use the network redirector API,
CD/DVD redirector API or both, including drivers which use those for
different purposes, which advantage do we expect from using a special
IFS API which is both "more on topic" and "less existing", as in only
very specific DOS versions may have supported it? My impression was
that things like vmsmount and etherdfs work fine without that API :-)

Also note that the low-level format is not visible through IFS, so it
does not matter whether you use FAT32, FAT16 or NTFS. However, it may
matter whether you want long file names or files > 2 GB. For those,
I hope that the usual Win9x DOS 7.x int 21 calls have counterparts in
the network and CD redirector API space of the same DOS generations. 
Yes, the network redirector "hides" the actual implementation of the 
remote/server side. For example, Novell Netware had a totally different 
file system, with very granular permissions and longer file names than 
DOS (and early Windows 95) supported. And as I mentioned in an earlier 
reply to Aitor, I just can't recall right now how this was handled in 
Novell. I would have to try and dig out some of my old sources for some 
utilities that I wrote for Novell under DOS, including a revision 
control system that we used at a former employer.


And yes, it would be interesting to check how vmsmount handles that, but 
as I mentioned, that MSCDEX specification is the only "official" source 
that I can find still. Unless someone can dig out anything else on any 
of the multitude of MSDN CDs, which I think might be the only other 
possible source. I checked (before Aitor's question) for some info on 
this and could not find anything on Microsoft's web site anymore, only 
404s...



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/20/2023 12:51 PM, Mercury Thirteen via Freedos-devel wrote:
If it was in fact removed from the "official" MS-DOS, and one wanted 
to (re)implement it anyway, perhaps browsing the code of the 
open-source recreation of OS/2 would help? It has a FAT32 driver which 
is compatible with the OS/2 IFS and, as I recall, OS/2 was more of a 
direct successor to MS-DOS than Windows ever was, so perhaps its code 
would be more helpful to a DOS dev as opposed to the Windows versions.


Not sure, I haven't dug too deeply into that myself, but hope it 
possibly helps.


https://www.arcanoae.com/wiki/fat32/

FAT32 is pretty much just an extension of the FAT system which is after 
all the underlaying filesystem since DOS 1.0 (and 86-DOS, as that is 
what Paterson gleaned from Marc MacDonald at Microsoft), it is not an 
additional "installable filesystem". Don't know right now how long 
filenames are being handled, but as they only came out with Windows 95B 
(and I don't recall right now how this was exactly handled on Novell :( 
), it was well after DOS...



Ralf

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/20/2023 11:58 AM, Aitor Santamaría wrote:

Thanks, Ralf!!

So I thought, but I have read a couple of references (such as the 
following in Wikipedia, but not the only one) by which the IFS was 
present in MS-DOS 4.X, of course as well as in OS/2 and Windows:


Installable File System - Wikipedia 



Apparently, there was some support for it that was probably removed 
for MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)


In RBIL, the only reference I've found is to IFSHLP.SYS, which was a 
Windows mean to guess what has been installed before getting into 
protected mode, so I am not sure is if this has to be with the IFS 
that was planned and implemented in MS-DOS 4.0.


Windows and OS/2 are totally different ball games. In DOS, as long as I 
can remember, only the network redirector existed. That MSCDEX.TXT that 
I mentioned I think tries to explain that as well...


Don't recall when MSCDEX first showed up, but I think it was after the 
networking redirector stuff (for both Novell and LanManager) in MS-DOS 3.0.



Ralf

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Aitor Santamaría]

Hello Eric,

More than useable, it was just a question of historical curiosity.

In a very long time ago posted thread  (I haven't tested myself) it was
suggested that the redirector API does not work well with LFNs. I am not
suggesting that the unmaintained DOS IFS would do, but I was curious to
know how do these two different approaches to third party filesystems
(redirector and IFS) compare to each other, and how they both deal with:
LFNs, case sensitivity, unicode names, big files, and a long etc.

Aitor



On Mon, 20 Feb 2023 at 22:04, Eric Auer  wrote:

>
> Hi! As we have various drivers which use the network redirector API,
> CD/DVD redirector API or both, including drivers which use those for
> different purposes, which advantage do we expect from using a special
> IFS API which is both "more on topic" and "less existing", as in only
> very specific DOS versions may have supported it? My impression was
> that things like vmsmount and etherdfs work fine without that API :-)
>
> Also note that the low-level format is not visible through IFS, so it
> does not matter whether you use FAT32, FAT16 or NTFS. However, it may
> matter whether you want long file names or files > 2 GB. For those,
> I hope that the usual Win9x DOS 7.x int 21 calls have counterparts in
> the network and CD redirector API space of the same DOS generations.
>
> Regards, Eric
>
>
>
>
> ___
> 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

[Aitor Santamaría]

Many thanks!
Interesting link.

On Mon, 20 Feb 2023 at 21:52, Mercury Thirteen via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> If it was in fact removed from the "official" MS-DOS, and one wanted to
> (re)implement it anyway, perhaps browsing the code of the open-source
> recreation of OS/2 would help? It has a FAT32 driver which is compatible
> with the OS/2 IFS and, as I recall, OS/2 was more of a direct successor to
> MS-DOS than Windows ever was, so perhaps its code would be more helpful to
> a DOS dev as opposed to the Windows versions.
>
> Not sure, I haven't dug too deeply into that myself, but hope it possibly
> helps.
>
> https://www.arcanoae.com/wiki/fat32/
>
>
>
> Sent with Proton Mail  secure email.
>
> --- Original Message ---
> On Monday, February 20th, 2023 at 2:58 PM, Aitor Santamaría <
> aitor...@gmail.com> wrote:
>
> Thanks, Ralf!!
>
> So I thought, but I have read a couple of references (such as the
> following in Wikipedia, but not the only one) by which the IFS was present
> in MS-DOS 4.X, of course as well as in OS/2 and Windows:
>
> Installable File System - Wikipedia
> 
>
> Apparently, there was some support for it that was probably removed for
> MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)
>
> In RBIL, the only reference I've found is to IFSHLP.SYS, which was a
> Windows mean to guess what has been installed before getting into protected
> mode, so I am not sure is if this has to be with the IFS that was planned
> and implemented in MS-DOS 4.0.
>
> Aitor
>
>
>
>
>
>
>
>
>
>
>
> On Mon, 20 Feb 2023 at 18:27, Ralf Quint  wrote:
>
>> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
>> > Hello,
>> >
>> > Does anyone know if the IFS (Installable File System) API is
>> > documented anywhere?
>> >
>> Just checked in my archive of docs, and there is a MSCDEX.TXT, which
>> describes the interface for the CD-ROM "network redirector".
>>
>> It can apparently be found online at
>> https://cybermax.tripod.com/mscdex.txt
>>
>>
>> Ralf
>>
>>
>>
>>
>> ___
>> 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
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] More on Packages

[Louis Santillan]

On Mon, Feb 20, 2023 at 11:37 AM  wrote:
[SNIP]
> Other possible new packages to consider for inclusion (or at least watch):
[SNIP]
>
> GW-BASIC - MIT License, Microsoft’s original 1983 version
> https://github.com/microsoft/GW-BASIC

tkchia has a better branch that should be easier to compile and will
be more complete.
https://github.com/tkchia/GW-BASIC

>
> DOSLINUX - GPLv3, DOS Subsystem for Linux
> Run real linux programs under DOS.
> Why? IDK. (requires someone to compile)
> https://github.com/haileys/doslinux

I also have some notes on how to build.  I integrated those steps into
the repo below.
https://sites.google.com/view/lpsantil/home/dos-subsystem-for-linux-on-a-hp-t5745

The repo below should make it easier to build a package.
https://github.com/lpsantil/doslinux

In terms of purpose, DOSLINUX is a lot like the VFAT Linuxes from 20
years ago BasicLinux (https://distro.ibiblio.org/baslinux/) and Dragon
Linux (https://web.archive.org/web/20010401131118/http://dragonlinux.org/)
and phatlinux 
(https://web.archive.org/web/20040901031901/http://phatlinux.com/).
An easy way to install and boot Linux without having to understand the
nuances of Linux installation. DOSLINUX does substitute LILO for it's
own dsl Linux loader, and, can be used with a modern version of
busybox instead of ancient versions of GNU tools.  Unlike other
distros, it's intended to return to DOS once a command is complete.
However, if you pass dsl an interactive command, like /bin/sh, it will
continue to run.  I can see potential uses for making an improved,
single-reboot DOS installer (format, partition, install on first
boot!), gaining access to useful hardware or software for which DOS
has no software (I'm looking at you USB 3.0).

One other command that might be interesting to add to FreeDOS is the
fast compressor/decompressor LZ4.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Eric Auer]

Hi! As we have various drivers which use the network redirector API,
CD/DVD redirector API or both, including drivers which use those for
different purposes, which advantage do we expect from using a special
IFS API which is both "more on topic" and "less existing", as in only
very specific DOS versions may have supported it? My impression was
that things like vmsmount and etherdfs work fine without that API :-)

Also note that the low-level format is not visible through IFS, so it
does not matter whether you use FAT32, FAT16 or NTFS. However, it may
matter whether you want long file names or files > 2 GB. For those,
I hope that the usual Win9x DOS 7.x int 21 calls have counterparts in
the network and CD redirector API space of the same DOS generations.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Mercury Thirteen via Freedos-devel]

If it was in fact removed from the "official" MS-DOS, and one wanted to 
(re)implement it anyway, perhaps browsing the code of the open-source 
recreation of OS/2 would help? It has a FAT32 driver which is compatible with 
the OS/2 IFS and, as I recall, OS/2 was more of a direct successor to MS-DOS 
than Windows ever was, so perhaps its code would be more helpful to a DOS dev 
as opposed to the Windows versions.

Not sure, I haven't dug too deeply into that myself, but hope it possibly helps.

https://www.arcanoae.com/wiki/fat32/

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Monday, February 20th, 2023 at 2:58 PM, Aitor Santamaría 
 wrote:

> Thanks, Ralf!!
>
> So I thought, but I have read a couple of references (such as the following 
> in Wikipedia, but not the only one) by which the IFS was present in MS-DOS 
> 4.X, of course as well as in OS/2 and Windows:
>
> [Installable File System - 
> Wikipedia](https://en.wikipedia.org/wiki/Installable_File_System)
>
> Apparently, there was some support for it that was probably removed for 
> MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)
>
> In RBIL, the only reference I've found is to IFSHLP.SYS, which was a Windows 
> mean to guess what has been installed before getting into protected mode, so 
> I am not sure is if this has to be with the IFS that was planned and 
> implemented in MS-DOS 4.0.
>
> Aitor
>
> On Mon, 20 Feb 2023 at 18:27, Ralf Quint  wrote:
>
>> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
>>> Hello,
>>>
>>> Does anyone know if the IFS (Installable File System) API is
>>> documented anywhere?
>>>
>> Just checked in my archive of docs, and there is a MSCDEX.TXT, which
>> describes the interface for the CD-ROM "network redirector".
>>
>> It can apparently be found online at https://cybermax.tripod.com/mscdex.txt
>>
>> Ralf
>>
>> ___
>> 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

[Aitor Santamaría]

Thanks, Ralf!!

So I thought, but I have read a couple of references (such as the following
in Wikipedia, but not the only one) by which the IFS was present in MS-DOS
4.X, of course as well as in OS/2 and Windows:

Installable File System - Wikipedia


Apparently, there was some support for it that was probably removed for
MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :)

In RBIL, the only reference I've found is to IFSHLP.SYS, which was a
Windows mean to guess what has been installed before getting into protected
mode, so I am not sure is if this has to be with the IFS that was planned
and implemented in MS-DOS 4.0.

Aitor











On Mon, 20 Feb 2023 at 18:27, Ralf Quint  wrote:

> On 2/19/2023 5:38 PM, Aitor Santamaría wrote:
> > Hello,
> >
> > Does anyone know if the IFS (Installable File System) API is
> > documented anywhere?
> >
> Just checked in my archive of docs, and there is a MSCDEX.TXT, which
> describes the interface for the CD-ROM "network redirector".
>
> It can apparently be found online at
> https://cybermax.tripod.com/mscdex.txt
>
>
> Ralf
>
>
>
>
> ___
> 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

[Freedos-devel] More on Packages

[jerome]

Hi All,

It is interesting no one has mentioned this very simple Public Domain command 
line player that is similar to the CDP program.

https://github.com/Baron-von-Riedesel/PlayCD 


I’ve created a packages for SJGPlay, PLAYCD and 386Max in the GitLab Archive. 
https://gitlab.com/FreeDOS/sound/sjgplay 
 (Public Domain)
https://gitlab.com/FreeDOS/sound/playcd 
 (Public Domain)
https://gitlab.com/FreeDOS/drivers/386max 
 (GPLv3)

386Max has not been fully converted to package format for simple installation. 
You must install the package sources. There you will find a DISK\TMPOUT 
subdirectory which contains the pre-compiled binaries originally released with 
the project. These binaries still display the old license. Someone may  wish to 
figure out how to compile the sources and update those messages to display the 
new license. 

All we will need to decide is wether or not to include these in the upcoming 
T2303 Interim Build.

I propose that since PLAYCD is the most similar to CDP, to include PLAYCD 
instead of CDP. 
(That would be with FULL and on the BonusCD.)
As for SJGPlay and 386Max, to just include those on the BonusCD.

Does that sound good?

Other possible new packages to consider for inclusion (or at least watch):

AHCICDU - CD/DVD optical disk driver (unsure of license)
https://github.com/Baron-von-Riedesel/AHCICDU 


SBEMU - Sound Blaster Emulation with OPL3 for AC97 (state and license unknown)
https://github.com/crazii/SBEMU 

XDMA - Revived UDMA Driver to be used in Qemu, 86Box, PCem, … (GPLv2+)
https://github.com/Baron-von-Riedesel/XDMA 


386SWAT - GPLv3, Debugger (may require someone to compile)
https://github.com/sudleyplace/386SWAT 

GW-BASIC - MIT License, Microsoft’s original 1983 version
https://github.com/microsoft/GW-BASIC 

DOSLINUX - GPLv3, DOS Subsystem for Linux
Run real linux programs under DOS. 
Why? IDK. (requires someone to compile)
https://github.com/haileys/doslinux 

DIFPAT, GPLv2, DIFF and PATCH Utilities
https://github.com/deverac/difpat 

DOStodon, Multiple Licenses
(Requires next version of DOjS)
https://github.com/SuperIlu/DOStodon 

Any thoughts?

:-)

Jerome


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/19/2023 5:38 PM, Aitor Santamaría wrote:

Hello,

Does anyone know if the IFS (Installable File System) API is 
documented anywhere?


Just checked in my archive of docs, and there is a MSCDEX.TXT, which 
describes the interface for the CD-ROM "network redirector".


It can apparently be found online at https://cybermax.tripod.com/mscdex.txt


Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[Ralf Quint]

On 2/19/2023 5:38 PM, Aitor Santamaría wrote:

Hello,

Does anyone know if the IFS (Installable File System) API is 
documented anywhere?


There is no such thing for DOS. For DOS, things like this, for example 
for the CD-ROM (which is the only "file system" beside FAT that was ever 
implemented officially in DOS), the applicable interface is that of the 
"network redirector" introduced with DOS 3.0.
I had a link to a Microsoft MSDN  web page about this, but that is 
giving a 404 these days. I think Microsoft removed all that stuff years 
ago.


Best chances to find some info is in the sources of MSCDEX (or 
equivalents), or possibly on old MSDN subscription CDs, but those are 
pain to sift through...



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel