Re: [Freedos-devel] Email test

[Steve Nickolas via Freedos-devel]

On Mon, 27 May 2024, Jim Hall via Freedos-devel wrote:


My email to the list bounced as undeliverable, but I'm sending this test
just in case it was a temporary hiccup.

Can someone reply to this thread if you can see this message?

*sent May 27 11:20pm



Second attempt - first one immediately got deflected with a DNS error from 
the main SF server.


-uso.


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

Re: [Freedos-devel] zoo

[Steve Nickolas via Freedos-devel]

On Wed, 22 May 2024, tom ehlert via Freedos-devel wrote:


it seems that no knowledgable person  finds zoo interesting enough to fix it.
and those who care about zoo have no clue.
I regret that I have to say this.

Tom


Was zoo even popular in its heyday?

I feel like when it comes to DOS, for the last 30 years it's been 
exclusively ZIP, except in Japan where it's been exclusively LHA...


-uso.


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

Re: [Freedos-devel] still can't find the source code

[Steve Nickolas via Freedos-devel]

On Fri, 10 May 2024, Green Fog via Freedos-devel wrote:


There you go. The 2 requirements for free dos being a thing are just not
there. not ease of use. I need to use an antique mail list for
communication and wiki/documentation. It's absurd and very not efficient. I
am very busy, and I can't afford the time to download each of these
packages one by one. That is not how the source code should be distributed.
Ease of use is none. Documentations are very bad. The sites linked to are
web 0.1 material. Good documentation and know-hows are what drive further
development, so I can say free dos is dead, and I will not invest more time
on it.

Calling me a troll and telling me not to talk to me? How old are you? That
is not very welcoming and very immature. Either way, I am gone.


ROFLMAO, obvious troll is obvious... Can't even take the time to get the 
name right.


I'm 44 and surmise that I am one of the *younger* regulars on the list, so 
is it really any surprise things are a bit old-fashioned around here? 
(Some of the other old-times probably know what an ignorant little n00blet 
I was when I first showed up here in the late 1990s.)


Trash took itself out.

-uso.


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

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve Nickolas via Freedos-devel]

On Tue, 7 May 2024, Ralf Quint via Freedos-devel wrote:

I don't think there is really a point in trying to get the whole thing 
compiled with FOSS tools. This is just a Sisyphos task, for no or very 
little gain. There is a reason why they included the old, matching tools 
in the release.


I think it's actually somewhat of "in theory everything would work the 
same in practice; in practice not so."  The Watcom tools are explicitly 
clones of the Microsoft ones, but they're just different enough to throw 
the code.


The point is that in some circles (e.g., Debian) a program isn't truly 
open source unless the entire build can be done exclusively with open 
source software.


-uso.


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

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve Nickolas via Freedos-devel]

On Sat, 4 May 2024, Bernd Böckmann via Freedos-devel wrote:


Hello Steve,

Some of the code's pretty braindead, too.  Especially what looks to 
have come from IBM.  I mean...house styles vary, but Algolization is 
still just hideous-looking.  But it goes beyond that - think some of 
the utilities are going to need major rewrites.  I'm thinking of 
writing a new front-end around the FDISK code, but I haven't really 
been able to take the code and sort through everything to figure out 
what parts I'll need in order for FDISK to...fdisk (and don't know 
enough about int13, MBR or FAT to do it my damnself).  I was looking 
into D-Flat, but my brain melted - might have to write bespoke UI code.


does the Microsoft FDISK provide a feature you are missing in Free 
FDISK, or is it because of the license thing you mentioned, or for pure 
fun? Writing a new frontend code for Microsoft FDISK would be a massive 
effort. This would probably take as long as a clean sheet design, and 
then it will still not handle large disks, FAT-32 and so on...


If you want to deal with partition managers, there is also the option of 
contributing to Free FDISK ;)


Greetings, Bernd


B and C (learning exercise + not really a fan of GPL).

I did go in figuring it might require a gutting, if only because the code 
is written in a mutant dialect of C that was partially algolized, and has 
limitations I'd need to lift.


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

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve Nickolas via Freedos-devel]

On Fri, 3 May 2024, Jim Hall via Freedos-devel wrote:


On Fri, May 3, 2024, 10:53 PM Steve Nickolas via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:


So I've had some thoughts regarding the MS-DOS 4 source drop, regarding
[...]
(The obvious question:
Why not use what FreeDOS already has?  A: Because I'd like to have the
entirety of the project under a single license - that being the X license
Microsoft and IBM are already using.)


FYI: the license Microsoft has used for the official MS-DOS source code
releases is the MIT License. The FSF people call this the Expat license.


Huh - thought they called it the "X11 license" (but then, that was 20 or 
25 years ago).  They have used it themselves.



The FSF people also say the Expat/MIT license is compatible with the GNU
GPL. You can copy code from an Expat licensed project and paste it into a
GNU GPL'd project.


And thus MS-DOS 4 can theoretically (not really in practice) benefit 
FreeDOS.


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

[Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve Nickolas via Freedos-devel]

So I've had some thoughts regarding the MS-DOS 4 source drop, regarding 
things I'd like to do with the code.  I'm not really that good of a coder 
and probably would only be able to do some of them myself.  (I'd kill for 
a 3.3 drop - would obviate a lot of these things!  And 5 and 6.2 even 
more.)


First big issue, and one I can only partially resolve.  I'm taking a 
strict approach to the contents of the TOOLS folder - want to get rid of 
it and replace it with open-source equivalents.  That means, most 
practically, OpenWatcom 1.9 (there's prolly other options but the more 
like MSC it is the less torturous porting is going to be).  And the code's 
going to need to be dinked as far as possible to roll in Watcom instead of 
MSC - that's going to be a major pain in the neck.


Some of the code's pretty braindead, too.  Especially what looks to have 
come from IBM.  I mean...house styles vary, but Algolization is still just 
hideous-looking.  But it goes beyond that - think some of the utilities 
are going to need major rewrites.  I'm thinking of writing a new front-end 
around the FDISK code, but I haven't really been able to take the code and 
sort through everything to figure out what parts I'll need in order for 
FDISK to...fdisk (and don't know enough about int13, MBR or FAT to do it 
my damnself).  I was looking into D-Flat, but my brain melted - might have 
to write bespoke UI code.


Additionally, the whole "Message Server" thing.  (I think the broken TYPE 
command when COMMAND.COM is run under FreeDOS is related to this.)  I'd 
like to have the feature reduced to compatibility only and use good 
old-fashioned AH=9 like older DOS versions.  It'll probably also iron out 
some of the compile issues I've had trying to port the C stuff to Watcom!


After these things are ironed out, I guess the next phase would be, unless 
another code drop obviates the effort, to recreate features of later 
versions.  I've actually done this with some apps.  (The obvious question: 
Why not use what FreeDOS already has?  A: Because I'd like to have the 
entirety of the project under a single license - that being the X license 
Microsoft and IBM are already using.)  High memory support - big feature 
of 5.0 - that's a big part of why 5 was considered a _good_ version of DOS 
and 4 wasn't.


(If I sound like about an idiot, I probably sounded about ten times so on 
this list 20, 25 years ago... bear with me :P, I've been learning things 
and hope to continue to do so.)


-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Thu, 2 May 2024, Liam Proven via Freedos-devel wrote:


On Fri, 26 Apr 2024 at 08:25, Steve Nickolas via Freedos-devel
 wrote:


Everything but himem, dosshell, gwbasic, and parts of xmaem/xma2ems,
apparently.  I got most of it compiled using the tools in the archive.


That being the case, is it possible to get it working with 386MAX
instead, as that's now FOSS as well?

https://github.com/sudleyplace/386MAX


I've never seen it rolled, so I can't say if the current code will work on 
DOS 4, but 8.03 does.


-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Thu, 2 May 2024, Eric Auer via Freedos-devel wrote:



Hi!

I have no life - I can devote the time and energy to it, just don't have 
the brainpower I'd like to think I have.


I hope that will get better :-o

Eric


Well, I certainly know more about C, 8088 ASM, and MS-DOS than I did going 
into this thing about 25 years ago... holy hell, I was a n00b then :P


-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Tue, 30 Apr 2024, tom ehlert via Freedos-devel wrote:

I have no idea why I would recompile old MS stuff, but as a hobby it's 
ok.


6.21 would be much more useful and no doubt a lot more people would want 
to do what I'm trying to do for 4.01 with a 6.21 source drop.


(Even 5.0 would be more useful.  But really only for io.sys, msdos.sys and 
command.com.  Then...same for 6.2)


I have no life - I can devote the time and energy to it, just don't have 
the brainpower I'd like to think I have.


JWASM is supposed to be better MASM compatible; at least Japteth changed 
some things as he had problems with "WASM not compatible enough".


Hmm.

-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Tue, 30 Apr 2024, Bernd Böckmann via Freedos-devel wrote:


Sadly not. Only the binaries are released under MIT through the repository.


Does that mean we finally have a genuinely open sourced OMF linker?

-hpa


It's my opinion that including them was more of a fortuitous accident than 
actual intent.  I'd _like_ to try to migrate as much as possible away from 
them and onto something like OpenWatcom 1.9, but it's proving to be a pain 
in the neck.  Ideally, I'd like to organize the source a little better too 
so that there isn't a lot of stuff being compiled and assembled in the INC 
folder.


I started bashing on a copy of the tree, and I started to get stuff rolled 
in Watcom, but mainly ran into trouble over parse(), sysloadmsg() and 
sysdispmsg(), which are ASM and mostly call into deep, dark, officially 
undocumented parts of DOS and could probably be replaced, if I could 
figure out what they were doing in the first place...


No luck doing the same with the kernel or any of the other ASM stuff. 
Watcom's MASM emulation isn't 5.1-tier.


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

Re: [Freedos-devel] FreeDOS Windows for Workgroups howto

[Steve Nickolas via Freedos-devel]

On Sun, 28 Apr 2024, Eric Auer via Freedos-devel wrote:


- Use the Microsoft versions of HIMEM and EMM386 and SMARTDRV
  (bundled with Windows, alternatively from MIT-released MSDOS 4?)
  so update your config and autoexec accordingly


HIMEM 2.04 is included in 4.0, but it wasn't in the source drop. (The 
source to 2.03 has been out there, though; maybe Microsoft could be 
convinced to let that be dropped into the unofficial forks...)


Dunno if such an old version of himem, emm386 or smartdrv would work with 
Windows 3.x though, which is why they included them (or at least himem and 
smartdrv) with Windows...


-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Fri, 26 Apr 2024, Eric Auer via Freedos-devel wrote:


As mentioned by DOSEMU2 people, this is a somewhat exotic,
but interesting MS DOS 4.00, not the once widespread 4.01:


Actually, apart from having the io.sys sources to the multitasking 4, this 
is the regular 4.x line from 1988.  Most of the binaries in 4.01 didn't 
change at all from 4.00, as a SFV of both versions will reveal.


-uso.


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

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[Steve Nickolas via Freedos-devel]

On Fri, 26 Apr 2024, Bernd Böckmann via Freedos-devel wrote:

Microsoft and IBM released the source code of MS-DOS 4.0 under MIT 
license [1]. To me, it looks fairly complete.


Everything but himem, dosshell, gwbasic, and parts of xmaem/xma2ems, 
apparently.  I got most of it compiled using the tools in the archive.


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

Re: [Freedos-devel] Is there an open source fmt clone for DOS?

[Steve Nickolas via Freedos-devel]

On Wed, 24 Jan 2024, Jim Hall via Freedos-devel wrote:


I'm looking for a way to keep my text files (like README.TXT) tidy and
easy to read. One problem is that if I modify a plain text file in a
regular text editor, and change the line length in the middle of a
paragraph, now I have to fix all the lines around it so the lines are
all about 77 characters wide.

On Linux, I'd use the BSD 'fmt' command to do it. This is a trivial
program to write (and I just did) if you don't want cool features like
preserving indents. But there are probably lots of similar existing
programs to do the same thing - so I wondered if anyone knows of an
open source DOS version of 'fmt' (or something like it)?


Gnuish?

Otherwise I could try to bring it over from BSD?

-uso.


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

Re: [Freedos-devel] Learning DOS assembly programming

[Steve Nickolas via Freedos-devel]

On Tue, 26 Dec 2023, Jim Hall via Freedos-devel wrote:


I actually never learned DOS assembly programming, but decided I'd
like to start.

What assembler do you recommend, and where is a good place to start
learning about DOS assembly programming? Start with a "Hello world"
program and eventually move up to writing an assembly version of TYPE
and CHOICE, things like that.

I was thinking about NASM, since it's open source and we include it in
the distribution. Looking around, I found a bunch of tutorials on
https://asmtutor.com/ that look easy enough to follow, although it's
for Linux. Any similar tutorials to learn DOS assembly programming?


I've used NASM because it's easier than the traditional x86 assemblers.  A 
simple .COM might look like this:


  cpu   8086
  org   0x0100
entry:mov   dx, msg
  mov   ah, 0x09; PUTSTR
  int   0x21
  mov   ax, 0x4C00
  int   0x21; EXIT CODE 0
msg:  db"Hello, cruel world.", 13, 10, "$"

My own implementation of CHOICE is actually written in NASM - it's one of 
the programs I wrote to learn x86 ASM (and it reads a lot like I was 
thinking in 6502).


-uso.


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

Re: [Freedos-devel] VME broken on Ryzen CPU, autodetection useful?

[Steve Nickolas via Freedos-devel]

On Mon, 13 Nov 2023, Rugxulo via Freedos-devel wrote:


Ryzen (Zen 1) was brand new in 2017, redesigned from scratch. I doubt
the current Zen 4 (2022) has that bug, but who knows. (Now that the
BIOS and CSM are dead, they may not care to fix it. And the whole
"x86-S" rumors imply legacy is going away.)


Though I think that's mainly an Intel thing (x86S, I mean).

That said, I think there may be a point where if one's going to run DOS on 
a modern machine, it'll have to be through some degree of emulation. 
Whether that be a KVM/QEMU-on-metal approach, or a 64-bit "DOS" which can 
emulate a Pentium MMX or so, VESA SVGA, SB16, etc. for legacy apps...


(Actually, I'd be interested in something of this ilk if I knew more, 
having run a stripped-down Apple //e emulator on bare-metal from UEFI and 
then giving up because I couldn't read the damned Alt keys...)


-uso.


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

Re: [Freedos-devel] i have a tech question about 286 and XMS

[Steve Nickolas via Freedos-devel]

On Thu, 2 Nov 2023, Deposite Pirate via Freedos-devel wrote:

You should read again what he said. A 286 running a DOS doesn't need 
"maintained drivers". If fdxms286 works on a 286, there is no reason it's not 
going to work or in a lesser way now. DOS is not Linux/BSD.


People forget that it's possible for a program to be "mature" to the point 
that, at most, all it might need is the occasional bugfix.  Not every 
program needs to be under constant maintenance.


(Not directed at you)

-uso.


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

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Steve Nickolas via Freedos-devel]

On Thu, 2 Nov 2023, Harald Arnesen via Freedos-devel wrote:


Jim Hall via Freedos-devel [02/11/2023 11.12]:

So now phishers are pretending to be FreeDOS emails. That's pretty 
targeted phishing (aka "spear phishing" where attackers customize the 
email to be very specific to the recipient).


Thanks for sharing. I haven't seen this, but I'll watch for it now.

On Thu, Nov 2, 2023, 4:39 AM Wilhelm Spiegl via Freedos-devel 
> wrote:


Hi all,
I only wanted to tell you that I had a "FreeDOS" phishing attack
yesterday.


I got one as well. Same subject and link.



I got one from an Argentinian address - figured it was a hack rather than 
a phish, but with the same idea.


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

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

[Steve Nickolas via Freedos-devel]

On Thu, 5 Oct 2023, Liam Proven via Freedos-devel wrote:


On Thu, 5 Oct 2023 at 10:29, Danilo Pecher via Freedos-devel
 wrote:


The best solution would be three disks:

BaseCD - no bigger than 300MB, only basic tools

ApplicationCD - Editors, Gemes, Utilities - the lot

DeveloperCD


I agree with this, FWIW.

(Personally I would also rate xNix editors like Vim and Emacs as
strictly programmers' tools.)




I can't see what would need to be on base to make it more than about 20 
MB?  And even that's pushing it hard.


Maybe because I'm measuring by PC DOS 2000, which came on 6 floppies.

-uso.


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

Re: [Freedos-devel] dir issues

[Steve Nickolas via Freedos-devel]

On Thu, 10 Aug 2023, Liam Proven via Freedos-devel wrote:


On Wed, 9 Aug 2023 at 00:13, Rugxulo via Freedos-devel
 wrote:





 (DJGPP v1 SDK)


What does DV have to do with DJGPP?


I'm not sure it was *DJGPP*.  It *was* based on GCC - and I do think it 
was GCC 1 - but that's the extent of my knowledge.





James Gosling was familiar with UCSD Pascal (based upon ETH Zurich's
Pascal P sources) which also used pseudo code. (P4 has been ported to
DOS, so has its successor P5.)


What are "P4" and "P5" here?


Versions of the original Pascal system, I think?

UCSD used Roman numeral major versions, IIRC; this is the "Pascal" 
operating system that ran on the Apple ][.


-uso.


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

Re: [Freedos-devel] dir issues

[Steve Nickolas via Freedos-devel]

On Tue, 8 Aug 2023, Rugxulo via Freedos-devel wrote:


Long story short: I don't think FreeDOS not having a DOSshell clone is
a significant omission. Nobody will write the "program switcher" code
(too complex), and we already have file managers. So I don't see what
else it would offer. Feel free to prove me wrong, but there's just too
much inertia and not enough time or experience to do such heavy tasks
like that. FreeDOS is already good enough as it is.


May I point out that if the goal is MS-DOS 6.2x, there's no need anyway; 
they don't come with DOSSHELL.  You had to send away for the supplemental 
disk to get that.


-uso.


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

Re: [Freedos-devel] CD-ROMs was ANSI for DOS

[Steve Nickolas via Freedos-devel]

On Mon, 7 Aug 2023, Danilo Pecher via Freedos-devel wrote:


Yeah, around 1993 was when the first ones arrived.


I know I was hearing about CD-ROM drives connected to the Apple IIgs when 
I was still in grade school (so no later than mid-1990)...


-uso.


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

Re: [Freedos-devel] CD-ROMs was ANSI for DOS

[Steve Nickolas via Freedos-devel]

On Mon, 7 Aug 2023, Danilo Pecher via Freedos-devel wrote:


The first one I can remember was the Mitsumi CRMC-LU005S single speed
drive, which was the one I had. It had its own card because it was
non-IDE despite the fact that the cable and plug looked exactly like
IDE. They did use a proprietary standard. They definitely worked on an
80286, so I think we can conclude that CDROMs did not require an
80386. I can remember some early Shareware CD's with stuff I couldn't
use because I only had a 80286. DJGPP springs to mind.


I remember seeing an XT with an external CD-ROM drive at a library 30 
years ago.


-uso.


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

Re: [Freedos-devel] Interesting behavior with PC Tools

[Steve Nickolas via Freedos-devel]

On Sun, 30 Jul 2023, Jim Hall via Freedos-devel wrote:


*Aside: I thought QBASIC would only run on MS-DOS, but I checked the
screenshot the user sent me; it's really MS-DOS QBASIC, not QuickBASIC
or something else. And the series of screenshots they sent indicated
QBASIC was running on FreeDOS. So I guess QBASIC doesn't mind running
on non-MS DOS?


It doesn't care.  I used to use it on PC DOS 3.

QBASIC actually came with PC DOS for a while too (5.0-5.02).  I have a set 
of install disks for 5.00.1.


-uso.


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

Re: [Freedos-devel] dir issues

[Steve Nickolas via Freedos-devel]

On Fri, 28 Jul 2023, Jose Senna via Freedos-devel wrote:


While I am just an user, I also think that a
GUI for DOS is not an important improvement.
As Liam Proven, I think that a shell that
is a good app launcher, file manager and
provides fast task switching with a small
memory footprint would be much more useful.
Since DOSShell was available In MS-DOS 5,
that would also be more in line with the
goal of making FreeDOS fully compatible
with MS-DOS.


For what it's worth:

DOSSHELL was introduced with PC DOS and MS-DOS 4.00, written by IBM.  With 
MS-DOS/PC DOS 5, Microsoft rewrote it from scratch.  MS-DOS 6.2 moved it 
to the supplemental disk, but PC DOS kept it in the main system until the 
end (PC DOS 2000 will still install it by default).


-uso.


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

Re: [Freedos-devel] dir issues

[Steve Nickolas via Freedos-devel]

On Sun, 23 Jul 2023, tom ehlert via Freedos-devel wrote:




ISTM that all the other graphical shells in FreeDOS are even less
useful than GEM, and it would be no loss to remove them... but adding
GEOS would be a win.


in what way is GEOS even related to FreeDOS which runs on PC's?

unless wikipedia has it completely wrong GEOS needs 6502 (commodore c42, 
AppleII etc)
computers.

Tom


There was a "PC-GEOS".  Has a kinda Win9x look in later versions.

-uso.


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

Re: [Freedos-devel] EXIST NUL

[Steve Nickolas]

On Wed, 14 Jun 2023, Mercury Thirteen via Freedos-devel wrote:


Unfortunately, in many cases, it has to be an absolute rule.

I totally get the mindset (and semi-subscribe to it myself)of wanting 
FreeDOS to be a kind of MS-DOS but improved in every way possible 
including fixing Microsoft's bugs, but realistically that cannot be in 
all cases since some legacy software out there may very well be relying 
on a specific behavior present in MS-DOS and us fixing that bug - even 
when normally be the right thing to do - may break compatibility in 
those cases.


This... MS-DOS and PC DOS have been "the norm" for so long that a lot of 
software relies on bugs and corner cases, and falls apart if they aren't 
supported.


-uso.


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

Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)

[Steve Nickolas]

On Sat, 8 Apr 2023, Andrew Bird via Freedos-devel wrote:

 I think I can shorten the Spanish text, which fixes both the alignment 
problem and the lack of a space. I'll send a PR but I'd be grateful if 
somebody can check the text there as my Spanish is mostly beginner 
level.


es_ES in PC DOS 6.3: "Tamaño del mayor programa ejecutable"
es_ES in MS-DOS 6.22: "Programa ejecutable más extenso"

Don't know how useful that is to you, though.

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

Re: [Freedos-devel] DOS 44h (Get Device Information) - CD-ROM marked as remote?

[Steve Nickolas]

On Mon, 13 Mar 2023, Aitor Santamaría wrote:


Hello,

A quick question, if I query device information on CD-ROM (int 21h,
AX=4409h), will I get that a CD-ROM drive is remote?  (bit 12 = 1).

I am getting this under XP's ntvdm, and it sounds as a correct thing (the
filesystem is not FAT), but I would like to check in case someone knows if
this is correct).

Thanks,
Aitor



So I wrote a program to display the DX returned from that function call 
when pointed to a CD-ROM.  To be fair, this is MSCDEX 2.25 on PC DOS 
5.00.1.  It said 0x1000.


I think the answer is yes.

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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Steve Nickolas]

On Wed, 8 Mar 2023, Michael Brutman wrote:


Sorry, we have a terminology issue here.  (Again.)

A Virtual Machine for the rest of us is something like VMWare, Qemu,
VirtualBox, etc. - something that simulates a real machine.  You load a
real operating system in it and the operating system generally doesn't know
or care that it's actually in a simulation.

Those other environments are not virtual machines.  They are DOS emulators
or different versions of DOS.  They are not any form of a virtual machine.

You should have no problems with the InDOS flag when running real DOS in a
real virtual machine.  That may not be true for the emulated DOS
environments.  I wouldn't even think to try to look for the InDOS flag on
something like DOSBox.


-MIke



And QEMU sits on the line; if you use KVM it's a VM, but if you don't, 
it's an emulator.


-uso.


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

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Steve Nickolas]

On Tue, 7 Mar 2023, Rugxulo wrote:


Maybe you mean something like this?

"Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR

"The Power Macintosh 6100/66 DOS Compatible is a fascinating machine.
For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks
to an Intel 486 and a PowerPC 601 inside! Yeah, mid-90s Apple was
rather amusing."


I actually have the LC630, an earlier 68LC040 version of that machine, 
albeit without the PC compatibility module.


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

Re: [Freedos-devel] 386MAX

[Steve Nickolas]

On Mon, 6 Mar 2023, Bret Johnson wrote:

Or just take some of the important stuff that Bob Smith and Qualitas 
discovered about Windows/GEMMIS/EMM386 and import it into something like 
JEMM.  There's some knowledge embedded in 386MAX about what MS did that 
you will never directly get out of MS.


Good luck with that.  The codebases may well be too different and/or one 
or both of them too inscrutible (I've never sat down and tried to read 
either one) for that to even be possible.


-uso.


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

Re: [Freedos-devel] MS-DOG (was Re: [Freedos-user] FSF)

[Steve Nickolas]

On Wed, 1 Mar 2023, Ralf Quint wrote:


On 3/1/2023 6:12 AM, tom ehlert wrote:

Hallo Herr Rugxulo,

am Mittwoch, 1. März 2023 um 10:22 schrieben Sie:

  Hi again,


It's entirely possible that Richard dislikes DOS that much.

I also dislike Richard. we can leave it at that.

That makes two of us.. He had a basically good idea decades ago and then 
went all out on an ego trip and became nothing but an ignorant, arrogant 
software license nazi.


Just say no to fascism... 

Ralf


That mentality from GPL fanboys is why I soured on it and use "university" 
licenses (e.g., MIT, BSD) anymore.


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

Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS

[Steve Nickolas]

On Wed, 22 Feb 2023, Liam Proven wrote:


On Sun, 19 Feb 2023 at 17:52, Jim Hall  wrote:


It's been a few days since the last comment on this thread, so I think
those who have an opinion on this have voiced it.


Just seen it. I've moved house recently and have no broadband at my new place.


The consensus appears to be "Keep OpenGEM but drop oZone and SEAL"


Sounds good. But please _fix_ OpenGEM. Either configure it to run from
the subdirectory FDIMPLES puts it in, or tweak its batch file to
SWSUBST it to a drive letter of its own.


That shouldn't even be hard.

http://www.seasip.info/Gem/Software/resdir.zip

-uso.


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

Re: [Freedos-devel] FreeDOS package issues

[Steve Nickolas]

On Sun, 19 Feb 2023, Jim Hall wrote:


On Wed, Feb 15, 2023 at 4:30 PM Steve Nickolas  wrote:

Would it be something not too hard to bang out with a decent C compiler?

I've never written a CD player interface per se, but if all the
information can be retrieved, and all the commands can be executed, why
not?


I haven't written a CD Player either, but I would think it's not too
hard. If you can read the waveform from the CD track file, and send
that to the sound card - that seems like that's all you need to do,
no?

Steve has released SJGPlay as CC0. It's a different programming
language, but maybe you can look at his code to implement a similar
player in C.


It happens to be a language I speak, too, though it does look 
overengineered compared to what I'd do.


I'll see what I can figure out.

-uso.


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

Re: [Freedos-devel] FreeDOS package issues

[Steve Nickolas]

On Wed, 15 Feb 2023, E. Auer wrote:


Well, you can tell a CD drive to play track X using my
minimalist cdrom2ui, but I think that would be sort of
an INdecent open source alternative because it is too
minimal :-D On the other hand, a QuickBasic solution
sounds like something needing FreeBASIC in QB mode, or
something which compiles into a large binary? That is
probably too non-minimal?


Would it be something not too hard to bang out with a decent C compiler?

I've never written a CD player interface per se, but if all the 
information can be retrieved, and all the commands can be executed, why 
not?


-uso.


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

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Sun, 29 Jan 2023, tom ehlert wrote:


but I think the black box with the command prompt in Windows is indead
often called the DOS VM or DosBox.


DOS Virtual Machine, yeah.

-uso.


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

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Fri, 27 Jan 2023, tom ehlert wrote:


this argument is nonsense. many/most people don't care about the 'open source'
part as long as it's free.


This.


most care more if this OS supports big disks or much memory.

after all, an OS is not an end target:
people need the OS to run their applications like

1. Play classic DOS games.

2. Run legacy software.

3. Develop embedded systems.

none of this is open source.


Often, "Windows 3.1x" is the #2.


I can't see many users to reprogram their motherboard (even if it
would be supported) just to play a casual round of Doom or
Wolfenstein.


Also this.  (Though those, at least, can be rolled and run on modern 
systems.)



no network card.
no mouse.
no USB devices.
(no memory at b8000 or a)?
no sound.
nothing with interrupts.

congratulations.


The way I suggested to do things - a bare-metal emulator/virtualizer, upon 
which the FreeDOS kernel is run - is heavier than SeaBIOS, but would be a 
better fit for all of this.


Emulate a generic NIC, mouse, SVGA, SB16...run 16-bit code in emulation if 
you have to...and virtualize 32-bit stuff.


If the system's 32-bit, you can run DOS natively.  If the system's 64-bit, 
this would be for if you can't...if you can, just do.


(Hopefully that doesn't sound too confused.)

-uso.


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

[Steve Nickolas]

On Tue, 24 Jan 2023, Bret Johnson wrote:

For purposes we're discussing here, I don't think DOSBox (or any of its 
forks, including vDOS) is a viable solution.


DOSBox really isn't DOS.  It's an environment designed to run certain 
DOS applications.  A lot of stuff is missing in DOSBox that's needed to 
make it a "real enough" DOS to be used for development and testing. 
E.g., a lot of the internal structures that some DOS "extenders" need to 
look at (like certain TSRs and Device Drivers) simply don't exist on 
DOSBox.


A perfect example of this are the "standard" DOS Devices: NUL, CON, 
COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two 
that exist in a form where other programs can "see" them using standard 
methods (by scanning through the linked list of Device Driver addresses) 
are NUL and CON.


Things like that can cause lots of problems in certain situations.


Though the hardware emulation may be useful, it would be better for such a 
situation to use that as a base to run an actual DOS on.


-uso.


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[Steve Nickolas]

On Mon, 23 Jan 2023, E. Auer wrote:




Depending on how thin the glue and VM layer will be, you will be able
to run fewer or more DOS apps with it. You can run some DOS apps in
CTTY serial consoles if they only use int 21 for user I/O. There are
support modes for simple DOS apps in some boot managers which only
implement a few most popular bits of the DOS API to run apps directly
from the boot manager without an actual DOS. So why not use for example
real mode DOS apps without sound, with whatever is left in terms of
hardware text mode or maybe VGA as an already entertaining intermediate
milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
apps etc. pp. for later? The "easy" solution will still be running a
DOS-friendly VM inside Linux or other host OS. But not the exciting
solution regarding technological challenge and "abstraction thinness".

People have written hypervisors to hide malware. Porting an open BIOS
and some VM ingredients into a CSM and an open source "VMware ESXi"
competitor which runs DOS better than the commercial product does?
In other words, a Xen for DOS? To stay in the Xen terminology, would
one want a paravirtualized DOS for that? Or would one put some light
weight "BIOS setup" type menu into dom0 and run DOS only as client?


This is kind-of what I was trying to hint at - a lightweight operating 
system that just manages the hardware and (if necessary) provides 
emulation for 16-bit apps.  I feel like even a stripped-down Linux kernel 
is extreme overkill since multitasking/multiuser isn't even useful for 
that purpose.


But in this day and age where the solution to everything is "throw a 
'Duino at it" or "throw a RasPi at it", I think too many people have lost 
the concept of simple, lightweight, minimalist software.  And that's why 
you have all the kids trying to turn FreeDOS into Linux, and Linux into 
Windows.


The idea is this: provide a "volume manager"; a way to use the installed 
hardware to emulate VGA/SVGA, SB16, and the basic equipment used on DOS 
machines; and hooks to MS-DOS/FreeDOS to support stuff you're likely to 
have on a modern machine that wouldn't be supported.  And since it's quite 
possible that in the future 8086 and 80286 mode will finally get the axe, 
it might be necessary to move them to actual emulation (maintaining, if 
possible, virtualization for 32-bit software).


I'm also kind-of thinking MacOS 7.x, that had the 68030 emulator to run 
parts of the OS on PowerPC systems...


-uso.


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

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Sun, 22 Jan 2023, Jerome Shidel wrote:

Assuming Google does not scrap GSoC amidst the layoffs, I have a 
thought.


Perhaps it could be used to solve one of the most frequent problems I 
hear. Running FreeDOS on modern UEFI hardware.


As we are all well aware, this cannot be directly accomplished and would 
require an abstraction layer between the OS and the actual hardware.


A project could be created to provide a very thin Linux based system 
(possibly using an RTOS kernel) whose only job is to manage the 
abstraction layer and implement the virtual machine to run FreeDOS.


This could be done almost transparently. Booting straight to DOS unless 
the user pressed a specific key (Like F1) during boot.


Pressing such a key would bring up a BIOS like interface that could be 
used to change the virtual BIOS settings and configure drivers and such 
aspects of the host OS.


Their job would be to create that interface and make it all work 
seemingly. Most of the pieces required exist. But, it would not be a 
small task to implement.


It could yield much better performance and more accurate emulation than 
traditional virtual machines. With todays multi-core systems, individual 
cores could be dedicated to emulating various aspects of PC hardware. 
For example, one core could be dedicated to performing the tasks handled 
by a sound card.


I think such a project could appeal to many. There is a lot of interest 
in playing old games. Also, since this would be a generic legacy PC 
emulation layer. It could be used to install other Operating Systems 
like MS-DOS, PC-DOS, etc.


:-)

Jerome


I think I actually proposed a similar idea some time ago except that it 
was *itself* the OS, rather than a stripped-down Linux distro.  Sort-of a 
pre-AMD64 PC emulator, virtualizing where possible, emulating where not.


Then again, I have a half-written Apple //e emulator that runs straight 
off UEFI - and it's much the same thing I was describing, except Apple ][ 
instead of an older variety of PC, and strictly emulation.


I do feel it's really overkill though - and it's a bit of a two-edged 
sword.  More work to implement and maintain, though much less of a 
footprint.


As for all the people saying "make FreeDOS more like Linux", they don't 
seem to understand FreeDOS *or* Linux.


-uso.


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

Re: [Freedos-devel] Re: Where to start and continue?

[Steve Nickolas]

My comments here are directed to the OP, but build off the message to 
which I am replying.


On Sun, 15 Jan 2023, jer...@shidel.net wrote:



I don’t think your ready to tackle assembly under DOS yet. Not only do 
you need to know some variant of assembly language. That really does 
require some understanding of how DOS, BIOS and the computer itself work 
at such a low level. This knowledge is mostly gained through experience 
programming for DOS.


Even I would find writing a GUI for DOS a daunting task, and I've written 
a lot of code in C (including such complicated things as emulators). 
You're trying to swim in mile-deep waters when you can barely tread.


Therefore, you will need to start with one of the higher level 
languages. Either a variant of C or Pascal. For Pascal, the most common 
for DOS is Turbo Pascal. There are loads of example programs for it in 
books and online. However, Turbo Pascal is a closed source compiler. 
Nowadays, you can download v5.5 for free from Embarcadero. But being a 
closed source compiler, there are many individuals in the open source 
community that frown upon using it. That probably make C a better 
choice. There are lots of C resources online as well.


C is, in my opinion, the most useful language for programming in DOS.  x86 
ASM is the second-most useful.


Keep this in mind:

I got by for over 20 years with almost NO knowledge of x86 ASM, and I've 
written some complicated programs for DOS, including emulators and an IRC 
client.


You seldom, if ever, need ASM for anything more than a speed or size 
boost.  And C is usually pretty fast and lightweight on its own.  Stay in 
C as long as you can, before going deeper into the "sea".


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

Re: [Freedos-devel] Linking asm with C

[Steve Nickolas]

On Fri, 13 Jan 2023, Knedlik wrote:

To be honest, I’m just following a tutorial that said it’s better to do 
it in asm - but it’s in Pascal, so I’m translating it into C.


Only reason you'd want to use ASM rather than C is to try to optimize it 
beyond what the compiler can do.


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

Re: [Freedos-devel] Linking asm with C

[Steve Nickolas]

On Fri, 13 Jan 2023, Knedlik wrote:


void clearScreen(char color) {
   int i;
   for (i = 0xa000; i < 0xfa00; i++) {
   char* byte = i;
   *byte = color;
   }
}


This is completely wrong.  Mode 0x13, right?

void clearScreen (char color)
{
 char far *screen;
 unsigned int i;

 screen=MK_FP(0xA000, 0x);
 for (i=0; i<64000; i++) screen[i]=color;
}

-uso.


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

Re: [Freedos-devel] Linking asm with C

[Steve Nickolas]

On Fri, 13 Jan 2023, Knedlik wrote:

To be fair, I myself am not sure about this. It’s the default options, 
so I would assume the watcom linker and whatever memory model open 
watcom is using.


The default for OpenWatcom is the small model.

I happen to know how to do this only for the specific usage case of "void 
function, takes void" and the specific combination of the 32-bit compiler 
and NASM.  You'll probably have to do more research to figure out the 
specifics for the 16-bit compiler and how to send parameters.


With the specific combination of WCL386 and NASM you do this in NASM:

  cpu   386
  bits  32
segment   _TEXT public align=4 class=CODE USE32
global_asmentry

_asmentry:

And in C, you declare it "extern void cdecl asmentry(void);"

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

Re: [Freedos-devel] Toggling directories

[Steve Nickolas]

On Sat, 12 Nov 2022, tom ehlert wrote:

maybe even one of our assembler gurus looks at published sources of 
msdos 2.01


The 2.11 sources won't say anything here, as the DIRCMD stuff wasn't 
introduced to MS-DOS until 5.0.


I checked the behavior with PC DOS 2000 since that was my preferred 
version and was, in fact, a descendant of MS-DOS 5 (and still supports 99% 
of Microsoft's quirks).


-uso.


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

Re: [Freedos-devel] Toggling directories

[Steve Nickolas]

On Fri, 11 Nov 2022, tom ehlert wrote:


virtually all options toggle, but someone probably noted that /P
should not toggle, because even after

 set DIRCMD=/P

 DIR /P

should still pause.

MSDOS probably has not toggling at all (I'm not sure; someone who is not
named Tom should test this), and optScanBool() should be replaced by
optScanBool2() all over FreeCOM.


Checked with PC DOS 2000:

DIR /P/P = page mode is active.

SET DIRCMD=/P
DIR = page mode is active.

SET DIRCMD=/P
DIR /P = page mode is active.

SET DIRCMD=/P
DIR /-P = page mode is not active.

DIR /P/-P = page mode is not active.

-uso.


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

Re: [Freedos-devel] New version of text editor (and image viewer) Blocek

[Steve Nickolas]

On Fri, 28 Oct 2022, Rugxulo wrote:


Hi,

On Fri, Oct 28, 2022 at 6:14 AM Eric Auer  wrote:


I noticed that Jim's TRCH only translates one char at a time,
do we already have a variant which is as powerful as Linux "TR",
supporting for example TR 'a-z' 'A-Z' or TR -d '\n' and so on?


DJGPP's TextUtils has TR.EXE (but I'm not familiar with it):

* http://www.delorie.com/pub/djgpp/current/v2gnu/txt20br3.zip


You could try Gnuish, for the same reason.

Or http://6.buric.co/bsdtr.zip which I just kitbashed in 2 minutes out of 
some old BSD source code.


-uso.


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

Re: [Freedos-devel] CLS reimplementation (Re: VERIFY reimplementation)

[Steve Nickolas]

On Wed, 14 Sep 2022, Bitácora de Javier Gutiérrez Chamorro (Guti) wrote:

Dear Jim,   There is no practical purpose on my mind, just the challenge 
of rapidly and efficiently convert it. As you said, both CLS and VERIFY 
are internal commands.


What surprised me about your ANSI fallback is that DOSBox, MS-DOS and 
DR-DOS already work it that way, but not the command console in Windows 
11. It seems that with time we are losing capabilities instead of 
gaining.


In fact any argument passed to CLS will trigger the help screen no 
matter if it is -h, /? or whatever. It was simply silly to check for it, 
since CLS should not expect any argument. BTW, your implementation does 
the same, checking argc > 1 which is smart too.


At least in your 2.01 and 2.1 versions there is no possibility of 
changing colors, maybe they were lost in previous versions. But as you 
said, this does not matter, just a curiosity.   Kind regards.


I myself only implemented cls at the same level as MS-DOS, and the most 
basic cls looks something like this (NASM):


; Copyright 2001, 2002, 2003, 2022 S. V. Nickolas.
;
; Redistribution in whole or in part, with or without modification, is
; hereby permitted without restriction.  This software is provided "as is"
; and all warranties, express or implied, are hereby disclaimed.

  cpu   8086
  org   0x0100
entry:mov   ax, 0x4400
  mov   bx, 1   ; stdout
  int   0x21
  jc.2
  test  dx, 0x0010  ; is CON:
  jz.2
  mov   byte [maxrow], 24
  mov   ah, 0x12; do we have an EGA?
  mov   bx, 0xFF10
  mov   cx, 0x
  int   0x10
  cmp   cx, 0x  ; unchanged = MDA or CGA
  je.1  ;   = always 25 lines
  mov   ax, 0x0040  ; otherwise, lines-1 is stored at
  push  es  ;   0040:0084
  mov   es, ax
  mov   ah, [es:0x0084]
  pop   es
  mov   [maxrow], ah
.1:   mov   ah, 0x0F; this, OTOH, works on anything
  int   0x10
  dec   ah
  mov   [maxcol], ah
  mov   ax, 0x0600  ; method used by MS-DOS COMMAND.COM
  mov   bh, 0x07
  xor   cx, cx
  mov   dx, [maxcol]; pulls in maxrow also
  push  bp  ; BUG WORKAROUND
  int   0x10
  pop   bp
  xor   dx, dx
  mov   ah, 0x02
  xor   bh, bh
  int   0x10
  jmp short .3
.2:   mov   dx, eansi
  mov   ah, 0x09
  int   0x21
.3:   mov   ax, 0x4C00
  int   0x21; EXIT CODE 0

maxcol:   db79  ; Must be in this order
maxrow:   db24

eansi:db27, "[2J$"
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] No simple cpu identification program returning an error code as an answer?

[Steve Nickolas]

On Mon, 29 Aug 2022, Bret Johnson wrote:

I'll try to search for an appropriate license and e-mail it to you. 
I've been searching though a little bit of licensing info and really 
didn't know that even declaring that something is "public domain" 
doesn't necessarily mean what you think it means.  I suspect it may 
ultimately have something to do with the lawyers needing SOMEBODY to go 
after when something goes wrong -- declaring it to be public domain 
doesn't necessarily get you completely "off the hook".  I know Jim has a 
significant concern over these kinds of things since he is the "face" of 
FreeDOS.


We could end up having a long discussion about this (and it might even 
be worthwhile, or at least entertaining), but it seems to me as though 
legally they try to classify software as simply another "branch" of 
writing, with the other major branches being books and music.  While 
they all certainly have "creative" aspects to them and can be 
"plagiarized" in some sense, they really are different animals and 
pretending they are the same (even if only in a legal sense) really 
doesn't seem very logical.  Of course, legality and logic don't 
necessarily need to have anything to do with each other.


For example, I know it's a big deal these days for musicians to claim 
that somebody who disagrees with their politics can't play their songs 
(at things like political rallies).  Basically, they're declaring who 
can and can't listen to their music.  This would be equivalent to 
book-banning by an author -- the author of a book saying who can and 
can't read it, or a programmer declaring who can't and can't use their 
software (even if they pay for it).


We're living in a funny world.


This is why I use UIUC (for a longer license) or MIT/MIT0 (for a shorter 
one).


Something like this (basically a "MIT0") is just 3 sentences and grants 
effectively the same rights that would be intended by a "public domain" 
dedication.  This is the UIUC license with the three conditions removed:


"Permission is hereby granted, free of charge, to any person obtaining a 
copy of this software and associated documentation files (the 'Software'), 
to deal in the Software without restriction, including without limitation 
the rights to use, copy, modify, merge, publish, distribute, sublicense, 
and/or sell copies of the Software, and to permit persons to whom the 
Software is furnished to do so.


"THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN 
NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT 
OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 
THE USE OR OTHER DEALINGS WITH THE SOFTWARE."


There's other ways to word it that would also work.

-uso.


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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Steve Nickolas]

For what it's worth:

I have a 286 I still use.  A 286 is enough for the Win95 version of 
EDIT.COM (it uses some 186 opcodes), so that's usually what I go with.


It's still important to *me* to be able to support 8086 and 286 PCs.  But 
with that said, I've felt that that's best done by me coding the support I 
want my damnself, so far as I can.


And there's the rub...

I have a different style of pretty much everything compared to most of the 
people here (it's a main reason I went my own way and started work on my 
own MS-DOS clone, even though apart from some little pieces of the 
userland I really didn't get all that far).


FreeDOS, for the most part, targets the high end - 386, 486 and beyond 
(this is my perception and my opinion).  I decided to try to target the 
low end and try to bring some of the MS-DOS 6 capabilities to MS-DOS 3.3, 
until I could do something about the lower-level stuff like kernel and 
command.com which are still (despite me writing a nearly complete 
implementation in C of command.com 20 years ago it is too broken to be 
practical) outside my wheelhouse.


But all of this is my opinion.  I was the one who did a bunch of testing 
of FreeDOS back in the day on a really oddball XT clone (the Tandy 
1000HX); that had an 8088.


-uso.


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

Re: [Freedos-devel] MS-DOS compatibility issue

[Steve Nickolas]

On Fri, 29 Jul 2022, Ralf Quint wrote:

Well, not having comments to understand what you are doing is pretty tough 
when you don't have the time to analyze the code line by line. But IIRC, the 
common way to check for the presence of an ANSI device driver was to check 
via an INT 2Fh (multiplexer) call (don't recall the exact call value 
(AX/AH)).


That would only work on MS-DOS 4 or later and I'm not sure NANSI supports 
it, but according to RBIL, it's INT2F/AX=1A00, return FF in AL.


I'm guessing it's only used internally by MS-DOS in stuff like MODE.COM 
(though why MODE needs ANSI for anything, I don't understand...).


-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, Aitor Santamaría wrote:


Once solved the "legal issues", one way to go could be to enrich DISPLAY
instead of making a new driver. DISPLAY is organised as having
"sub-drivers":

DISPLAY CON = (EGA,437,2)

where "EGA" is used to select the sub-driver, 437 is to declare the
codepage that is hardwired in the hardware, and 2 is the number of how many
room for CPIs you want.
Ideally, you could add a "CGA" sub-driver, so that instead of GRAFTABL, one
could issue

DISPLAY CON=(CGA,437,1)

and you save from the TSR stuff, the codepage loading stuff and the
interrupts hooking stuff.

Just an idea that lingered in my mind for a lot of time, although I never
had an enormous interest to care about CGA.

Aitor



I don't think there's any use for DISPLAY.SYS outside of EGA, VGA, and the 
PC Convertible.  There isn't a way to override the text charset, which is 
what DISPLAY.SYS needs.


(I think the PC Convertible is, in fact, the only reason there's even an 
option - it supports loadable charsets, but only in 8x8, so installing a 
full charset, 8x8+8x14+8x16, would be a waste.)


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

Re: [Freedos-devel] Re: Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, Wilhelm Spiegl wrote:


Hi, I just looked at my website
http://home.mnet-online.de/willybilly/fdhelp-108a-internet/en/hhstndrd/base/graftabl.htm
and noticed that the documentation for graftabl from 2007 is extremely short, 
strictly speaking: there is none.
As I never learned what graftabl is really good for, could you please write and 
add at least a short and
understandable documentation and some examples for it. Would be very nice and 
helpful for me and the FD help.

Thx for doing so


It serves a very specific purpose, and isn't very useful these days (which 
is why it was relegated to supplemental with MS-DOS 6 and omitted with PC 
DOS 6.1).


Basically, when you enter graphics mode on a CGA, it gets the first half 
of its character set from F000:FA6E, and the other half from wherever 
INT1F points.  INT1F by default points to nothing in particular so you'll 
get garbage if you try to output 80-FF.  GRAFTABL loads this missing half 
of the character set into RAM, and points INT1F to it.


On an EGA or VGA, DISPLAY.SYS and MODE do everything that GRAFTABL does 
and more, so it makes no sense to install it there.  Also, it doesn't do 
any good in text mode.


When it was introduced in PC DOS 3.0, it only contained one character set. 
This became 4 (437, 860, 863, 865) in 3.3, 5 (850 was added) in 4.0, and 6 
(852 was added) in 5.0.


Because in the time between MS-DOS 5 and 6 it became more common to have 
up-to-date PCs, with VGA, GRAFTABL became even less useful than it was, 
and was relegated to the Supplemental disk starting with version 6.0.


GRAFTABL is the same as GRAFTABL 437, probably for backward compatibility 
with MS-DOS 3.0-3.21.


-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, C. Masloch wrote:


On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
I haven't uploaded a copy of the new source anywhere yet - it'll 
probably be in the next DOSLITE source batch along with my work on a few 
other DOS commands, but I don't want to replace the copy I've already 
uploaded, and DOSLITE isn't ready to go onto anything like github or 
gitlab yet.


I strongly suggest to keep source history. If you'd rather not, you do 
not need to publish that right now but I do recommend you keep it 
privately at least. I started in 2010 [1] and it has been a great 
experience that often proved useful.


Yeah.  "Upload early, upload often" is very much at play here, something I 
learned when I lost the hard drive I was keeping a fansub project on. 
Because I uploaded the raw on BitTorrent and had been maintaining 
timestamped uploads of the scripts on my Web server, nothing was lost.


Several revisions of GRAFTABL that I haven't released, plus the one I did, 
are archived in a folder along with other tools like ATTRIB, CHOICE, 
DELTREE, FIND, LABEL, SORT and TREE, plus my hacks on EDLIN and MORE.  But 
I wanted to get a bit closer to my goal before putting them into "proper" 
revision control - just a few loose commands doesn't feel worth making a 
project on Github or its many clones. (Or into a Subversion or something 
on my own server.)




Not quite: The "ds:" segment override prefixes are unneeded actually. 
NASM will happily emit them, but they eat memory completely 
unnecessarily. "mov word [bx], entry" already defaults to ds as its 
segment. (Unlike addresses including "[bp]" which default to ss.)


I didn't notice those at first because I assumed you were using es. 
That's what your comment in your caller says:


.21:  mov   ax, 0xB001  ; So where is it?
  mov   bx, whence  ; ES:BX gets this.
  int   0x2F


However, the Interrupt List [2] does say it uses ds:bx so your interrupt 
handler is correct, your caller's comment is incorrect.


Oopsie. XD

Maybe I wrote "ES" because a lot of stuff that uses BX with a segment uses 
ES.  I almost never use ES myself - my code generally runs in a 64K space.


Removing the redundant segment escapes does save a few bytes.

-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, C. Masloch wrote:

Your technique is the default way to do this, most TSRs ever written did 
it that way. The SMC is just a small optimisation over it.


Codegolfing is good, when done right. :D

If you really want to continue to use the free software release of 
Microsoft's Debug, you may want to look into the following:


* Some notes on building the original sources, probably not needed if 
you already figured out how to manage that. [1]


Yeah, I'd actually managed to roll a few things before then, though I 
think I may have referenced that later.


* A fix to the CALL 5 bug (that was preserved all the way into the 
latest Microsoft Debug versions) [2]


Yep, started from that codebase.

I think John Elliott might have been the first one to actually roll 
MSDOS.SYS.


* Some discussion on additional bugs in this Debug (might be fixed by 
later MS-DOS Debug) at [3], in particular the fact that it doesn't set 
itself up as self-parented and also fails to create a proper child PSP 
for the client when just assembling into the code segment. The child PSP 
problem is not relevant when loading a program into the debugger.


* For historical reference, there are some versions of the original 
86-DOS Monitor and Debug out there, some of which explicitly note that 
copyright does not apply to them.


Other than that, do have a look at FreeDOS Debug [4] or my repo of its 
history going back decades [5], as well as my fork, lDebug [6]. Another 
fork with fewer changes is debug.gen [7]. There is also Enhanced Debug 
in the same family but that one is not free software, it's not 
redistributable.


Regards,
ecm


Yeah, I'm aware of the PC DOS guy's fork of FreeDOS DEBUG.

It's interesting that in an operating system that is mostly GPL, that one 
component happened to end up X11-licensed, and MS picked the same license 
when they opened up MS-DOS 2.11...


I managed to get EDLIN and DEBUG to roll with WASM with some help from 
someone on Libera, and it was a bit of an undertaking.  EDLIN was easier, 
I think.  But the code is a bit nasty - delves into MS-DOS internals to 
get the current directory instead of just calling GETPWD (AH=47), and uses 
FCBs for everything instead of "Xenix functions".  Like, it's a 
transitional version before all the "Xenix" stuff got fully brought in or 
something.  Eugh.


-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

I haven't uploaded a copy of the new source anywhere yet - it'll probably 
be in the next DOSLITE source batch along with my work on a few other DOS 
commands, but I don't want to replace the copy I've already uploaded, and 
DOSLITE isn't ready to go onto anything like github or gitlab yet.


As I said, I managed to move the CP437 table into the spot reserved for 
the resident table (except for the first 3 bytes), which saved good 
memory, and with C. Masloch's optimizations and by simplifying the version 
check the file size and resident footprint went down even further.  (In an 
earlier incarnation, I had to jigger around 'jmp far 0', but it turns out 
'jmp 0:0' as mentioned was the solution to that.)


The resident footprint went down 1 paragraph, from 1344 to 1328 - now only 
128 bytes larger than the official version.  (I wonder if any of the PSP 
can be just up and deallocated?)


The new "new2F":

new2F:cmp   ah, 0xB0; is it ours?
  je.2
.1:   jmp   0:0
.2:   cmp   al, 1
  ja.1  ; >1 - chain
  mov   al, 0xFF; needs set for both functions.
  je.3  ; 1 - where are we?
  iret  ; 0 - are we here?
.3:   mov   word ds:[bx], entry
  mov   ds:[bx+2], cs
  iret
old2F equ   .1+1

...probably as codegolfed as it's going to get.

The original

  xchg  ah, al
  cmp   ax, 0x0200

has been replaced with "cmp al, 0x02" in a size optimization.

The code following the freeing of the environment has also been replaced 
to close everything first and do things more efficiently.


So far, so good...

-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, C. Masloch wrote:

(Only replied-to portions copied)

Further, you calculate the size of the PSP block to keep resident by using 
test, add, and shifts:


 mov   dx, trans   ; Allow everything preceding the
 test  dx, 0x000F  ;   transient portion of GRAFTABL to
 jz.20 ;   remain resident. (Rounded up to
 add   dx, 0x10;   the next paragraph, because 
MS-DOS

.20:  mov   cl, 4   ;   wants the size in paragraphs.)
 shr   dx, cl
 mov   ax, 0x3100
 int   0x21; TSR EXIT CODE 0

It is more efficient to change this like so:

   mov dx, trans
   add dx, 15
   mov cl, 4
   shr dx, cl

The "add dx, 15" makes the shr round up in its division. (I expect that the 
addition won't overflow here.) However, you can easily change it so that the 
addition is done by the assembler at build time, using "mov dx, trans + 15".


Prolly the 65C02 programmer in me. xD

Another problem (which is also little known) is that your use of interrupt 
21h service 31h will retain all of your currently open process handles, as 
well as the entire system's System File Table (SFT) entries associated with 
these. This is not a problem by default because all your handles will be 
DUPlicated from the parent's, for your stdin, stdout, stderr, stdaux, and 
stdprn. That means they will share the same SFT entries as already used by 
the shell. However, if the user runs your program with output redirection 
(either to a file or a character device such as NUL), as in "graftabl > nul", 
then you will leak the SFT entry which was reserved for your process to use.


I assume that the people involved in the design of this DOS service expected 
that TSRs would generally want to keep around their PSPs, so that they could 
swap processes and then use their own handles as preserved in their process 
handle tables. However, in practice most TSRs never re-use their PSPs after 
the DOS TSR termination handling is done. So in that case, as it is for your 
application, you should explicitly free all handles before terminating.


Here's how I solved it [7] in FDAPM (and with equivalent code in FreeDOS 
SHARE):


xor bx, bx  ; = 0
mov cx, word [32h]  ; get amount of handles
.loop:
mov ah, 3Eh
int 21h ; close it
inc bx  ; next handle
loop .loop  ; loop for all process handles -->


Hm. Probably a good point.

In your executable entrypoint you have a near jump to skip the buffer later 
used for the table data:


entry:jmp   trans
 db1021 dup 0x00

It is implied by the size of the buffer that the jump must be near, so it 
takes 3 bytes, and then you add another 1021 bytes to get a total of 1024 
bytes. (I think the "dup" syntax is only supported by recent versions of 
NASM, but that's not important.) However, I'd prefer to use some calculation 
to get NASM to reliably fill the buffer, such as:


entry:  jmp trans
   times 1024 - ($ - entry) db 0


Alternatively, you could use my fill macro [10] like this:

entry:  fill 1024, 0, jmp trans


(Also, as I think you already suggested in this thread, for optimising the 
transient executable size you could put one of the tables into this buffer to 
save 1 KiB at the end of the executable. (Just the jump needs to stay, you 
could re-initialise it to hold the correct 3byte for the table start later.) 
Or stash some of the messages in there, as long as they're shorter than the 1 
KiB size.)


(I've more recently done this with the CP437 table, because it's the 
default.)


You do not use an IBM Interrupt Sharing Protocol (IISP) [11] header for your 
interrupt hook. Therefore, you could optimise this part a bit, from:


old2F:dd0x
...
.1:   jmp far   [cs:old2F]


Into this:

.1: jmp 0:0
old2F equ $ - 4


This is some self-modifying code (SMC) to stash the downlink into an 
immediate far jump instruction, instead of using the indirect far jump to 
refer to a different memory location in your code segment. The dollar sign is 
used in the equate to denote the current assembly position after the 5-byte 
instruction; it is offset by minus four so as to address the far pointer in 
the instruction's encoding. (As mentioned, you cannot do this if you use a 
standard IISP header, because that has a "jmp short $+18" (EBh 10h) 
instruction right in front of the downlink field.)


I believe it was from analyzing some MS-DOS 2.0 code that I got the 
technique I used here.


Next, you're using "or al, al" to check a register for zero. However, it is 
more idiomatic [12] to use "test al, al" instead, which right away hints (to 
a reader or even to the processor) that no change of the register occurs.


Also not sure where I got the "or" idiom, but I know that it doesn't alter 
the 

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Wed, 13 Jul 2022, TK Chia wrote:


Hello Bret Johnson,

[me:]


GRAFTABL basically just needs to install a 1024-byte glyph table
somewhere in conventional memory, and point the int 0x1f vector at it.
(The glyph table can then be used to display "extended ASCII" characters
in a CGA graphics mode.)  There is no need to even install any resident
code.


I guess I misspoke --- it seems that Steve's implementation of GRAFTABL
hooks int 0x2f, rather than int 0x1f, and does involve a little bit of code.

Thank you!


It hooks both.

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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Wed, 13 Jul 2022, TK Chia wrote:


Well, this is GRAFTABL we are discussing here, so it probably does
qualify as one of the "simplest TSRs". :-)

GRAFTABL basically just needs to install a 1024-byte glyph table
somewhere in conventional memory, and point the int 0x1f vector at it.
(The glyph table can then be used to display "extended ASCII" characters
in a CGA graphics mode.)  There is no need to even install any resident
code.

Thank you!


It actually does need some resident code so that another GRAFTABL can 
detect it, but it's very minimal.  Basically, "if AX=B000, return AL=FF; 
if AX=B001, return AL=FF and copy a far pointer to the graphics table into 
DS:BX; otherwise chain into the old handler." (It's "new2F" in the 
source.)  This change probably happened with the introduction of codepages 
in MS-DOS 3.3.


FWIW, MS-DOS 6.22 MEM.EXE reports a memory footprint of 1344 bytes, vs. 
1200 for Microsoft's version.  That's not a big difference, but it's 
something, and I don't think "uso's code is sloppier" explains it all.


-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, Ralf Quint wrote:


On 7/12/2022 3:01 AM, Steve Nickolas wrote:



For some reason I don't understand (me am n00b) the footprint is 144 bytes 
larger than the MS-DOS 5/6 version, but the binary is smaller. 


Most commonly, these kind of things are due to a different amount of stack or 
other dynamic memory being allocated...


Ralf


For what it's worth, I don't allocate anything.

Could be an issue in my math (generating the paragraph count), or maybe 
I'm including something I shouldn't.  I've never written TSRs before and 
I'm a n00b to ASM.


(I do keep graftabl in revision control as part of a larger project.)

-uso.


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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

On Tue, 12 Jul 2022, Jerome Shidel wrote:

I haven’t looked at the code for either. But, there are some things in 
general to consider with TSRs.


I would assume the memory footprint difference may be related to 
optimization of the executables layout and data storage. Basically, when 
you return to DOS, you release all the memory you don’t need. So, you 
store all the data you do need to keep in the beginning of the program. 
At start, jump past it and do all the initialization stuff. Then free 
everything you don’t need when you call the terminate-but-stay-resident 
interrupt.


You could even use areas of the PSP (program segment prefix) to store 
some data. For example, once processed, you could move data into the PSP 
command line buffer. Another thing, is to free the env segment. Maybe 
even Shuffle your own data and code around at run-time.


Lots of tricks like that.


I do use some of these tricks.  There is code to free the environment, and 
the JMP at the beginning is zapped (it is organized to put the full 
resident portion in one place, starting at CS:0100).


I suppose I could step on zero page (PSP) but I don't know how safe that 
is.  The graphics table is written at CS:0100-04FF (this could be why 
Microsoft's version is incompatible with mine, while mine is compatible 
with Microsoft's).


I could actually probably store most of CP437 up at the top to reduce 
.COM size.


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

[Freedos-devel] Another implementation of GRAFTABL

[Steve Nickolas]

I've been working on this for my own project, and it's only useful for the 
rare CGA or Tandy users out there (which is probably why MS-DOS 6 
relegated it to the Supplemental disk and PC DOS 6 removed it).


GRAFTABL hooks INT1F to provide the upper half of the charset in graphics 
mode on a CGA or Tandy.  (DISPLAY.SYS does this and more on more modern 
display adapters.)  The current version seems to be incomplete - only 
supports a single hardwired codepage? - so I figured I'd offer my own, 
which is my first successful attempt at a TSR that actually does 
something.


I admit that the font data was taken from a copy of EGA.CPI many years ago 
(I think it was the one from Win95, and I extracted it back in 2000 when I 
was reverse-engineering the format).  If that's a problem, feel free to 
replace it with something else, but I used it with the understanding that 
this kind of font data can't actually be copyrighted; take that as you 
may. (IANAL)  The code should be pretty well organized.  The command-line 
help is also extracted from MS-DOS if that's a problem - feel free to 
rewrite it, it's UIUC-license (essentially the same as 3-clause BSD).


https://6.buric.co/graftabl.a86

Just use "nasm -o graftabl.com graftabl.a86" to build it.
Use "nasm -DHELP -o graftabl.com graftabl.a86" to add the command line 
help.


My implementation is based on RBIL and poking at the binary black-box 
style.


For some reason I don't understand (me am n00b) the footprint is 144 bytes 
larger than the MS-DOS 5/6 version, but the binary is smaller.


-uso.
(My preference for UIUC licensing is, admittedly, a bit strange; 
originally I preferred BSD but I think UIUC is a little safer against the 
kind of rules-lawyering that affected PINE.  It's basically the BSD 
license with the first paragraph replaced with that of the MIT/X11 
license.  Again - IANAL, I just don't really care what others do as long 
as they don't claim they wrote it.)



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

Re: [Freedos-devel] Historical vs. Hysterical Edlin Versions

[Steve Nickolas]

On Thu, 12 May 2022, Gregory Pietsch wrote:


FreeDOS Mavens,

I'm thinking of editing Edlin to match historical behavior after downloading 
a 1982 IBM DOS manual and a 1987 Microsoft OS/2 manual I found floating 
around the 'Net. I want to make Edlin still the small program it has always 
been without adding things that would make the executable super-huge, so I 
want to get some feedback from the list before I do anything.




Well, there wouldn't be anything wrong with poking around at the MS-DOS 
2.11 version since it's MIT-licensed now and we legally have the sauce ;)


-uso.


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

Re: [Freedos-devel] How to work with FAT12 in FreeDOS 1.3

[Steve Nickolas]

On Sat, 23 Apr 2022, richardkolacz...@hotmail.com wrote:

I cannot find a way to reformat just the D:\ partition into a FAT12 - 
neither via Windows, CMD or so far by FreeDOS. I was aiming for a 256 MB 
FAT12, but if this is not possible then a 32 MB FAT12 will do.


Both of those are too big for FAT12.  256 MB would require BIGFAT (which 
is a variant of FAT16), and even 32 MB really needs FAT16.


-uso.


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

Re: [Freedos-devel] "FreeDOS Next" packages

[Steve Nickolas]

If you want my personal opinion, just distribute what more or less 
reproduces MS-DOS/PC DOS/DR DOS functionality as part of the release 
proper.


-uso.


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

Re: [Freedos-devel] FreeDOS virtual get-togethers in 2022

[Steve Nickolas]

On Fri, 11 Feb 2022, Jim Hall wrote:


** In January, we used Zoom as a test. For February, we're back to
using BlueJeans (I use them for my training/consulting business). The
BlueJeans support folks have given me a few pointers to improve
performance, so I'm hoping this session will work better. (For
example: the desktop client is better than the web client - I've
already switched, and it's much smoother for me.)


Huh. Didn't know they were Verizon. (Verizon was my ISP for many years and 
my telco for even longer.)


-uso.


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

Re: [Freedos-devel] REMember a bug

[Steve Nickolas]

On Sun, 16 Jan 2022, Jim Hall wrote:


I have a paper copy of a few original MS-DOS manuals. My MS-DOS 4
manual says the only separators allowed in a comment are whitespace
but didn't mention redirection. But the MS-DOS 5 manual specifically
says *not* to use redirection in REM.

So this was a known issue in MS-DOS. It was later fixed in the Windows
CMD prompt, but the feature exists in MS-DOS COMMAND. And I think it's
important to meet the features of MS-DOS.

And it's a weird one, because one would think that REM would ignore
the *rest* of the line, like any comment. And that was probably the
intent, but that's not how it was implemented. Instead, you get MS-DOS
behavior like this:

REM > file.txt

..and then you get a zero-length FILE.TXT.

So I think the feature should stay as-is in FreeDOS. We implemented
this just like MS-DOS did. And that's good.


(I quoted a scanned manual from PC DOS 2.00, which was the first version 
that supported I/O redirection.  This behavior was documented there as 
well.)


-uso.


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

Re: [Freedos-devel] is there anyway i can contribute to freedos's development with C++?

[Steve Nickolas]

On Tue, 11 Jan 2022, Tyson Oswald wrote:

I found C++ at least with Watcom to not support the standards, at least 
current ones. I had to rollback to C as I didn’t want to get used to 
non-standard C++. DJGPP might be better I do not know.


Well, I have a DJGPP install from some time ago and it has G++ 8, so no 
doubt you'll have support for modern C++ with it.  Of course, the usual 
proviso about using DJGPP applies.


I actually switched from learning C++ to regular C because of FreeDOS.  Of 
course this was over 20 years ago.


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

Re: [Freedos-devel] Pushing source code to Github

[Steve Nickolas]

On Sun, 9 Jan 2022, Jim Hall wrote:


When you edit with Pico, you're really editing with an email composer.
Pico stands for the Pine Composer.  Pine was an email client that replaced
another email client called Elm.  Pine stands for Pine Is Not Elm.


And "nano" is a clone of "pico".

I still use pine to this day (in the form of "realpine").

-uso.


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

Re: [Freedos-devel] REMember a bug

[Steve Nickolas]

On Sat, 8 Jan 2022, Jerome Shidel wrote:


Hi all,

As everyone knows and the docs clearly state, everything after a REM is ignored.

However, I recently noticed an issue with a batch file that had something like:

REM this thing [[x|4]] or later

in one of its remarks. Every time the batch was executed, it displayed a 
“4]]” command not found error.


Out of curiosity, I checked under MS-DOS 6.22. It exhibited the same 
behavior. I have a vague recollection of noticing this decades ago as 
well.


It is a bug. But, it’s a bug that MS-DOS has as well. 


What’s you opinion? Should FreeCOM replicate this “feature” or  fix the bug?

Personally, I think it should be fixed. No one should be using that. If 
they were, I feel they are technically just exploiting a bug and there 
is no obligation to continue supporting that “feature.”


I don’t/won’t work on FreeCOM. I’m just curious about your thoughts on this. 


:-)

Jerome


I think it's neither a bug nor a feature, but normal operation (daft, but 
internally consistent).


My own command interpreter (which is buggy AF) does the same thing as 
MS-DOS 6.22.


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

Re: [Freedos-devel] Wordy - a word puzzle game (sample code)

[Steve Nickolas]

On Fri, 7 Jan 2022, Jim Hall wrote:


Hi everyone

I wrote a quick sample game that is kind of fun, so wanted to share it.

Wordy is a word puzzle game for DOS. You have six attempts to guess
the mystery five-letter word. After each guess, the game highlights
your letters: black if that letter does not exist in the mystery word,
orange if the letter exists but not in that location, green if the
letter exists in that location.

If you've heard of the Wordle game (an online free word puzzle game)
Wordy is basically that.

I've posted the code at:
https://github.com/freedosproject/wordy

(MIT license)

I haven't added the code to pick a random word from a list of possible
five-letter words. This was just some sample code so I didn't do that.
But the code is easy enough to update; feel free to send a pull
request. (I'd add a function to main. That's probably the easiest way,
and what I had in mind when I wrote Wordy.)


Jim


Sounds like a fancier version of a number game MECC used to call "Bagels".

-uso.


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

Re: [Freedos-devel] The FreeDOS Orphanage

[Steve Nickolas]

On Wed, 1 Dec 2021, Liam Proven wrote:


Fair. For me, I left the IBM reseller that was my first job and moved
to a much smaller company, so I stopped working with a mixture of PC
DOS and MS-DOS and switched to mostly MS-DOS, with a little DR DOS.


Meanwhile I started out with PC DOS 3.2, and mostly used the IBM dialect 
on my first couple machines.



There has been a little bit of renewed interest in PC DOS from the
late '90s onwards, especially with the recent retro-gaming trend,
because IBM continued development for some time, into this century,
while Microsoft switched focus to Windows only. Connectix' VirtualPC
program -- a PC emulator on MacOS, but a hypervisor on Windows -- used
to bundle PC DOS 2000 for free as its sample VM. So I suspect that a
bunch of new users first encountered it that way.


And PC DOS is more compatible with MS-DOS than other DOSes, because, well, 
it *is* MS-DOS.



I run it PC DOS some of my Thinkpads, simply because it feels
artistically _right_ somehow to run an IBM OS on what was originally
IBM-designed hardware. :-)


Likewise my PS/2 runs PC DOS.

-uso.


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

Re: [Freedos-devel] The FreeDOS Orphanage

[Steve Nickolas]

On Wed, 1 Dec 2021, Liam Proven wrote:


On Wed, 1 Dec 2021 at 02:27, Steve Nickolas  wrote:


The division actually happened earlier - after 5.0.


So Wikipedia said. I have not personally seen PC DOS after 4 but
before 6.3, so I can't say from direct personal knowledge.


I have a boxed copy of 5.00.1.


  From 3.2 to the
second issue of 5.0 (and in fact the second issue of MS-DOS 3.1) the two
releases are effectively the same


[Nod]


 the difference between FC/RAMDRIVE and COMP/VDISK.


Could you elaborate on that, please, just to satisfy my curiosity?


MS-DOS had FC (written in C in 3.x and later) and RAMDRIVE, while IBM had 
COMP (still written in ASM; simpler and not as powerful) and VDISK.


5.0 had both.


Although one feature did migrate from PC DOS to MS-DOS: Interlnk, which
appeared first in PC DOS 5.02, and then MS-DOS 6.


That I did not know! Fascinating. A little-regarded but very useful
tool, Interlink. I think I wrote somewhere that it still works with
NT, if you just run one end in a DOS command prompt (can't find it
now, though.)


I'm not sure too many people know much about PC DOS versions after 4.01, 
or really other than 2.1 and 3.3.


-uso.


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

Re: [Freedos-devel] The FreeDOS Orphanage

[Steve Nickolas]

On Tue, 30 Nov 2021, Liam Proven wrote:


On Tue, 30 Nov 2021 at 22:35, Steve Nickolas  wrote:


On Tue, 30 Nov 2021, Deposite Pirate wrote:


PC-DOS is also strictly better than MS-DOS. Don't know of a valid
reason for anyone to bother with the latter anymore.


For the most part, PC DOS *is* MS-DOS.


Well, I agree with both of you. :-D

Up until the last version of MS-DOS, 6.22, they were largely identical, yes.


The division actually happened earlier - after 5.0.  From 3.2 to the 
second issue of 5.0 (and in fact the second issue of MS-DOS 3.1) the two 
releases are effectively the same, apart from MS-DOS getting a few things 
before PC DOS, and the difference between FC/RAMDRIVE and COMP/VDISK.


Although one feature did migrate from PC DOS to MS-DOS: Interlnk, which 
appeared first in PC DOS 5.02, and then MS-DOS 6.


-uso.


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

Re: [Freedos-devel] The FreeDOS Orphanage

[Steve Nickolas]

On Tue, 30 Nov 2021, Deposite Pirate wrote:


On Tue, 30 Nov 2021 16:31:00 +0100
Liam Proven  wrote:

Lest anyone accuse me of spamming: this isn't mine; I make nothing
from it; I do not work for IBM or any part of it. I'm just sharing
info.



PC-DOS is also strictly better than MS-DOS. Don't know of a valid
reason for anyone to bother with the latter anymore.


For the most part, PC DOS *is* MS-DOS.

-uso.


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

Re: [Freedos-devel] Does FreeDOS (or something) sometime automatically break up an hard disk in 2GB sub-disks?

[Steve Nickolas]

On Wed, 6 Oct 2021, tom ehlert wrote:




users will have FAR more than 60 GB disk size and you can
have only 24 drive letters from C: to Z:



Up to 32 under some DOS/Windows versions:
https://en.wikipedia.org/wiki/Drive_letter_assignment#Common_assignments


while technically true, it just doesn't make ever sense to have setup
split *automatically* a hard disk into 24 (or 32) partitions.

this auto partitioning option(?) simply should go the way of the dodo.

Tom


For what it's worth, while MS-DOS and PC DOS autopartition, DR DOS 
doesn't, and just runs FDISK.


That is probably the better route?

-uso.


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

[Freedos-devel] The "choice.asm" I was talking about on the FD chat

[Steve Nickolas]

I did this a couple weeks ago but didn't think it was important enough to 
mention, plus it's not actually an improvement over the current version. I 
was talking about how I had just entered the world of 8088 ASM coding, and 
had been thinking about creating minimalist versions of DOS utilities.


Anyway, this came up in the side chat during the videochat today, and I 
thought I might mention it here, even though there's really nothing of any 
actual interest (in my opinion):


http://6.buric.co/choice.a86.txt

It's written with NASM (the version I rolled it with, since I have Debian 
11, is 2.15.05); it just rolls to a 678-byte binary.  (I also rolled it 
with yasm 1.3.0 with the exact same result.)


-uso.


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

Re: [Freedos-devel] List of blocking issues for FreeDOS 1.3

[Steve Nickolas]

On Sat, 28 Aug 2021, thraex wrote:


Finally, I would like to ask a question: if memory serves me well, there
was an automatic network detection in FreeDOS 1.2 in VirtualBox.  A
message beginning with "Good new everyone" announced it. Would it be
possible to keep that feature for FreeDOS 1.3?


IIRC, the "Good news, everyone!" message comes from MTCP's DHCP client.

-uso.


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

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for Fr eeDOS 1.3]

[Steve Nickolas]

On Tue, 10 Aug 2021, Bret Johnson wrote:

The problem with this approach is something like Belgium.  Somebody 
correct me if I'm wrong, but Belgium does not have its own language -- 
some parts of the country are French and other parts are German.  There 
is a Belgian country code and a Belgian keyboard layout (which I think 
is a "hybrid" between French and German).  If everything points to 
Belgium but LANG isn't set, I'm not sure the right thing to do is write 
messages in English even though that's the only logical thing to do.


Semi-right; I think you've mistaken Dutch for German. Two of my friends 
(one of whom runs about half of my IRC network) are from Belgium and their 
language is Dutch.


(I do believe German *is* spoken in a small corner of Belgium though.)

-uso.


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

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Steve Nickolas]

On Sun, 8 Aug 2021, Volkert via Freedos-devel wrote:


As you can see in his existing repositories on GitHub (
https://github.com/sudleyplace ), Bob seems partial to the GPLv3, so I
guess that would be acceptable to FreeDOS, right? 


My understanding is GPL3 is fine.


Anyway, I opened an issue in his DPMIONE project on GitHub, with a request
for a release of the 386MAX source code:
https://github.com/sudleyplace/DPMIONE/issues/3


(me)


Isn't it not only a replacement for EMM386, but also for MEMMAKER?


I have no idea. I never used 386MAX back in the day, but if it came with a
MEMMAKER-like utility, perhaps that will be included in the source code,
should he decide to release it.

Perhaps you can ask him in that GitHub thread.


I never did either.  But I'm pretty sure its chief competitor, QEMM, did.

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

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Steve Nickolas]

On Sun, 8 Aug 2021, Volkert via Freedos-devel wrote:


It turns out that writing another EMM386 reimplementation from scratch
might not be necessary after all.

Do you remember this thread from 2012? I see you participated in it as well:

https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668

In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) mentioned
that with enough interest, he would be willing to "release the source code
for Qualitas MAX (a.k.a. 386MAX)".

In that same thread in 2012, BretJ mentioned that 386MAX supports the same
I/O port trapping API as the one offered by Microsoft EMM386. Also, 386MAX
supports GEMMIS.

So this might be the ideal solution for both these problems! :) I'll try to
reach out to him to ask him if he would still be willing to release the
source code.


:O

If 386^MAX could be released under suitable terms (for example the 4DOS 
terms are problematic) then that would be something major to add to 
FreeDOS.


Isn't it not only a replacement for EMM386, but also for MEMMAKER?

-uso.


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

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

[Steve Nickolas]

On Fri, 6 Aug 2021, tom ehlert wrote:


Hi Robert,


attaches the german resources to fdisk.exe, and makes german the
default language for fdisk.exe.



Minor note: AFAIK, correct spelling of "german" in English is "German"
with a capital "G". Same for all other language "names".


really? Like in 'Could you provide the German resources?'

if true, I have done that wrong for the last 50 years.

Insights from native english/american  (English/American) people?

Tom


Yes, all would be capitalized.

(That said, I use a bastard version of English, so...go figure.)

-uso.


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

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Steve Nickolas]

On Thu, 29 Jul 2021, thraex wrote:


There's a saying in French, something like "The best is the enemy of
good".


As "Perfect is the enemy of good enough", it is almost a mantra in my 
circles.


-uso.


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

Re: [Freedos-devel] video FreeDOS running Windows 3.1

[Steve Nickolas]

Followup to my last comment, since I actually went and checked.

On Sat, 24 Jul 2021, Steve Nickolas wrote:

For what it's worth, Windows 3.x comes with its own versions of HIMEM and 
SMARTDRV.  I *think* it also comes with EMM386, but I'm not so sure about 
that one.  Have to check my setup disks.


Answer: It comes with its own HIMEM, EMM386, SMARTDRV and RAMDRIVE.

-uso.


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

Re: [Freedos-devel] video FreeDOS running Windows 3.1

[Steve Nickolas]

On Sat, 24 Jul 2021, Eric Auer wrote:


I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft
EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually
necessary? I would expect things to also work with HIMEMX or XMGR,
as long as no free EMM386 is loaded at all? Why do you use 4DOS in
the DOS window inside Windows? Any special system.ini [386enh] items?
See my notes below :-) Is setting VERSION=6.0 required, too?


For what it's worth, Windows 3.x comes with its own versions of HIMEM and 
SMARTDRV.  I *think* it also comes with EMM386, but I'm not so sure about 
that one.  Have to check my setup disks.


I think Windows' 386 mode is pretty heavily tied into undocumented 
features of EMM386 when it is active, so it wouldn't surprise me if a free 
version of EMM386 made it go down in flames.


-uso.


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

Re: [Freedos-devel] Pacific C Shareware version at ibiblio

[Steve Nickolas]

On Fri, 2 Jul 2021, tom ehlert wrote:




Not sure if anyone will be concerned but just found that ibiblio
(https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/pacific/)
is mirroring the shareware version of Pacific C (circa 1998), while
during 2000 they release the same version as freeware with no
shareware nags. They can be got from
https://web.archive.org/web/20040215154614/http://www1.htsoft.com:80/files/pacific/pacific.exe



so to summarize: nobody has cared about Pacific C or it's licensing
for the last 20+ years.

RIP

Tom


Two reasons.

1. Borland's freeware release of Turbo C 2.01 and later Turbo C++ 1.01, 
which had better C runtimes.


2. OpenWatcom, which had pretty much everything Borland did, and wasn't 
just freeware (though it needed a beefier host computer).


-uso.


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

Re: [Freedos-devel] Additional notes on Games

[Steve Nickolas]

On Thu, 17 Jun 2021, Eric Auer wrote:

If you really worry about people getting confused by GNUCHESS, but 
really refuse to load NANSI by default, you could simply provide a batch 
file to first load NANSI, then GNUCHESS and bundle that batch file with 
GNUCHESS. You can even make that batch file check whether NANSI already 
is loaded.


My personal opinion is that on DOS, GNUCHESS should be adjusted to use 
something like conio instead of requiring ansi.sys, which is really a 
hack.


-uso.


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

Re: [Freedos-devel] Additional notes on Games

[Steve Nickolas]

Here's the problem, as I see it.

A lot of people misuse the terms "open source" and "public domain".  They 
say "open source" when they mean source-available (it may not be open, if 
it is not as I describe "freedom-compliant"), and they say "public domain" 
when they mean freeware.


When I say something is public domain, I add the phrase "all copyrights 
are disclaimed" to make it clear and unambiguous that it is indeed "public 
domain" that I meant and intended.  In one case I also added a CC0 logo to 
make it not only doubly but triply clear what my intention was (in a sort 
of Lewis Carrollian "what I say three times is true").


Err on the side of caution, IMO: if the intent is ambiguous, assume the 
less free interpretation.


-uso.


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

Re: [Freedos-devel] FreeDOS 1.3 packages

[Steve Nickolas]

On Tue, 8 Jun 2021, Deposite Pirate wrote:


June 8, 2021 4:46 AM, "Eric Auer"  wrote:

check? * Maybe not even both FREEDOOM and BOOM at the same time


Freedoom is a free Doom compatible WAD and boom is a doom engine
source port. You always need Freedoom along with a doom engine to
have a full Doom-like game.


Was going to say the same thing.

FreeDOOM is the assets, BOOM is the game engine.  You need both.

-uso.


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

Re: [Freedos-devel] FreeDOS 1.3 packages

[Steve Nickolas]

On Mon, 7 Jun 2021, Jim Hall wrote:


No problems with keeping both EDLIN and EDIT. These are standard DOS
programs, and I don't know why we would remove either of them.


Even Microsoft agreed.

MS-DOS 5 and 6 and PC DOS 5 have both.  PC DOS 6 has both EDLIN and E, 
though PC DOS 7 dropped EDLIN.


-uso.


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

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Steve Nickolas]

(Although the message was e-mailed to me personally, I was asked to reply 
to the list, so I did.)


On Mon, 31 May 2021, Eric Auer wrote:


Hi Steve,


That's what DRIVPARM is for.  I used to use it on my old Tandy 1000HX
because the firmware, being XT-class, reported the A drive as 360K when
it was actually 720K.


Thanks! First hardware which acually DOES need it :-) I
think we do not have DRIVPARM in the kernel yet either?


Can't remember. I know I commented on issues running FreeDOS on a Tandy 
1000HX, but this was literally 20 years ago.



DRIVER.SYS did the same thing but it created a virtual floppy drive with
its own letter, and when that drive was accessed, it had DOS ask for a
disk swap.


Are you sure? Maybe it just was for drives which were not even
reported as existing at all by the BIOS, but which were real?


It's actually why I used it back in the day.

Most of what one would use driver.sys for, honestly, drivparm made 
redundant.  But driver.sys was supported earlier than drivparm.


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

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Steve Nickolas]

On Mon, 31 May 2021, Eric Auer wrote:


PS: FreeDOS does not include a DRIVER.SYS driver, or feature.
That was a very ancient MS DOS feature which let you override
BIOS based detection of floppy drives and their geometry, see

http://info.wsisiz.edu.pl/~bse26236/batutil/help/DRIVER_S.HTM

Maybe we COULD add a config.sys command instead of a device=...
driver, but I do not know any hardware needing it? Basically, it
tells DOS a BIOS disk drive with any given CHS geometry exists.


That's what DRIVPARM is for.  I used to use it on my old Tandy 1000HX 
because the firmware, being XT-class, reported the A drive as 360K when it 
was actually 720K.


DRIVER.SYS did the same thing but it created a virtual floppy drive with 
its own letter, and when that drive was accessed, it had DOS ask for a 
disk swap.


-uso.


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

Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)

[Steve Nickolas]

On Mon, 31 May 2021, Mercury Thirteen via Freedos-devel wrote:


+1

Personally, I always thought it would be best to have this "phantom 
drive" feature disabled by default and allow the user to enable it if 
they need. But that's just me. :)


Personally, I'd go with the opposite: behavior compatible with MS-DOS 3.3 
ought to be the default because it's what most people would expect from 
software that has as its primary compatibility target Compaq MS-DOS 3.31 
(not sure if that's still accurate, it's certainly been a long time since 
I checked).


But with that said:

1. Allowing it to be disabled isn't a bad idea. (I'd go with SWITCHES=/B 
personally, but there's other options too.)


2. One could say that's what something like DRIVER.SYS is supposed to be 
for...and indeed, a virtual floppy drive created with DRIVER.SYS under 
MS-DOS or PC-DOS will trigger the "Insert diskette for drive X: and press 
a key when ready..." prompt, just like the virtual B drive.


-uso.


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

Re: [Freedos-devel] Cleanup on FreeDOS Ibiblio

[Steve Nickolas]

On Wed, 12 May 2021, Mercury Thirteen via Freedos-devel wrote:

A side note/gripe here: Traditionally (at least the way I have learned 
it) you only increment the major version when making a major change to 
the application - e.g. changing the structure of files saved by the 
application or perhaps a major overhaul of how things work internally. 
With that in mind, how, pray tell, could Firefox possibly be at 88.0? 
Mozilla, do you mean to tell me you made sweeping, application-wide 
changes eighty eight times? I think not lol :)


It's called version inflation.

Seamonkey rebased off 1.9.1 Gecko for 2.0 ... and did normal version 
incrementing while Firefox started going up ridiculously. 2.10 was based 
on Firefox 13, and the current version is 2.53.7.1, which is much more 
reasonable.  Edge, OTOH, is up into the 90s already!




Gah, ok you got me there. I hadn't thought of the kernel at all. Off the 
top of my head, though, I'm not certain; is 2042 a version number in and 
of itself or just a revision/build number?


I think it's a build number - there's a separate version number but I 
don't think it's been updated in a while?


-uso.


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

Re: [Freedos-devel] Cleanup on FreeDOS Ibiblio

[Steve Nickolas]

On Sat, 1 May 2021, Jim Hall wrote:


Using "2.02.01" is an interesting solution, but then the "version
number" on the filename no longer matches what's in the documentation
- or reported by the program when you run it. If the program outputs a
version number that's "2.1" (and uses "2.1" in the documentation) and
we rename the file to "2.01" .. that will confuse people too.


I call it "Tandy numbering", since that's how Tandy used to do version 
numbering.



There is no 100% perfect solution. :-(


Too true.

Would've been nice to standardize on a specific method of numbering but 
it's about 27 years too late for that. ;)


-uso.


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

Re: [Freedos-devel] FreeDOS as a unikernel?

[Steve Nickolas]

On Mon, 1 Mar 2021, Pablo Pessolani wrote:


Thanks Geraldo.

Dosemu: I think that with Dosemu, Linux "emulates" DOS system calls and 
environment. It doesn't run a DOS kernel in userspace. i.e. It 
intercepts DOS system calls and converts them to equivalent Linux system 
calls.


dosemu actually does run a DOS kernel.  I use that of PC DOS 7 in mine. 
It uses a shim to allow access to the local filesystem.


-uso.


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

Re: [Freedos-devel] DOS runtime library format

[Steve Nickolas]

On Tue, 29 Dec 2020, Mercury Thirteen via Freedos-devel wrote:


On Tuesday, December 29, 2020 11:44 AM, Steve Nickolas usots...@buric.co wrote:


...
I've had ideas for what I'd do if I were writing my own OS or my own DOS 
clone... but they'd probably be too weird for this list.
...


But I, for one, would love to hear those ideas.


Well, maybe some people would be interested. ;)  Feel free to ignore the 
rest of the post, because it's really gonna go off into lala land, 
although some of it does relate to FreeDOS.


I actually really dig DOS, although I'd prolly stir in a little bit of 
OS/2 and NT if I were coding for a more advanced CPU.  And prolly make the 
shell a bit more like the Bourne shell - which really isn't that big a 
deal, the Bourne shell was a major influence on COMMAND.COM.


I've had ideas for bootstrapping a DOS using a separate IPL - and in fact 
FreeDOS did do this at one point.  This way, I'd be able to keep basic 
drivers out of the main kernel, enhancing portability - which wouldn't be 
a big deal with PC-compatibles, since the basic drivers would essentially 
be the same.  But on other systems, maybe you would want to be able to 
swap IPLs (one for floppy disks, one for FAT16, one for FAT32 as an 
example), or swap console drivers (maybe you're running on a system that 
doesn't speak BIOS and needs to speak to the keyboard and display some 
other way)...and keep the kernel itself down to a minimum, just plugging 
in what it needs at boot time.  And with this kind of a system, things 
like mouse.com or mscdex.com wouldn't be implemented the same way they are 
on DOS.


What I think would result from this is a sort of modularity similar to 
Linux, but with a more DOS-like footprint.  At this point it wouldn't be 
DOS anymore - it will have sacrificed too much, and will have morphed into 
a strange mutant beast, perhaps similar to Microsoft's unreleased "XEDOS", 
not quite DOS, and not quite a Unix, but somewhere in between, where it 
would load like Linux, the command line would feel about like Linux but it 
would more or less be able to run MS-DOS applications.


On the other end, I've been doing some experiments with UEFI, and mused 
about the possibility of creating a 64-bit "DOS".  Again - wouldn't quite 
be DOS.  But it would almost resemble OS/2 1.0, with its task switcher, 
and the ability to run DOS apps - transparently, not in a penalty box like 
OS/2 1, but like 32-bit Windows.  This could be more DOS-like; but the 
more I thought about it the more I realized it would bear far more 
resemblance to OS/2 without the Presentation Manager.  It would probably 
have to have NT-like USB support, allocating drive letters on the fly - 
and it would need to emulate legacy hardware for the sake of legacy 
software, although newer and cleaner APIs could be provided to expose the 
real hardware to native software.  The command shell would need to more or 
less emulate CMD.EXE.  This concept would also need to be able to emulate 
stuff like GO32 and DOS/4GW, for the many 32-bit DOS apps that rely on 
them.


-uso.


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

Re: [Freedos-devel] DOS runtime library format

[Steve Nickolas]

On Tue, 29 Dec 2020, DosWorld via Freedos-devel wrote:


Was there ever any "official" format for a shared runtime library under MS-DOS?
...
Any constructive feedback would be appreciated! :D


Here is no any standard. I can purpose few way:
Experimental library format in msa2 - 
https://github.com/DosWorld/msa2/tree/master/original/examples/OVL-TP7
Way, described into Turbo Pascal 3. Here is example, how to use GRAPH.BIN 
library (from TP3) into other languages. Imho, here is no problem link it 
static or dynamic.
https://github.com/DosWorld/pl2/blob/main/EXAMPLES/TP3GDEMO.PL2
https://github.com/DosWorld/pl2/blob/main/LIB/TP3GRAPH.PL2

Also, we have BGI - this is about graphics, but it is shared library.
And next way - "everything is a file" (this is unix way) - write library as 
device driver (.sys)

One more - load unix a.out format (it is easy and well documented).

And last way, (more hard) - dynamic loading .obj file. .obj contains all 
required info.


I've thought of the possibility of using ELF.  Never got off the ground 
though.


I've had ideas for what I'd do if I were writing my own OS or my own DOS 
clone... but they'd probably be too weird for this list.


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