Re: [Freedos-devel] Setting up the new FreeDOS documentation project at GitLab

2024-07-21 Thread Jim Hall via Freedos-devel
I probably have access to do that too. (I wrote my email at 11pm, too tired
to try it out .. and fix it if I messed something up.)

But I'll let Jerome do it (if he doesn't mind) to make sure all the options
are set right.

I agree with you about pushing directly rather than pull requests, and
using the unstable branch. Good ideas.

I also have a bunch of docs to put in right away. For a start, I'll add
condensed how-tos based on the articles I've written for OpenSource and
elsewhere.

The FreeDOS books will go in here too, including an update for Why We Love
FreeDOS (someone requested edits to their contribution, this is a good
opportunity to move it at the same time). I'll have to look at how to
organize them, so that might be lower on the list than the other how-to
docs.


On Sun, Jul 21, 2024, 3:18 AM Bernd Böckmann via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
>
> > Am 21.07.2024 um 06:08 schrieb Jim Hall via Freedos-devel <
> freedos-devel@lists.sourceforge.net>:
> >
> > What do we need to do next to set up a "Documentation" subproject
> > (shared subdirectory) at https://gitlab.com/FreeDOS where we can start
> > working on documentation?
>
> I think only Jerome has the permissions to create the repository under the
> Gitlab FreeDOS organisation. So first step would be that he creates the
> repo and assigns some permissions to us.
>
> For simplicity I suggest that we will push directly to this repo instead
> of everyone forking it and creating somewhat labour intensive merge
> requests.
>
> For some packages, there is an unstable branch. I recommend to also use
> this for checking in documentation. We can then transfer articles we are
> satisfied with to the main branch, which can then be converted to HTML by a
> workflow and put somewhere on a HTTP server.
>
> For the start I would like to write some guides how to cross-compile to
> the DOS target from different operating systems and compilers.
> Documentation for the latest tools (GCC-IA16, OpenWatcom v2 on Mac, Linux)
> seems to be a little sparse.
>
> Bernd
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


[Freedos-devel] Setting up the new FreeDOS documentation project at GitLab

2024-07-20 Thread Jim Hall via Freedos-devel
Following up:

The previous thread didn't develop further, so I am taking that as
consensus. Summary: We liked Bernd's and Jerome's and Wolf's
suggestions to put a "Documentation" subproject under the
https://gitlab.com/FreeDOS shared project in the FreeDOS GitLab, so we
can share working on documentation, in markdown, and work in the open.
I can automate (weekly? daily?) a process to pull that to a new
"docs.freedos.org" site and convert (pandoc?) from markdown to html,
so it's easy to view. We can use a similar process to create viewable
documentation to include in the FreeDOS distribution, so users have
access to the documentation on a running system.

What do we need to do next to set up a "Documentation" subproject
(shared subdirectory) at https://gitlab.com/FreeDOS where we can start
working on documentation?

From the previous conversation, using markdown seems like the best way
to go. We'll want to set up subdirectories for 'guides' and 'about'
and 'info' (and later, 'help')


Also: A former tech writing student of mine recently asked about
contributing to the FreeDOS documentation - very convenient timing! So
if we can set up the GitLab subproject, we'll have another volunteer
ready to help!


On Sat, Jul 6, 2024 at 12:16 PM Jim Hall  wrote:
>
> On Sat, Jul 6, 2024 at 5:12 AM Bernd Böckmann via Freedos-devel
>  wrote:
> >
> > Like Jerome I also would prefer to put the repository under the
> > Gitlab FreeDOS group[1] or alternatively under the fdos[2] group at
> > Github. Gitlab would be the more logical choice, I think. But Github
> > would have the benefit that there are still more people with an account
> > for it.
>
> Well, it won't be under "FDOS" because that's not "The FreeDOS
> Project." FDOS is Jeremy's project, I think. (I don't think I knew
> Jeremy was using the FreeDOS fish on the "FDOS" GitHub - he probably
> should use something else or it will confuse people to think that's an
> official FreeDOS GitHub.)
>
> I like the idea of putting the docs under the FreeDOS GitLab group at
> . That's where we host a live copy of the
> source code, so it makes sense to put the documentation there too. The
> process is the same to download a zip archive of everything in a
> repository/folder. For example, anyone can download the code to Choice
> with this:
> https://gitlab.com/FreeDOS/base/choice/-/archive/master/choice-master.zip
>
> ..so it's easy enough to automate grabbing a snapshot of the Markdown
> docs as a zip file (GitLab also supports tar.gz, tar.bz2, and tar).
>
> > I like Wolfs idea of automatically generating a "documentation site"
> > from the Git repository. He mentioned hugo[3] as a static site
> > generator. This seems to be a good fit. mdbook[4] would be a more
> > documentation focussed software, but is not nearly as flexible as hugo.
>
> It's actually pretty easy to create a "documentation site" without
> using a static site generator like Hugo. Once you have the Markdown
> files, it's just a matter of putting everything into a place that a
> display system can find it. That's pretty easy for me to set up.
>
> > From the beginning, we should put an emphasis on also generating proper
> > (with a table of contents etc.) PDFs from the documentation.
>
> I think we can do that automatically using pandoc, which we'd need to
> do anyway to turn Markdown into HTML.
>
> > Like already mentioned, having the documentation in markdown format
> > would give us the opportunity to automate many things, like building an
> > offline documentation from it. As Jim noted, we should establish some
> > form of code style considering the constrains given by the different
> > output formats and target system we would like to support. A few things
> > / questions come into my mind:
> >
> > - Restrict to UTF-8 encoding to make conversion to different DOS
> > codepages for translated documentation straightforward
> >
> > - Verbatim text like code snippets should be restricted to 78 characters
> > a line, so that it fits without a line break on a DOS screen, or
> > alternatively create a viewer for it that supports horizontal scrolling
> > on the verbatim text while reflowing the "ordinary" text paragraphs.
> >
> > ? Technically, while I doubt anyone is using it at all, there is a 40
> > column text mode. While probably not worth dealing with this it would
> > not be a bad thing to design everything that this could be supported
> > at some time.
> >
> > ? Maybe using things like tables should be considered a "do not",
> > because it is questionable if these look good on a 80 (or even 40)
> > column display when converted to a different format for offline viewing
> > under DOS. It could be made to work if the tables get converted to
> > verbatim text blocks and the horizontal scrolling thing gets implemented
> > in a DOS viewer.
> >
> > ? We should think about how to generate some form of index for the
> > documentation. This would be especially important for the DOS viewers.

Re: [Freedos-devel] Retro framebuffer graphics project?

2024-07-20 Thread Jim Hall via Freedos-devel
On Sat, Jul 20, 2024 at 6:55 AM Felix Natter via Freedos-devel
 wrote:
>
> hello freedos-devel,
>
> I would like to develop with freedos like I developed with MS-DOS (and
> VESA/DJGPP/NASM with 1024x768x8bit) in the 90s. Hence the questions:
>
> - is VESA framebuffer even supported by modern GPUs (i.e Intel onboard
>   HD graphics) or emulated by freedos? If yes, what framebuffer
>   layout/resolution?
>
> - Do you recommend to use GCC (like with RHIDE in DJGPP) or shall I port
>   my code to OpenWatcom1/2 (I saw that nasm is supported)?
>


The graphics support will depend entirely on the hardware in your
machine. As Eric pointed out, more recent graphics cards tend to have
worse VGA compatibility, but I agree the standard modes should be fine
like 640x480 or 800x600. But your mileage may vary depending on your
hardware.

My 'real hardware' where I run FreeDOS are either the Pocket386 that I
bought recently, or my 12-year old laptop where I run Linux to do
presentations on the go. And the graphics are fine there. But except
for the Pocket386, I don't usually run FreeDOS on bare metal; I run
FreeDOS on a virtual machine (I use QEMU). I find using a virtual
machine is really convenient - I don't have the space in my home
office to keep spare hardware in the hopes I might oneday use it.

I use OpenWatcom and IA-16 GCC for my C programs, but I use OpenWatcom
when I do programming in graphics mode. For example, I used OpenWatcom
for my 'programming' videos on the YouTube channel, like this virtual
dot matrix printer in graphics mode:

https://www.youtube.com/watch?v=yj8R4UIqBrQ

..or this one to calculate pi by counting pixels in a circle:

https://www.youtube.com/watch?v=jHC1iLHtUP8

..or this graphics-mode program to program a retro 'Toy' CPU in
machine language:

https://www.youtube.com/watch?v=IptoyRCRYFU


I usually stick to the standard modes like 640x480, 800x600, and
1024x768, but this video shows other video resolutions in an
OpenWatcom program:

https://www.youtube.com/watch?v=0wf-KqsOfnE


*And the YouTube channel itself:

https://www.youtube.com/@freedosproject



Jim


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


Re: [Freedos-devel] development and advertising plan

2024-07-12 Thread Jim Hall via Freedos-devel
First, I'll say that this appears to be either a troll or spam.
Opening with "FreeDOS is dying" is a classic troll "opening." And
there's a note in there that seems to be a discussion with someone
else that was accidentally copied/pasted into the email, but shouldn't
have been:

> > I expect they will consider it unnecessary. I think so myself. There
> > will be other proposals later.
> >
> > ## Domain

And while I usually don't reply to trolls or spam, I'll reply briefly anyway:

At best, this is someone who doesn't understand what DOS is. And we
get these emails from time to time - I know that I get emails at my
personal address from people who have just discovered FreeDOS, and
maybe tried to install it, but they don't know what "DOS" is or how to
use it. And then they suggest some odd ideas, like "you should make
FreeDOS for a Samsung watch" or "you should port FreeDOS to an Amiga"
or something else. This person is suggesting turning FreeDOS into some
kind of server-oriented platform, like a FreeDOS VPN.

FreeDOS is an open source DOS-compatible operating system that you can
use to play classic DOS games, run legacy business software, or write
new DOS programs. That's the goal. We're an open source DOS.

It's clearly a troll. Don't feed the trolls.


On Fri, Jul 12, 2024 at 4:45 PM armored--- via Freedos-devel
 wrote:
> It's obvious that Freedos is dying. I can probably revive it if I take
> a course towards the servers.
>
> For example, you can save a lot of money if you deploy a VPN on Free
> DOS.  I'm sure that VPN is already possible there, but it needs to be
> advertised. Even in this small version, Free DOS is already useful. Free
> DOS should be server-oriented, no one will want to sit in the console
> anymore (and even if you compile horg it won't help there too much...)
>
> Linux is successful because of servers. but now Linux is very heavy
> compared to Free DOS and you can win on this. especially if you provide
> ready-made builds for example for email, matrix (python is slow and
> complex, I know the rest for Nix OS, or does not function, so we will
> skip) activity pab, for example Pleroma (better not Mostadon, complex
> and heavy). also activity pub, Lemmy...
>
> I am not a programmer but I can help. For example, in advertising. I
> have a lot of knowledge. I am also a bit of a webmaster. Yes, and I
> have PHP SQL hosting which is free, we pay only for the domain (and
> the hosting domain).
>
> > I expect they will consider it unnecessary. I think so myself. There
> > will be other proposals later.
> >
> > ## Domain
>
> It would be nice if with i2p and/or top so that a person could not
> pay for domains, and in general.
>
> And it would also be good to buy a short domain and make a free ddns
> for free dos users.
>
> then because of the freebies people would install servers on old devices
> (for many people electricity is free or very cheap).


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-06 Thread Jim Hall via Freedos-devel
On Sat, Jul 6, 2024 at 5:12 AM Bernd Böckmann via Freedos-devel
 wrote:
>
> Like Jerome I also would prefer to put the repository under the
> Gitlab FreeDOS group[1] or alternatively under the fdos[2] group at
> Github. Gitlab would be the more logical choice, I think. But Github
> would have the benefit that there are still more people with an account
> for it.

Well, it won't be under "FDOS" because that's not "The FreeDOS
Project." FDOS is Jeremy's project, I think. (I don't think I knew
Jeremy was using the FreeDOS fish on the "FDOS" GitHub - he probably
should use something else or it will confuse people to think that's an
official FreeDOS GitHub.)

I like the idea of putting the docs under the FreeDOS GitLab group at
. That's where we host a live copy of the
source code, so it makes sense to put the documentation there too. The
process is the same to download a zip archive of everything in a
repository/folder. For example, anyone can download the code to Choice
with this:
https://gitlab.com/FreeDOS/base/choice/-/archive/master/choice-master.zip

..so it's easy enough to automate grabbing a snapshot of the Markdown
docs as a zip file (GitLab also supports tar.gz, tar.bz2, and tar).

> I like Wolfs idea of automatically generating a "documentation site"
> from the Git repository. He mentioned hugo[3] as a static site
> generator. This seems to be a good fit. mdbook[4] would be a more
> documentation focussed software, but is not nearly as flexible as hugo.

It's actually pretty easy to create a "documentation site" without
using a static site generator like Hugo. Once you have the Markdown
files, it's just a matter of putting everything into a place that a
display system can find it. That's pretty easy for me to set up.

> From the beginning, we should put an emphasis on also generating proper
> (with a table of contents etc.) PDFs from the documentation.

I think we can do that automatically using pandoc, which we'd need to
do anyway to turn Markdown into HTML.

> Like already mentioned, having the documentation in markdown format
> would give us the opportunity to automate many things, like building an
> offline documentation from it. As Jim noted, we should establish some
> form of code style considering the constrains given by the different
> output formats and target system we would like to support. A few things
> / questions come into my mind:
>
> - Restrict to UTF-8 encoding to make conversion to different DOS
> codepages for translated documentation straightforward
>
> - Verbatim text like code snippets should be restricted to 78 characters
> a line, so that it fits without a line break on a DOS screen, or
> alternatively create a viewer for it that supports horizontal scrolling
> on the verbatim text while reflowing the "ordinary" text paragraphs.
>
> ? Technically, while I doubt anyone is using it at all, there is a 40
> column text mode. While probably not worth dealing with this it would
> not be a bad thing to design everything that this could be supported
> at some time.
>
> ? Maybe using things like tables should be considered a "do not",
> because it is questionable if these look good on a 80 (or even 40)
> column display when converted to a different format for offline viewing
> under DOS. It could be made to work if the tables get converted to
> verbatim text blocks and the horizontal scrolling thing gets implemented
> in a DOS viewer.
>
> ? We should think about how to generate some form of index for the
> documentation. This would be especially important for the DOS viewers.

+1 Yes to all of that! I think creating the "front page" index will
probably take a little coding so it's automated, but not hard.


Jim


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-05 Thread Jim Hall via Freedos-devel
On Fri, Jul 5, 2024 at 2:00 PM Wilhelm Spiegl  wrote:
>
> Could you offer a few spammed files for download so that the fd group can 
> check if the files can be fixed?
> How many files do we talk about?
>


From my other email, and the temporary page at
https://wiki.freedos.org/spammed/ with screenshots, I said it was
"hundreds and hundreds of new pages." But really it's thousands of
spam pages: see the screenshot from the Orphaned pages report, showing
500 pages at a time, sorted alphabetically, and over half of page 1 is
"pages that start with a number." Page 1 ends with "BBB," page 2 goes
to "Fiber," and page 3 goes to "Ideal." After 1,500 wiki entries,
we're only at "I" in the alphabet. So you can see that this is a
really long list of pages. And many hundreds of dummy users. But I
don't think they mangled any existing wiki pages, probably to stay
under the radar.

But there has to be a better way to manage documentation than using a
wiki. And I really liked Bernd's suggestion, see that discussion for
how that could work. I think copying/pasting an initial set of content
into Markdown wouldn't take too long.


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-05 Thread Jim Hall via Freedos-devel
>> On Fri, Jul 5, 2024 at 1:21 PM Wilhelm Spiegl via Freedos-devel wrote:
>>
>> > I wonder how someone was able to come in? Bad configured server / not yet 
>> > fixed linux bug or bad password?
>> > Have I been pawned? shows interesting results for passwords.
>> >

> Am 05.07.24, 20:32 schrieb Jim Hall via Freedos-devel 
> :
>
>> My impression from managing the wiki when it was on SourceForge, and
>> moving the wiki to wiki.freedos.org, is that Mediawiki was designed to
>> be "everything for everyone." So it has a lot of entry points into the
>> system, which means a pretty wide attack surface for a system everyone
>> on the Internet can talk to.
>>

On Fri, Jul 5, 2024 at 1:44 PM Wilhelm Spiegl  wrote:
>
> Nevertheless it is strange to have the second attack within a few
> months (mail). I just tested it, you do not come into mailing list if
> you use an unknown mail address.
>


The reason for moving the wiki from SourceForge to wiki.freedos.org
wasn't because the old wiki was spammed or hacked. SourceForge had
been making some updates to the web hosting service, and basically
broke how the wiki worked. I moved the wiki to wiki.freedos.org so we
could have more control over the website.


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-05 Thread Jim Hall via Freedos-devel
On Fri, Jul 5, 2024 at 1:21 PM Wilhelm Spiegl via Freedos-devel
 wrote:
>
> I wonder how someone was able to come in? Bad configured server / not yet 
> fixed linux bug or bad password?
> Have I been pawned? shows interesting results for passwords.
>

My impression from managing the wiki when it was on SourceForge, and
moving the wiki to wiki.freedos.org, is that Mediawiki was designed to
be "everything for everyone." So it has a lot of entry points into the
system, which means a pretty wide attack surface for a system everyone
on the Internet can talk to.


BTW, I also check https://haveibeenpwned.com/ every few months to
check for data issues, and you need to be thoughtful about what you
find there. For example, they show several "data breaches" for me that
weren't "account breaches." Like 'B2B USA Businesses' which aggregates
contacts lists for different employers in the US (they sell access to
that list to people like recruiters and marketers). My email was in
there because they collected it (and that data was leaked during a
data breach) but not because I had an account there. And then you have
things like the Linux Mint breach, and I set up an account there to
ask exactly one question on their board - but I didn't enter any
personal data, just email address and "Jim Hall" (any other fields
would have been blank or made-up data) so the other stuff in that
breach doesn't apply to me. A reminder to be careful about what data
you share online.


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-05 Thread Jim Hall via Freedos-devel
On Fri, Jul 5, 2024 at 5:47 AM Eric Auer via Freedos-devel
 wrote:
>
>
> Hi Jim,
>
> sounds like somebody copied their whole spam wiki on top of our wiki?
>
> That means it barely got damaged, we only need a way to mass-delete
> their content, recognizable by originating from edits in a very small
> time window from many different accounts which all are very young.
>
> We need some wiki expert to suggest a tool to automate cleaning :-)


While I *think* the spammers "only" copied a bunch of their content
into other pages in our wiki, and *probably* didn't damage our pages
(such as to add links from "our" pages to "their" pages) we can't be
*sure* without looking at everything. That's a lot of pages.

And see also this note from my email. Maintaining a Mediawiki requires
a lot of work, and you have to patch to the latest version as soon as
it's available, and do that *immediately*, or we risk having this
happen again.

> Maintaining a Mediawiki requires a lot of work. You basically have to
> jump onto a new version as soon as they release a new one, because
> they often fix security issues (probably like the one that caused our
> problem). We were on the 1.41.x version, and the Mediawiki website*
> says "The 1.42.0 stable release came out on 27 June 2024." That was
> shortly after our wiki was spammed. I'm not excited about a future
> where I need to drop all my other work immediately, just to apply a
> new Mediawiki version to the wiki website.
> *see https://www.mediawiki.org/wiki/MediaWiki_1.42


I think there's a better way to manage documentation. I really like
Bernd's suggestion. See my reply to him about how to extend it - I
think that will cover all our use cases, and provide flexibility down
the road.


Jim


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


Re: [Freedos-devel] FreeDOS wiki is temporary offline

2024-07-04 Thread Jim Hall via Freedos-devel
Hi everyone. I am following up on my email from a week ago, about the wiki.

To summarize: I discovered that our wiki had been spammed, but
fortunately I found it only a day after it was spammed.

I discovered the spamming on June 27, and immediately shut down the
wiki and emailed the freedos-user email list about it:

On Thu, Jun 27, 2024 at 10:37 AM Jim Hall  wrote:
>
> I just realized that someone started spamming our wiki yesterday. So
> I've taken that down until I can clean it out and apply a patch.
>
> Great. Just when a bunch of people would be likely to visit the wiki
> to learn more about us.

Unfortunately, the only backup was right before I started copying over
most of the content, and they spammed the site before the next backup
- and I had already made a ton of updates to the wiki in the weeks
leading up to the 30th anniversary on June 29. So rolling back to a
previous backup basically wipes out the wiki.

I can't attach screenshots on the email list, so I've created a
temporary page at https://wiki.freedos.org/spammed/ that has
screenshots and a version of this email.

Whoever spammed the wiki, I don't think they mangled any existing wiki
pages, probably to stay under the radar. That means our content is
still there, so we can copy/paste it out of the wiki.

I found out about the spammed wiki because I was searching for the
answer to a question someone asked me about the history of FreeDOS,
and I thought we had a "history" page. I deleted these first 3 pages
before I realized the extent of the spamming.

But they created hundreds and hundreds of new pages, most (all?) of
them not linked to from any other pages on the wiki (orphaned). They
also created many hundreds of dummy users.

The web page I linked to has a screenshot from the Orphaned pages
report, showing 500 pages at a time, sorted alphabetically, and over
half of page 1 is "pages that start with a number." Page 1 ends with
"BBB," page 2 goes to "Fiber," and page 3 goes to "Ideal." So you can
see that this is a really long list of pages.

Doing a spot check on these pages and looking at the creation date for
each, I'm pretty sure the hack happened a day or two before I found it
on June 27.


So, where do we go from here?

I could rebuild the wiki. However, that would require basically
rebuilding from scratch.

Maintaining a Mediawiki requires a lot of work. You basically have to
jump onto a new version as soon as they release a new one, because
they often fix security issues (probably like the one that caused our
problem). We were on the 1.41.x version, and the Mediawiki website*
says "The 1.42.0 stable release came out on 27 June 2024." That was
shortly after our wiki was spammed. I'm not excited about a future
where I need to drop all my other work immediately, just to apply a
new Mediawiki version to the wiki website.
*see https://www.mediawiki.org/wiki/MediaWiki_1.42

Even before this issue, I was thinking about how to integrate some of
our "non-wiki" content into the wiki website. For example, we have
some ebooks at https://www.freedos.org/books/ and content from the
press kit that I wanted to migrate into the wiki in some way - but
these aren't really "wiki" topics, they are longer form. And I wanted
to copy the articles I've written about FreeDOS into the wiki - but
again, these don't fit as "wiki" topics.

Years ago, we created a "FreeDOS Documentation Project" website that
hosted all of our "how-to" articles, "technotes," and other long form
topics. We retired that when SourceForge set up a shared wiki for all
projects hosted at SourceForge, and we thought it would be easier to
maintain a wiki. And for a time, that worked well, until most folks
stopped contributing to the wiki. We had a few who updated the wiki,
but like two or three people, including me. And of course: later,
SourceForge stopped managing a shared wiki, and that's when we set up
our own wiki (which lived on freedos.sourceforge.net for a long time
before SF did an update that broke the wiki and I had to move the wiki
to the new server).

Looking at how people look for "help" today, I don't think a wiki is
the right answer in 2024. We've seen people email freedos-user and
freedos-devel to ask for help, and I've seen similar requests on
Facebook and on YouTube sometimes. What people are looking for is a
"walkthrough" or a "tutorial" - long form "how-to" content that shows
people how to do something, like how to install FreeDOS, or how to use
the FreeDOS command line. Instead of building a new wiki, I think this
is the right opportunity to set up a FreeDOS "documentation" website,
filled with these kinds of "how-to" and "what-is" content.

Writing about FreeDOS is also my strength, so I can build up some core
documentation quickly by adapting (or just copying/pasting) content
from articles I've already written, such as the articles I wrote for
Opensource.com and Both.org and elsewhere. The website would be an
excellent place for anyone who wants to write a 

Re: [Freedos-devel] New libfp-0.0!

2024-07-01 Thread Jim Hall via Freedos-devel
I've mirrored your libfp to the FreeDOS Files Archive at Ibiblio. It's here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libfp/0.0


I've been having sporadic problems today when trying to access Ibiblio
via the web. I'm not sure if that's my end ("The connection has timed
out") or their end. For example, I was able to download the T2407 test
release this morning, but when I went back to Ibiblio later in the day
to download something else, I couldn't access the website. Has anyone
else had issues connecting to Ibiblio today?

If that URL works for others, let me know and I'll post a news item
about libfp on the FreeDOS website.

Jim



On Mon, Jul 1, 2024 at 8:53 PM Jim Hall  wrote:
>
> Thanks! I got your email with the attachment, but we're watching a movie. 
> I'll try to mirror this to Ibiblio tonight - otherwise, in the morning.
>
> I'll reply here when it's up, and post a news item on the website at the same 
> time.
>
>
> On Mon, Jul 1, 2024, 7:16 PM Gregory Pietsch via Freedos-devel 
>  wrote:
>>
>> I first mentioned libfp a few years ago, and I thought I could enhance its 
>> development by releasing what I have so far.
>>
>> The library libfp is the complement to libmpi. It handles floating-point 
>> math and complex math as part of the C runtime library. Version 0.0 is 
>> incomplete, and I hope that people out there can help in its development. 
>> Parts of it were borrowed from libm and libmpi as it was supposed to not be 
>> dependent on libm and on the same level as libmpi.
>>
>> Gregory
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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


Re: [Freedos-devel] New libfp-0.0!

2024-07-01 Thread Jim Hall via Freedos-devel
Thanks! I got your email with the attachment, but we're watching a movie.
I'll try to mirror this to Ibiblio tonight - otherwise, in the morning.

I'll reply here when it's up, and post a news item on the website at the
same time.


On Mon, Jul 1, 2024, 7:16 PM Gregory Pietsch via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> I first mentioned libfp a few years ago, and I thought I could enhance its
> development by releasing what I have so far.
>
> The library libfp is the complement to libmpi. It handles floating-point
> math and complex math as part of the C runtime library. Version 0.0 is
> incomplete, and I hope that people out there can help in its development.
> Parts of it were borrowed from libm and libmpi as it was supposed to not be
> dependent on libm and on the same level as libmpi.
>
> Gregory
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


[Freedos-devel] Next FreeDOS virtual get-together is Sunday, Aug 4

2024-06-29 Thread Jim Hall via Freedos-devel
Thanks to everyone who joined us for a very special virtual
get-together this morning to celebrate our 30th anniversary! This
meeting was social time, and I think about a dozen people joined over
the two hours (we went longer than planned) although we probably had
about 8 or 9 people at any one time.

We'll see you again next month for a technical discussion—great for
live debugging or going over technical issues. The next one is set for
Sunday, August 4 at 11am US/Central. Use your favorite timezone
converter to find your local time.

See you then!


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


[Freedos-devel] FreeDOS virtual get-together [happening soon!]

2024-06-29 Thread Jim Hall via Freedos-devel
Hi everyone!

This is a reminder that the FreeDOS virtual get-together is in about
half an hour from now. We usually do these on Sundays, but today is
the 30th anniversary day, so we had decided to do it today instead.

Here's the connection info:

FreeDOS virtual get-together (social)
Saturday, June 29 · 11:00am – 12:00pm
Time zone: America/Chicago

Google Meet joining info
Video call link: https://meet.google.com/kst-xbvs-vya

Or dial: ‪(US) +1 978-378-5658‬ PIN: ‪655 995 894‬#
More phone numbers: https://tel.meet/kst-xbvs-vya?pin=3315499233403


See you there!


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


[Freedos-devel] Reminder: FreeDOS virtual get-together (30th anniversary)

2024-06-25 Thread Jim Hall via Freedos-devel
Hi everyone!

This is a reminder that the FreeDOS virtual get-together will be a day
early this month, so we can do it on the 29th.

Join us for a very special FreeDOS virtual get-together as we
celebrate the 30th anniversary of FreeDOS. We will meet using Google
Meet at 11am US/Central on SATURDAY, June 29. I'll share connection
details when the meeting starts.


Jim


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


Re: [Freedos-devel] New libm-0.8!

2024-06-19 Thread Jim Hall via Freedos-devel
On Tue, Jun 18, 2024 at 7:40 PM Gregory Pietsch via Freedos-devel
 wrote:
>
> Unto an unsuspecting world filled with innumerate people, I have submitted 
> unto Jim Hall the latest version of libm, libm-0.8. I fixed a couple of 
> things in csqrt and tanh. If anyone is brave enough to test my math, go 
> ahead, I could use the feedback!
>


Hi everyone!

I've mirrored this on the FreeDOS Files Archive at Ibiblio:
https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/0.8/


I'll also post a news item on the website about it.


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


[Freedos-devel] Anyone here speak French?

2024-06-19 Thread Jim Hall via Freedos-devel
Underscore is interested in interviewing a developer about FreeDOS turning
30 years, but they have asked for someone who speaks French.

https://underscore.radio.fm/

Anyone interested? Reply here and I can put you in touch with someone.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

2024-06-17 Thread Jim Hall via Freedos-devel
Jerome Shidel asked:
>
> Does that machine have a NIC and did you get it working under FreeDOS?
>


It has a ribbon cable to connect ISA but I don't have an Ethernet card to
try, so I don't have networking running. It's standalone, just like my 386
from my undergraduate days. :⁠-⁠)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

2024-06-17 Thread Jim Hall via Freedos-devel
Also:

I wrote a "how-to" article about FreeDOS on the Pocket386 for
Both.org, but I also copied/pasted this into a wiki article on the
FreeDOS wiki:

https://wiki.freedos.org/wiki/Pocket386

Basically, it's these steps:

1. transfer the CF card to my Linux box
2. boot the install LiveCD in QEMU, using '-hda /dev/sda' to use the CF card
3. exit to DOS, do these steps manually:
4. FDISK (then reboot)
5. FORMAT C:
6. SYS C: /FORCE:CHS
7. SETUP ADV
8. do the rest of the install in the installer, but skip the step to
transfer system files
9. transfer the CF card back to the Pocket386


If you want to skip all of that: this afternoon, I reinstalled FreeDOS
T2406 on this laptop, using a "Full installation including
applications and games" (with source code). I've shared an image of my
CF card here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/pocket386/

That's not really a "distribution" per se, but I couldn't think of a
better place to store a 328MB file. Might move it later.


Now that I've reinstalled the Pocket386, my next step is to test every
application and game from FreeDOS T2406. If you're curious how an app
performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
I'll share notes in a follow-up thread.

So far, I can report that FED is a bit slow to start up (just when I
thought it had hung, it came up) but runs fine after that.

Jim


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


[Freedos-devel] FreeDOS on Pocket386 (follow-up)

2024-06-17 Thread Jim Hall via Freedos-devel
You might be interested in this video I recorded yesterday about
running FreeDOS on the Pocket386:
https://www.youtube.com/watch?v=2h96UseZs6Q

It shows several apps and games on the Pocket386, mostly running some
shareware games, plus Word for DOS, and As Easy As spreadsheet. If
you're curious about its performance, here's a quick rundown of some
games and apps: [not all of these are shown in the video]

Games:

- Dark Forces - runs a bit slow (but no SB16)
- Doom - runs fine at small size
- Duke Nukum - runs fine, uses PC speaker
- Ford simulator - runs great!
- Jill of the Jungle - runs great, full music and sound, sometimes has
glitchy video in VGA but no problems in EGA
- Pinball - runs great!
- Rise of the Triad - runs fine at small sizes, uses AdLib for sound
- Simple Senet - runs great!
- Shadow Warrior - doesn't run (requires 9MB, this has 8MB)
- Tomb Raider - crashes during setup (not a surprise, this is a 1996
game and requires way more memory and CPU than this laptop has - the
game should have done a memory check)
- Wolfenstein 3D - runs great!
- Biomenace - runs fine
- Commander Keen - Keen1-5 all work great!

Apps:

- Ability Office - runs great!
- As Easy As - runs great!
- Borland Turbo C++ compiler - editor runs fine, I've used the
compiler to write a few test programs, no issues there
- Word - runs great!


Jim


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


Re: [Freedos-devel] Four in a Row

2024-06-06 Thread Jim Hall via Freedos-devel
On Thu, Jun 6, 2024 at 5:32 PM Wilhelm Spiegl  wrote:
>
> I will test it on vbox tomorrow and, if necessary, inform the programmer 
> today, it is 12pm 24 here.
>

I'll also test it on the Pocket386, but it's evening here now so I
don't have time to do it right away. I'll try it in the morning.


> Btw, did you check fdtui? Does it really make sense to keep it?
>

After I do the next video for the YouTube channel (this weekend) I
plan to reinstall the Pocket386 micro laptop with a "Full" version of
FreeDOS T2406 test release. Then I can test out *every* app that's
included in the FreeDOS distribution (including fdtui). My goal is to
test what works and what doesn't - everything should be fine, but I
expect to find some programs run "slow" because the Pocket386 is a
386-SX at 40MHz.


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


Re: [Freedos-devel] Four in a Row

2024-06-06 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
> > The on-screen help says 'N' for a new game, 'Q' to quit. Using 'N' to
> > start a new game is fine. Playing the game works fine. But when I
> > press 'Q' to quit, it hangs and never brings me back to the DOS
> > prompt.


Eric Auer wrote:
> It does work in dosemu2, although I find it odd that it says to be
> SDL based, while the binary is a tiny COM file. The soure shows it
> used int 33 to: reset the mouse driver (function 0), show or hide
> the mouse (functions 1 and 2) and poll mouse status (function 3) if
> compiled for DOS, DPMI style. There do not seem to be hooked ints,
> but there are several different atexit calls activated. I hope you
> can register multiple atexits without causing problems? Will they
> be called in a sensible order when leaving the game?
>
> Maybe you just have to configure your mouse driver differently?
>
> You could also try pre-loading DPMIONE or CWSDPMI and check if
> that improves stability of this apparently DPMI-oriented game.
>


I've just tried running it with different configs:

1. without ctmouse loaded (this is my default)

2. with ctmouse loaded

3. with cwsdpmi loaded, no mouse

4. with cwsdpmi loaded, with mouse


I get the same behavior in each: the game plays fine, until I use 'q'
to quit. Then it just hangs.

*I'll add that it didn't occur to me that you could use a mouse to
play this game. The columns on the board are numbered, so it made
sense to just type the number of the column where I wanted to drop a
piece.


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


Re: [Freedos-devel] Four in a Row (was: one more proposal for upload via fdnpkg)

2024-06-06 Thread Jim Hall via Freedos-devel
Jerome Shidel wrote:
[..]
> But, we probably did not evaluate it for inclusion for an unknown
> reason. That was several years ago and I do not recall why. Possibly,
> it just got forgotten. It was released after a while after FreeDOS
> 1.2 but long before 1.3.
>
> Looking at it now:
>
> The author releases it as “GNU AGPLv3”
> Sources are marked as GNU GPLv2+, GNU GPLv3+, CC0, GNU AGPLv3+
>
>
> I don’t see a reason that would require it to be excluded.
> So, I recommend including it with the release starting with T2407.
>

I downloaded it and looked it over. The sources are fine, no problem
there. Then I played it on FreeDOS under QEMU.

The on-screen help says 'N' for a new game, 'Q' to quit. Using 'N' to
start a new game is fine. Playing the game works fine. But when I
press 'Q' to quit, it hangs and never brings me back to the DOS
prompt.

It's not even at the DOS prompt but "hidden" (no echo) in some way -
it's completely locked up. I can't type REBOOT to reboot the virtual
machine. I have to close the window or restart using the QEMU menu.
Does this behave differently for others?

I am using the latest version pointed to by Wilhelm:

https://akfoerster.de/dl/software/dos/fdos/ROW4.ZIP


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


Re: [Freedos-devel] Proposal for new package in T2405

2024-06-05 Thread Jim Hall via Freedos-devel
On Wed, May 29, 2024 at 3:02 PM Jerome Shidel via Freedos-devel
 wrote:
>
> Hi Jim,
>
> I created an i16env package.
>
> Since it is very small and you did not specify a license anywhere,
> I assumed you intend it to be “Public Domain”.
>
> So, that’s how I listed it in the metadata. If that is incorrect,
> let me know.
>
> I added the package to be included on the BonusCD along with the other
> IA-16 packages.
>
> So, it will be on the next interim test build.


Oops, I missed this in my inbox, so I'm replying late.

Yes, "public domain" is fine for me. It's just a few lines long - any
license will be much longer than that. :-)


And: I installed IA-16 GCC when I installed T2406 - thanks for
including I16ENV. Works great!


Jim


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


Re: [Freedos-devel] Four in a Row (was: one more proposal for upload via fdnpkg)

2024-06-05 Thread Jim Hall via Freedos-devel
Wilhelm Spiegl wrote:
>
> Hi, its once again me.
> At the fd gitlab account there is a game called row4, (four in a row) see:
> https://gitlab.com/FreeDOS/games/row4
> This version is out of date.
> There is an update at the programmers site, see:
>
> https://akfoerster.de/dl/software/dos/fdos/ROW4.ZIP
> The game runs in english.
> Would it be possible to enable an upload via fdnpkg  or to add it in FDT2407?

Jerome Shidel wrote:
> Thanks for point out the package was out of date. I updated the the
> version in the FreeDOS GitLab Archive and uploaded it to the package
> repository on Ibiblio.
>
> However as I am sure you have noticed, the game is not currently
> provided on any of the release media.
>
> I’m not sure why and do not recall why that is the case. The game is
> licensed as GNU Affero General Public License, version 3 or later. Since
> games seem to be one the areas users want and we include nearly all the
> games we have whose license permits it, perhaps we should reconsider
> excluding it from the release. We generally seem to set the bar fairly
> low when it comes to games.


I'm not sure why it wasn't included either. I don't see a note about
row4 on the wiki: (I don't see any text about "row" on that page - I
get one match for "browse")

https://wiki.freedos.org/wiki/Releases/1.3/Packages#Games

Was row4 part of the release candidates for 1.3? Those would have been
the programs I was evaluating for licenses.

At a guess, did the licenses not match up? The above wiki page lists a
few games that I asked not to include because (for example: Beyond The
Titanic) the game said "public domain" in some places and "GNU GPL" in
others - and "shareware" on the loading screen. All the license info
needs to match up.

But you're right that we have been very flexible with games. We
decided we can swap out games since they are not "core" like other
programs are, but they are fun to play - but some games are popular
for a while then people tire of them.


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-05 Thread Jim Hall via Freedos-devel
Jeremy wrote:
> I'm thinking of adding a multi-sector boot code for fat32 to support
> both LBA and CHS, but possibly keeping the single sector boot code
> support as well.   It would be a build option along with other
> advanced features so as to not bloat basic sys included with kernel
> archive.  I'd like to see if I can still keep lba logic in 1st sector
> so if 2nd sector corrupted could still boot in happy path (lba no
> errors).  A 3rd sector would not be used hopefully.   I will see
> about working on this, but not until next week.
>
> I don't think anything needs to be done with installer.  But we
> can document potential issues and fixes when moving drives from one
> computer to another, ie boot sector may need updating and there may
> be other issues if chs used and different geometry expected.
>


FYI to anyone who is curious:
I'm planning to do a video for the YouTube channel with this device in
the next few days. I figure it's good to show FreeDOS running on real
hardware, especially a "retrocomputing" laptop like this. After that
(probably this weekend) I'll start over and install a "Full" (all
applications and games) version of FreeDOS, using the T2406 test
release.

My goal is to run *every* app and program from the distribution on the
Pocket386. I expect everything will be fine, but some apps may be slow
(and that might be expected for "developer" apps like compilers or
something). I'll report back on freedos-devel with anything odd that
comes up.

If you want me to test something specific, please reply here and I'll
add that to the list of things to do.


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-03 Thread Jim Hall via Freedos-devel
Eric Auer wrote:
> >
> > Are you sure that this is not just what the PARTITION TABLE says?
> > Is there a way to ask FDISK whether it detects BIOS LBA support?


Bernd Böckmann wrote:
> Eric is right, I had a look at the relevant lines of the FDISK
> source. This is only an indicator that FDISK generally makes use of LBA,
> not if LBA for the currently selected disk is actually supported. Two
> different things.
>
> Sorry for that. Had better looked this up by myself before suggesting
> it.
>
> I now altered FDISK so that it also shows if LBA is actually used. It
> is printed after the disk size in the main menu if started with /XO.
>
> Jim, you may download the new executable from
[..]

Thanks! I grabbed that and ran the new FDISK with /xo on the CF card,
running in two ways:

1. Booted in QEMU, using the CF card (see command line in previous
emails). The output shows:

> Current fixed disk drive: 1   1775 Mbytes (LBA)

2. Put the CF card in the Pocket386 and booted from that. The output shows:

> Current fixed disk drive: 1   1775 Mbytes (CHS)


To compare: I also ran the new FDISK with /xo in the QEMU environment
where I normally run FreeDOS T2406 on my Linux box. That has a 500MB
"C:" drive (qcow2 disk image). The output there shows:

> Current fixed disk drive: 1   499 Mbytes (LBA)


So that says that QEMU supports LBA but the BIOS on the Pocket386 does
not. And that is probably why installing to the CF card from QEMU
worked fine .. and booting the CF card in QEMU worked fine .. but when
I just did plain "SYS C:" from the QEMU environment, FreeDOS didn't
boot on the Pocket386 (because it was trying to use LBA, which is not
supported on the Pocket386). When I instead used "SYS C: /FORCE:CHS"
from the QEMU environment, FreeDOS booted fine on the Pocket386
(because it was using CHS).

If you can think of a good engineering workaround for that, please do
it. But I'm thinking this is a "user" issue. I had SYS'd the drive
from a different "computer" (QEMU) then moved the CF card to a
different computer to boot it there. And then we run into BIOS not
supporting LBA on the second system.


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-02 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
> >> 5. SYS C: /FORCE:CHS
> >>
> >>
> >> And that boots without problem on the Pocket386!
> >>
> >>
> >> Also: you asked about FDISK /XO output. It reports "W95B INT LBA
> >> FAT32" in the upper left corner. This is running FDISK 1.3.15.

E. C. Masloch wrote:
> To Jim: Are you sure you ran FDISK /XO on the Pocket386 system? If FDISK
> says it detects LBA there but the LBA loader from FreeDOS doesn't work
> that'd be quite the bug.

Definitely I'm seeing "W95B INT LBA FAT32" when running FDISK /xo on
the Pocket386. I can't send photos to the email list, but I'll send an
off-list email to you and Bernd with a photo.


[..]
> If it really turns out that FDISK /XO detected LBA support *on the
> Pocket386* but the LBA loader fails, I could cough up some debugging
> hints as to how to install bootable lDebug on the system then debug the
> failing loader. For instance:
>
> 1. Rename kernel.sys to fdkernel.sys (exact name doesn't matter)
> 2. Copy ldebug.com to working drive (using CHS loader) as kernel.sys
> 3. Boot lDebug
> 4. Boot FreeDOS using "BOOT PROTOCOL FREEDOS fdkernel.sys" then "Q"
> 5. Write loader to file: "SYS C: /BOOTONLY /FORCE:LBA BOOTSECT.DOS"
> 6. Reboot into lDebug
> 7. Try "BOOT PROTOCOL CHAIN" and then trace the loader
>
> You could install the FAT32+FSIBOOT loader for lDebug as well but when
> you already have a working boot loader then this would just be the
> possible cause of more headaches. Not impossible, but not worth it
> probably. As I have oft repeated lDebug can be loaded as a number of
> kernel formats, most recently including the FreeDOS and the original
> Enhanced DR-DOS (v7.01.07) kernel load formats.
>
> I will advertise the lDOS FAT32 loader more in another subsequent email.
>

I'm happy to do any debugging you need on this device. I bought this
so I could experiment with it - so I don't mind reinstalling the
system, running debugging tools, or doing whatever we need to get more
info about it.


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-02 Thread Jim Hall via Freedos-devel
Bernd Böckmann wrote:
> >
[..]
> > You might try doing a "SYS X: /FORCE:CHS" under QEMU and then testing
> > again with your 386 to see if the FAT32 CHS loader works. This is not
> > documented via SYS /? but should work according to the source. You
> > can find out if LBA is supported by starting FDISK via FDISK /XO on
> > the 386. In the top line there will be an indication "LBA" if FDISK
> > (and probably the other FreeDOS parts) make use of it.

That appears to fix it! Here's what I did:

1. connect CF card to Linux (/dev/sda)

2. run QEMU:

sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


3. run FDISK .. delete partitions .. reboot .. create new partition ..
1 single partition .. reboot

4. FORMAT C:

5. SYS C: /FORCE:CHS


And that boots without problem on the Pocket386!

I then continued:


6. connect CF back into Linux (/dev/sda)

7. run QEMU

8. SETUP ADV .. don't transfer system files .. do "plain DOS" install


And now I have a working FreeDOS T2406 installation on the Pocket386!


Also: you asked about FDISK /XO output. It reports "W95B INT LBA
FAT32" in the upper left corner. This is running FDISK 1.3.15.

FDISK /INFO shows this:

> Current fixed disk drive: 1   3632832 sectors, geometry 901/064/63
>
> Partition   Status   Mbytes   System   Usage   Start CHSEnd CHS
>  C: 1  11  A   1775   FAT-32   100%0/001/01  901/063/63


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-02 Thread Jim Hall via Freedos-devel
On Sun, Jun 2, 2024 at 6:31 AM Bernd Böckmann  wrote:
>
> Hi Jim,
>
> > Am 02.06.2024 um 01:45 schrieb Jim Hall via Freedos-devel 
> > :
> >
>
> > (I created a single partition on the 1.9G drive, formatted and
> > installed "plain DOS" to that, everything works fine)
> >
>
> How did you create the partition? Did you run FDISK or did you re-use
> an existing 1.9G partition shipped with the original image?

To be clear, by "everything works fine," I meant "everything works
fine in QEMU. This step was before writing the image back to the CF
card.

I used FDISK from the FreeDOS T2406 install media. Specifically I
booted T2406 in QEMU .. deleted the partitions .. rebooted T2406 ..
created new partition .. rebooted T2406 .. did the rest of the install
steps as usual.

> > It stops at "Loading FreeDOS" and just hangs there
>
>
> This comes from the (FAT32 LBA?) volume boot code installed by the SYS
> command. There can be several reasons why it fails, the most probable
> being the partition layout. But it may also be that the 386 does not
> support LBA, and SYS puts the LBA-only loader onto the disk while
> running under QEMU. This might make the VBR code stuck in an infinite
> loop, according to the source. Or, there is some incompatibility with
> the BIOS...

It's an AMIBIOS (version 1.16) from 1996. With what I have seen so
far, I agree that the issue is likely to be limitations in the BIOS.
But I'll keep experimenting with different configs to work it out.


> You might try doing a "SYS X: /FORCE:CHS" under QEMU and then testing
> again with your 386 to see if the FAT32 CHS loader works. This is not
> documented via SYS /? but should work according to the source. You
> can find out if LBA is supported by starting FDISK via FDISK /XO on
> the 386. In the top line there will be an indication "LBA" if FDISK
> (and probably the other FreeDOS parts) make use of it.

I'll run that FDISK command in an upcoming test.


> If the 10MB partition can be booted from, we have to take into account
> that this is a FAT16 partition, and accordingly the FAT12/16 volume
> boot code is installed. This supports both LBA and non-LBA access.
>
> Jim, can you upload the non-working image and the working 10MB test
> image, so I can have a look at the relevant data structures (MBR etc.)?
>
> https://nextcloud.iww.rwth-aachen.de/index.php/s/BRXqZDGasw74NN9

I'm uploading two files to you:

10mb.cf is the "install" I did yesterday with a single 10MB partition.
It's not really an "install," though. That's where I just did FDISK
then FORMAT /S ... but at least it booted to a prompt. :-)

newinstall.cf is a test I just did, repeating one of my tests from
yesterday. It also ends up getting stuck at "Loading FreeDOS" and just
hangs.


For both of these images, I installed it using direct access to the CF card:

$ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


And then made the images using dd:

$ sudo dd if=/dev/sda of=newinstall.cf
3637872+0 records in
3637872+0 records out
1862590464 bytes (1.9 GB, 1.7 GiB) copied, 97.3253 s, 19.1 MB/s


> What BIOS is this machine using?

AMIBIOS (version 1.16) from 1996


> As Jerome said, the FreeDOS installer will re-use an existing partition
> layout. So what you can try (not 100% sure you already did that): start
> with an empty 1.9G image and install FreeDOS onto it via QEMU. The
> installer will create and format a partition. Then, try to boot it
> with your 386.


That's what I've done in every case: boot the installer .. run FDISK
to delete partitions .. reboot .. run FDISK to create partition(s) ..
reboot .. do the rest of the install. I didn't want to "inherit"
whatever partition scheme they provided on the system already. I
figured it was good to show everything could be done with FreeDOS
tools. :-)


> Thinking of this LBA, non-LBA thing we might investigate if it is
> possible to merge the LBA and non-LBA FAT32 VBR code into one. But that
> is for another topic. We also might replace the loaders with some other
> one. If I remember correctly ECMs lDOS loaders have the capability...

I think if we're seeing devices like the Book8088 and Pocket386,
that's probably a good suggestion. But as you said, that's probably
best for another thread.



Jim


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-01 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
> My CF card reader arrived, so I tried installing FreeDOS on the CF
> card. I've had partial success; I can install, but I can't boot. I
> need help.
>
[..]
> I've also tried running QEMU directly against the CF card, in case
> something weird happened when I was trying to write the CF card. So I
> did this:
>
> $ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
> T2406LIVE.iso -boot order=d
>
>
> And that FreeDOS install works fine too. Same as step 3. But it hangs
> at "Loading FreeDOS" when I boot the Pocket386 with the CF card.


I just did another test, one I should have tried first:


1. Ran QEMU directly against the CF card (same QEMU command line as above)

2. Did *not* run the installer

3. Manually ran FDISK, delete all partitions

4. Reboot .. run FDISK, create a single 10MB partition

5. Reboot .. FORMAT C: /s


And then I put the CF card back into the Pocket386, and it boots!
There's nothing there (I didn't install, just made a tiny partition
bootable) but at least it works!!

So I'll do more work with this tomorrow and put FreeDOS on it, even if
I have to do everything without the installer.


(I don't think the installer is specifically at fault, probably something else.)


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-06-01 Thread Jim Hall via Freedos-devel
> Jim Hall wrote:
> [..]
> > > It arrived Friday. I powered it on to make sure it works, and it does.
> > > They've pre-installed some pirated copy of Win95 on there, but I'll
> > > reinstall the whole thing with FreeDOS anyway. :-)
> > >
> > > The Pocket386 only boots from the internal C: drive (a CF card). I
> > > thought I still had a CF card reader (can't find it) so I've ordered a
> > > new one. My plan is to image the CF card from Linux and make a copy,
> > > then use QEMU with that drive image to install FreeDOS, then write the
> > > image to the CF so I can boot the Pocket386 with it.


My CF card reader arrived, so I tried installing FreeDOS on the CF
card. I've had partial success; I can install, but I can't boot. I
need help.


What I've done:

1. Backup the CF card from Linux:

$ sudo dd if=/dev/sda of=diskimage.cf

2. Make a copy of the CF card image:

$ cp diskimage.cf freedos.cf

3. Install FreeDOS using the CF copy:

$ qemu-system-i386 -enable-kvm -m 32 -hda freedos.cf -cdrom
T2406LIVE.iso -boot order=d

(I created a single partition on the 1.9G drive, formatted and
installed "plain DOS" to that, everything works fine)

4. Write the image back to the CF card:

$ sudo dd if=freedos.sf of=/dev/sda

(I get the same amount written as was read in step 1)

5. Boot the Pocket386 from the CF card

It stops at "Loading FreeDOS" and just hangs there



As a debugging step, I used 'dd' again to write the original image
back to the CF card. Put the CF card back into the Pocket386, and that
boots Win95 as usual:

$ sudo dd if=diskimage.cf of=/dev/sda



I've also tried running QEMU directly against the CF card, in case
something weird happened when I was trying to write the CF card. So I
did this:

$ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


And that FreeDOS install works fine too. Same as step 3. But it hangs
at "Loading FreeDOS" when I boot the Pocket386 with the CF card.



And to confirm: I installed T2406 on QEMU, on my usual virtual disk
setup that I have, and that installed fine. Doesn't hang at boot.


Does anyone have any suggestions?


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


Re: [Freedos-devel] Back at it with DOG

2024-05-30 Thread Jim Hall via Freedos-devel
On Wed, May 29, 2024 at 9:53 PM Wolf Bergenheim via Freedos-devel
 wrote:
>
[..]
> Now a question:
> What are your dev setups like? I'm on a linux host computer and I've
> been using both DOSBox and QEMU to build and test in. I find though
> that it's a bit of a chore, since DOSBox crashes randomly (like when
> compiling), or QEMU segfaults when I mount my dog source directory
> as a virtual FAT drive. So now I'm looking at setting up Dosemu2
> (I remember using doemu ~20 years ago).
>
> What do your dev environments look like? How do you make an efficient
> edit-build-test cycle? Has anyone tried using watcom as a crosscompiler?


I run Linux on my desktop, and I boot FreeDOS inside that using QEMU.
Here's my command line:

qemu-system-i386 -enable-kvm -m 32 -audiodev pa,id=snd -machine
pcspk-audiodev=snd -device sb16,audiodev=snd -device
adlib,audiodev=snd -hda freedos.qcow2 -hdb mystuff.qcow2 -cdrom
T2405LIVE.iso -boot menu=on


But that has some extra stuff in there just to make the PC speaker
work. If you don't care about the PC speaker, but still want SB16 and
Adlib, you can just do this:

qemu-system-i386 -enable-kvm -m 32 -device sb16 -device adlib -hda
freedos.qcow2 -hdb mystuff.qcow2 -cdrom T2405LIVE.iso -boot menu=on


And if you don't care about sound at all, then it's a very simple command line:

qemu-system-i386 -enable-kvm -m 32 -hda freedos.qcow2 -hdb
mystuff.qcow2 -cdrom T2405LIVE.iso -boot menu=on


I use '-boot menu=on' because I sometimes need to boot the LiveCD for
testing, and the boot menu makes that easy. I can also use the same
command line (it's a script) to install the next FreeDOS monthly test
release and just use the menu to select the LiveCD to install from.


My "C:" drive is freedos.qcow2 and my "D:" drive is mystuff.qcow2.
Keeping these separate makes it really easy to reinstall FreeDOS with
the monthly test releases. I keep all my stuff on "D:" and just
wipe/reinstall the "C:" drive. I don't keep any of my data on "C:".

I used to map a virtual drive to a folder on Linux - but like you
found, I sometimes had problems with that (not all the time, just
sometimes) so I stopped doing that. When I need to get access to my
virtual drive, I use guestmount from the libguestfs package to "mount"
the virtual disk from Linux:

$ mkdir mystuff
$ guestmount -a mystuff.qcow2 -m /dev/sda1 mystuff
...
$ guestunmount mystuff


I write my code directly in FreeDOS. I often use OpenWatcom, but I
also like IA-16 GCC. I use FED as my programming editor.


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


Re: [Freedos-devel] FreeDOS on Pocket386

2024-05-29 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
[..]
> > It arrived Friday. I powered it on to make sure it works, and it does.
> > They've pre-installed some pirated copy of Win95 on there, but I'll
> > reinstall the whole thing with FreeDOS anyway. :-)
> >
> > The Pocket386 only boots from the internal C: drive (a CF card). I
> > thought I still had a CF card reader (can't find it) so I've ordered a
> > new one. My plan is to image the CF card from Linux and make a copy,
> > then use QEMU with that drive image to install FreeDOS, then write the
> > image to the CF so I can boot the Pocket386 with it.
> >
> > I also ordered a PS/2 keyboard, because the built-in keyboard is too
> > tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).


Jerome Shidel wrote:
> Having fun with your 386?
>
> Does it have sound and does it work under DOS?
>
> Where are you Benchmarks??


I haven't tinkered with it too much yet, because that micro keyboard
makes my wrists ache just by *looking* at it. The keys are so tiny
(letters are 13mm x 11mm .. arrows and punctuation keys are 10mm x
11mm) that I often hit the key next to the letter I'm trying to type.
I'm looking forward to using a full-size PS/2 keyboard. :-)

Win95 says:

Cirrus Logic CL-GD 5420 r1 Rev 0 video card (512k video memory)
8 MB RAM
Ad Lib Gold compatible OPL3 sound card

The CPU is 386SX-40.


Since I can't install DOS applications yet (that's why I ordered a CF
card reader) I can't say if the Ad Lib sound card actually works with
DOS games. I'll share an update when the CF card reader arrives and I
wipe this with FreeDOS and put some games and other software on it.
:-)


Jim


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


Re: [Freedos-devel] Proposal for new package in T2405

2024-05-28 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
>
>> This didn't get any discussion a month ago. Since it didn't appear in
>> T2405, I wanted to raise it again for T2406. Can we add this to T2406?
>> Adding a DJGPP.ENV file is all you need to compile programs with IA-16
>> GCC without installing the full DJGPP environment.
>>
>> To make it easier to add to the distribution, I've created a 427-byte
>> zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
>> the root dir, then both get installed to \devel\i16gcc. I've copied
>> the zip file to the FreeDOS Files Archive at Ibiblio, here:
>>
>> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
>> I16ENV.ZIP
>>
>> The I16ENV.TXT file is just a brief Readme about it.

Jerome Shidel wrote:
>
> Wouldn’t it make more sense to just add those files to the 
> https://gitlab.com/FreeDOS/devel/i16gcc package?
>
> But, I don’t use it. So, maybe that would be an issue or confusing to users.


We can add it to that package, if you think that's better. But I also
wrote this in my original email:

[..]
:: But because we aren't updating any original IA-16 GCC packages, it
:: keeps things clean at the expense of a little extra "overhead" for the
:: package. But if you're installing a C compiler, you likely can spare
:: the tiny extra space.

..so I thought it might be nice not to "pollute" TK Chia's IA-16 GCC
release with these two files. And we already have several other
packages that are part of IA-16 GCC, adding this one didn't seem like
a lot of overhead.

But ultimately it doesn't matter to me if it gets merged into the
https://gitlab.com/FreeDOS/devel/i16gcc package or stays separate.


Jim


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


Re: [Freedos-devel] Free FDISK 1.3.15

2024-05-28 Thread Jim Hall via Freedos-devel
On Tue, May 28, 2024 at 6:04 PM Bernd Böckmann via Freedos-devel
 wrote:
>
> Free FDISK 1.3.15 is released.
>
> https://github.com/FDOS/fdisk/releases/tag/v1.3.15
>
> Fixes:
[..]


Thanks! I've posted a news item and mirrored this to the FreeDOS Files
Archive at Ibiblio.


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


[Freedos-devel] FreeDOS on Pocket386

2024-05-28 Thread Jim Hall via Freedos-devel
*I'm resending (with a few edits/updates) because this message failed
over the weekend due to the SF list server outage


You may remember the Book8088 micro-laptop and Hand386 handheld from
last year. I always said I'd buy one if they were the other way
around: a handheld 8088 or a '386 laptop.

Well, then they started selling the Pocket386 - and I bought one.

It arrived Friday. I powered it on to make sure it works, and it does.
They've pre-installed some pirated copy of Win95 on there, but I'll
reinstall the whole thing with FreeDOS anyway. :-)

The Pocket386 only boots from the internal C: drive (a CF card). I
thought I still had a CF card reader (can't find it) so I've ordered a
new one. My plan is to image the CF card from Linux and make a copy,
then use QEMU with that drive image to install FreeDOS, then write the
image to the CF so I can boot the Pocket386 with it.

I also ordered a PS/2 keyboard, because the built-in keyboard is too
tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).


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


Re: [Freedos-devel] Proposal for new package in T2405

2024-05-28 Thread Jim Hall via Freedos-devel
This didn't get any discussion a month ago. Since it didn't appear in
T2405, I wanted to raise it again for T2406. Can we add this to T2406?
Adding a DJGPP.ENV file is all you need to compile programs with IA-16
GCC without installing the full DJGPP environment.

To make it easier to add to the distribution, I've created a 427-byte
zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
the root dir, then both get installed to \devel\i16gcc. I've copied
the zip file to the FreeDOS Files Archive at Ibiblio, here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
I16ENV.ZIP

The I16ENV.TXT file is just a brief Readme about it.


On Wed, Apr 10, 2024 at 10:52 AM Jim Hall  wrote:
>
> Based on my other email about getting IA-16 GCC to work on T2404
> without installing DJGPP, I propose adding a new package in T2405
> called I16ENV that just has two files in it:
>
> /devel/i16gnu/djgpp.env
> /devel/i16gnu/setenv.bat
>
> The DJGPP.ENV file contains just:
>
> DJDIR=
>
> And the SETENV.BAT file sets the PATH and points the DJGPP environment
> variable to the DJGPP.ENV file, like this:
>
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
>
> Since it gets installed in the IA-16 GCC directory, it shouldn't get
> confused with the DJGPP stuff. If the DJGPP env file is called
> DJGPP.ENV, it will make more sense when people find references to
> "DJGPP.ENV" in other documentation. And because the package will be
> named similarly to the other IA-16 GCC packages, users will be more
> likely to install it when they install IA-16 GCC. But because we
> aren't updating any original IA-16 GCC packages, it keeps things clean
> at the expense of a little extra "overhead" for the package. But if
> you're installing a C compiler, you likely can spare the tiny extra
> space.
>
> This will be a good way for others to start testing compiling programs
> using IA-16 GCC in a working default configuration on a fresh install,
> starting with the next test release.
>
> This works on my T2404 installation. Here is a copy/paste of my
> FreeDOS session after a fresh reboot (using unmodified FDAUTO.BAT):
>
> C:\DEVEL>dir /b
> I16GNU
> WATCOMC
>
> C:\DEVEL>cd i16gnu
>
> C:\DEVEL\I16GNU>dir /b
> BIN
> IA16-ELF
> LIB
> LIBEXEC
> SHARE
> DJGPP.ENV
> SETENV.BAT
>
> C:\DEVEL\I16GNU>type setenv.bat
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
> C:\DEVEL\I16GNU>type DJGPP.ENV
> DJDIR=
>
> C:\DEVEL\I16GNU>setenv.bat
>
> .. now I'll switch to the D: drive to compile a program ..
>
> D:\SRC>dir /b hello.*
> HELLO.C
>
> D:\SRC>type hello.c
> #include 
> int main()
> {
> puts("Hello world");
> return 0;
> }
>
> D:\SRC>i16gcc -Wall -o hello.exe hello.c
>
> D:\SRC>dir /b hello.*
> HELLO.C
> HELLO.EXE
>
> D:\SRC>hello.exe
> Hello world


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


[Freedos-devel] Virtual dot matrix printer

2024-05-28 Thread Jim Hall via Freedos-devel
I created a FreeDOS program that simulates printing on a 9-pin impact
("dot matrix") printer.

I made this for a few reasons: 1. I am writing an article about dot
matrix printing, and didn't have a good way to demonstrate it; and 2.
It was something fun to do in an afternoon.

A few notes:

- This is a simplified version of a dot matrix printer. Characters are
5x8. The 9th "pin" is reserved for underline only. Although printer
control codes aren't implemented yet, so underline doesn't work
anyway.

- I didn't create a character set as "firmware" for the virtual
printer. So currently, printable characters are rendered as the bit
pattern for the character's ascii code (except 32, which is rendered
as a space).


I've shared it on my GitHub, with screenshots of the output:
https://github.com/freedosproject/vp


Compile with OpenWatcom. Uses the MIT license.


Jim



*I grabbed the "freedosproject" username some time ago so no one else
could take it and use it for something else. I use this account to
share source code for programming projects that I do on the YouTube
channel. The FreeDOS source archive is at GitLab:
https://gitlab.com/FreeDOS (there's also a link from my GitHub
profile)


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


Re: [Freedos-devel] Proposal for new package in T2405

2024-05-28 Thread Jim Hall via Freedos-devel
*Resending as I think my other email this weekend was lost due to the
SF email list servers issue:



This didn't get any discussion a month ago. Since it didn't appear in
T2405, I wanted to raise it again for T2406. Can we add this to T2406?
Adding a DJGPP.ENV file is all you need to compile programs with IA-16
GCC without installing the full DJGPP environment.

To make it easier to add to the distribution, I've created a 427-byte
zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
the root dir, then both get installed to \devel\i16gcc. I've copied
the zip file to the FreeDOS Files Archive at Ibiblio, here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
I16ENV.ZIP

The I16ENV.TXT file is just a brief Readme about it.



On Wed, Apr 10, 2024 at 10:52 AM Jim Hall  wrote:
>
> Based on my other email about getting IA-16 GCC to work on T2404
> without installing DJGPP, I propose adding a new package in T2405
> called I16ENV that just has two files in it:
>
> /devel/i16gnu/djgpp.env
> /devel/i16gnu/setenv.bat
>
> The DJGPP.ENV file contains just:
>
> DJDIR=
>
> And the SETENV.BAT file sets the PATH and points the DJGPP environment
> variable to the DJGPP.ENV file, like this:
>
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
>
> Since it gets installed in the IA-16 GCC directory, it shouldn't get
> confused with the DJGPP stuff. If the DJGPP env file is called
> DJGPP.ENV, it will make more sense when people find references to
> "DJGPP.ENV" in other documentation. And because the package will be
> named similarly to the other IA-16 GCC packages, users will be more
> likely to install it when they install IA-16 GCC. But because we
> aren't updating any original IA-16 GCC packages, it keeps things clean
> at the expense of a little extra "overhead" for the package. But if
> you're installing a C compiler, you likely can spare the tiny extra
> space.
>
> This will be a good way for others to start testing compiling programs
> using IA-16 GCC in a working default configuration on a fresh install,
> starting with the next test release.
>
> This works on my T2404 installation. Here is a copy/paste of my
> FreeDOS session after a fresh reboot (using unmodified FDAUTO.BAT):
>
> C:\DEVEL>dir /b
> I16GNU
> WATCOMC
>
> C:\DEVEL>cd i16gnu
>
> C:\DEVEL\I16GNU>dir /b
> BIN
> IA16-ELF
> LIB
> LIBEXEC
> SHARE
> DJGPP.ENV
> SETENV.BAT
>
> C:\DEVEL\I16GNU>type setenv.bat
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
> C:\DEVEL\I16GNU>type DJGPP.ENV
> DJDIR=
>
> C:\DEVEL\I16GNU>setenv.bat
>
> .. now I'll switch to the D: drive to compile a program ..
>
> D:\SRC>dir /b hello.*
> HELLO.C
>
> D:\SRC>type hello.c
> #include 
> int main()
> {
> puts("Hello world");
> return 0;
> }
>
> D:\SRC>i16gcc -Wall -o hello.exe hello.c
>
> D:\SRC>dir /b hello.*
> HELLO.C
> HELLO.EXE
>
> D:\SRC>hello.exe
> Hello world


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


Re: [Freedos-devel] Email test

2024-05-28 Thread Jim Hall via Freedos-devel
Thanks to Wilhelm and Andy for letting me know the email list services
are working again. It looks like the email list servers on SourceForge
were not processing email for at least a few days, possibly all
weekend (Monday was a holiday in the US). I opened a support ticket
about it, but they haven't updated the ticket yet - but at least I
know things are working again. Thanks.


*You can ignore this thread now


On Tue, May 28, 2024 at 11:01 AM Andy Stamp  wrote:
>
> Seen May 28 12:00 EDT.
>
> On Tue, May 28, 2024 at 11:33 AM 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


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


[Freedos-devel] Email test

2024-05-28 Thread Jim Hall via Freedos-devel
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
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] zoo

2024-05-23 Thread Jim Hall via Freedos-devel
[..]
> > But I got the feedback from Jerome  to ask the FD mailing list first as it 
> > is not possible to remove it if only one person
> > asks for removing. So I did this.
>
> So Jerome is now suddenly the official rule maker for FreeDOS? I don't 
> remember dicussing this.
>

No. I think it was "Wilhelm probably asked Jerome a question off-list,
and Jerome asked Wilhelm ['feedback'] to put that question on the
email list" .. because we shouldn't be having off-list conversations.
(Keeping all conversations on the email list is a good thing.)


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


Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?

2024-05-22 Thread Jim Hall via Freedos-devel
There's the ebook and video series I did a few years ago. It's meant to
teach the basics of programming in C, using openwatcom on FreeDOS.

https://www.freedos.org/books/cprogramming/


There also used to be a print book you could but at low cost on Lulu, but I
took it off sale a while back. If you would like to order it, let me know
and I can reactivate the listing so you can buy it.




On Wed, May 22, 2024, 8:26 PM Richard Stoltenberg via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Greetings:
> I got my program to compile under watcom 1.9 but it has errors.  Not
> looking for help directly, but good programming documentation.  Does anyone
> have any good free/paid programming books with examples?  found: The ANSI C
> Programming Language
> by Brian W. Kernighan, Dennis M. Ritchie (not cheap)
> and Ansi C Programming Concept Kindle Edition
> by Sivarasan R (Author) cheaper
>
> is Ansi-C the right year compiler and language? wasn't clear from a
> view of your youtube videos and website, I enjoy.  Thanks.
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] zoo

2024-05-22 Thread Jim Hall 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.

On Wed, May 22, 2024 at 12:24 PM Steve Nickolas via Freedos-devel
 wrote:
>
> 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...


My experience was ZOO was somewhat popular for sharing files for a
while. I found a lot of ZOO files on ftp sites at the time, and shared
on Usenet using ASCII encoding.

I saw LHA for a while, and that was much better than ZOO. For what I
saw, LHA (almost?) completely replaced ZOO.

But once ZIP came along (with Pkzip) everything moved to ZIP almost
overnight. It was like everyone stopped using LHA and moved to ZIP.
And once Info-Zip happened, you started to see ZIP files on Unix
systems too.


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


Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

2024-05-16 Thread Jim Hall via Freedos-devel
Jim wrote:
[..]
> > FYI: I've fixed the source files on my end and mirrored that version
> > to Ibiblio. It's at:
> >
> > https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.24/
> >
> >
> > I've also uploaded a compiled version of EDLIN16.EXE (compiled using OW.BAT)

Gregory wrote:
>
> Okay. Fixed. -- Gregory
>


Awesome, thanks! I've re-mirrored this edlin 2.24 to Ibiblio.

I'll also make a news item on the website for it!


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


Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

2024-05-16 Thread Jim Hall via Freedos-devel
On Thu, May 16, 2024 at 1:36 PM Gregory Pietsch via Freedos-devel
 wrote:
>
> FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall
> sent me some edits that moved the copyright to the help screen and
> changed "Abort edit" to "Really quit". It's available on SourceForge
> and Jim should mirror it very soon now!
>


Thanks! Unfortunately, this still advertises itself as 2.23. Can you
fix it on SF and I can re-mirror that?

D:\SRC\EDLIN224>find "2.23" config*.*
 CONFIG-H.BC
#define PACKAGE_STRING "edlin 2.23"
#define PACKAGE_VERSION "2.23"
#define VERSION "2.23"
 CONFIG-H.OW
#define PACKAGE_STRING "edlin 2.23"
#define PACKAGE_VERSION "2.23"
#define VERSION "2.23"
 CONFIG.GUE
 CONFIG_H.IN
 CONFIG.SUB
 CONFIGUR
 CONFIGUR.AC


Might want to update ow.bat too:

D:\SRC\EDLIN224>find "2.23" *.bat
 OW.BAT
REM builds FreeDOS's edlin 2.23 (by Gregory Pietsch:  gpiet...@comcast.net)
if not exist edlin-2.23\nul if exist edlin-2.23.zip unzip edlin-2.23.zip
if not exist edlin-2.23\nul goto end
cd edlin-2.23


I should have sent complete changes that updated the version to 2.24
for you, too. Sorry about that.


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


Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

2024-05-16 Thread Jim Hall via Freedos-devel
On Thu, May 16, 2024 at 1:49 PM Jim Hall  wrote:
>
> On Thu, May 16, 2024 at 1:36 PM Gregory Pietsch via Freedos-devel
>  wrote:
> >
> > FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall
> > sent me some edits that moved the copyright to the help screen and
> > changed "Abort edit" to "Really quit". It's available on SourceForge
> > and Jim should mirror it very soon now!
> >
>
>
> Thanks! Unfortunately, this still advertises itself as 2.23. Can you
> fix it on SF and I can re-mirror that?
>[..]

FYI: I've fixed the source files on my end and mirrored that version
to Ibiblio. It's at:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.24/


I've also uploaded a compiled version of EDLIN16.EXE (compiled using OW.BAT)


Jim


___
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

2024-05-10 Thread Jim Hall via Freedos-devel
On Fri, May 10, 2024 at 11:01 AM Steve Nickolas via Freedos-devel
 wrote:
>[..]
> 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.)
>

I don't know if you're the youngest on the list, but definitely not
the youngest person to use FreeDOS.

We get a fair number of new FreeDOS users who are at university - so
that's probably 18 years old? I get a lot of these emails, probably
because my email is everywhere (trademark statement, etc). I suspect
these new users discover FreeDOS as part of a computer science course
or an IT/MIS course. That would make sense, because DOS is a simple
operating system that makes it very easy to walk through "how
computers work" : boot the kernel, which reads CONFIG.SYS, start the
command shell, which reads AUTOEXEC.BAT, and you're ready to enter
commands.

That's why when I updated the website last year, I made such an effort
to do several rounds of design .. usability test .. update ..
usability test .. update. The goal was to answer most questions via
the website, without emailing me. My inbox gets less of these
questions now, so I guess it's working. :-)


___
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

2024-05-10 Thread Jim Hall via Freedos-devel
On Fri, May 10, 2024 at 8:46 AM 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.


I'm usually a very nice guy, but I have to call this out:

If there was ever a prime example of how *not* to ask for help, this
email thread was it.


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


Re: [Freedos-devel] Where is the source code?

2024-05-08 Thread Jim Hall via Freedos-devel
On Wed, May 8, 2024 at 10:28 AM Bernd Böckmann via Freedos-devel
 wrote:
>
>
> > I like that idea. I think a good place to add these would be in the
> > "Technical information" section on that page, maybe as another row of
> > "info boxes" before (or after? not sure) the row that has RBIL, VGA
> > programming, and the Graphics Programming book.
>
> I would put it below Technical Information as another row.


Sounds good! I'll probably use this as a comment right before it:
"Looking to get started in DOS programming? These YouTube videos show
you how to write your first programs:"


> > What are some good YouTube channels about DOS programming that I
> > should point to?
>
> I like the following playlist. He uses Turbo C, PowerBasic, NASM. While he 
> does it on DosBox, the skills are transferable. Be aware: heavy german accent 
> :)
>
> https://www.youtube.com/playlist?list=PLGJnX2KGgaw2L7Uv5NThlL48G9y4rJx1X


Thanks for that! I'll be sure to include that one.

Anyone else have other recommendations?


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


Re: [Freedos-devel] Where is the source code?

2024-05-08 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
> > To make this more clear on the website, I've changed the info box
> > title from "Create new programs" to "For developers" - and changed the
> > action link in that info box from "Create programs" to "Developers".
> > I've also changed the "sitenav" link in the website

Tom Ehlert wrote:
> Wow. having "sitenav" at the bottom of the page in 5 point font is really 
> inventive.

It is not 5-point font. The website doesn't set a font size except for
headings and the dates on the news items, so your browser will use
whatever your default font size is set at. On Firefox and Google
Chrome (you said you use Firefox) the website footer renders using the
same font size as the main body text.


> How about having ONE place to navigate the site; maybe near the
> " Read the wiki / Ask a question / Report a bug " location?


I hate to be the one to tell you, but "how Tom navigates a website" is
not the same as "how many others navigate a website." Today, many more
people expect to find a "mini 'site navigation' menu" in the footer.
It's just what they've come to expect; if they can't find a link in
the main body of the page, they look in the footer for a "mini 'site
navigation' menu". We saw this feedback in the usability test reports,
too. So when I updated the website, I made sure to include a "mini
'site navigation' menu" (a list of links to major areas of the
website) in the footer. The menu looks like this:

> Home Wiki Questions Bugs
> About Games Apps Devel


> now show me a way to locate the command.com sources.
>
> or the sources for the DVD driver.


You're a smart guy and you've been part of FreeDOS for many years. I
know you can find it. On the "Developer" page (from an earlier email,
this is now called "For developers" on the main page, and links to
) you'll find a page that has
information and links. AT THE TOP of the page, it says:
"FreeDOS is a collection of programs and utilities, so not everything
is in one place. The FreeDOS kernel is currently maintained by Jeremy
Davis and the source code is on his GitHub. Find other FreeDOS source
code in our GitLab:"

..and then you have links for:

> Kernel sources
> FreeDOS sources
> How to contribute

Click on the "FreeDOS sources" link, and you'll end up at the FreeDOS
source code archive at . You can find the
source code there, including command.com ("FreeCOM") and everything
else. The kernel sources are in there too, but you probably already
know that.


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


Re: [Freedos-devel] Where is the source code?

2024-05-08 Thread Jim Hall via Freedos-devel
On Wed, May 8, 2024 at 9:32 AM Bernd Böckmann via Freedos-devel
 wrote:
>
>
> > To make this more clear on the website, I've changed the info box
> > title from "Create new programs" to "For developers" - and changed the
> > action link in that info box from "Create programs" to "Developers".
> > I've also changed the "sitenav" link in the website footer from
> > "Create" to "Devel". And I changed the web page title on the
> > https://www.freedos.org/about/devel/ page from "Create new programs"
> > to "For developers" to match the info box title from the main page.
>
> I think this is an improvement!
>
> In a time where for most young programmers YouTube is their primary
> source of information it is perhaps a good idea to place a few YouTube
> channels regarding DOS programming more prominently on the developer
> section, including Jims?

I like that idea. I think a good place to add these would be in the
"Technical information" section on that page, maybe as another row of
"info boxes" before (or after? not sure) the row that has RBIL, VGA
programming, and the Graphics Programming book.

What are some good YouTube channels about DOS programming that I
should point to?


___
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

2024-05-08 Thread Jim Hall via Freedos-devel
*First: it is not good "netiquette" to start a new thread when you are
following up from a previous post. You should have written this as a
reply to your first email.

On Wed, May 8, 2024 at 4:50 AM Green Fog via Freedos-devel
 wrote:
>
> I can see the potential of Freedos if these 2 conditions are met:


Your subject line says you still cannot find the source code. Why did
you not click on the link that was suggested to you in the reply? In
my reply last night, I told you exactly where to find the source code.
I also said you can install the source code when you install FreeDOS.

You didn't read the answer to your question, and now you are requiring
"conditions" for FreeDOS. I think you are trolling, so this is my last
reply to you.


> 1, ease of use. Absolutely both for users and developers. Or else who
> is going to use it? or develop more fun and useful applications to
> it. So that means better documentation, easier access to not only the
> source code but also the known-hows on everything. I am able to find
> some source code from github, which only consists of 3.7MB. I am not
> sure how that translates into a 400MB ISO. I can't find any developer
> section. Are we in the matrix?


The "Developer" page that I pointed to in my last reply has a link
called "FreeDOS sources" that points to the FreeDOS source code
archive at GitLab  which is where you'll
find everything. The "Developer" page also has a link called "Kernel
sources" that points to Jeremy's kernel (he's the current maintainer)
at GitHub .

But maybe you found my personal project on GitHub
 that is called 'freedosproject.' I
originally had a different GitHUb username, but I changed to
'freedosproject' so no one else would try to "claim" that username and
confuse things. My personal project has this description:

"Some of the sample programs I write for the FreeDOS channel on
YouTube. For the FreeDOS source code archive instead, visit
https://gitlab.com/freedos;


> 2, Better documentation. The site has a wiki section that is not part
> of the site, and is very inadequate. The official site absolutely needs
> to provide more information on many aspects including the full source
> code if it's available.


When you clicked on the "Read the wiki" link on the FreeDOS website,
did you *read* the page that came up before you ended up on the wiki
website? The page stays up for 15 seconds, and says this:

"We are currently moving the wiki to a new website. Note that we
haven't finished moving everything over, so some links are "red"
because those pages don't exist yet. They'll be there soon."

That page also has a big button you can click to go right to the wiki
at 


Jim


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


Re: [Freedos-devel] Where is the source code?

2024-05-08 Thread Jim Hall via Freedos-devel
On Wed, May 8, 2024 at 3:23 AM tom ehlert via Freedos-devel
 wrote:
>
>
> > On Tue, May 7, 2024, 8:46 PM Green Fog via Freedos-devel <
> > freedos-devel@lists.sourceforge.net> wrote:
>
> >> I neither can find the source code in www.freedos.org or sourceforge.net.
> >> Is this an open source project or not? I highly suggest that the source
> >> code download link to be included in your main page.
> >>
>
>
> > It's on the website, under the "developer" section.
>
> in my version of firefox, there is no "developer" section on www.freedos.org
>
>
> > In the info box where it says:
>
> *>>>Create new programs*
> *>>>FreeDOS includes lots of compilers, assemblers, and other programming
> > tools so you can create your own DOS programs. You can also modify FreeDOS
> > itself, because we include the source code under an open source license.*
> *>>>*
> *>>>Create programs*
>
>
> > ..click on the link, and you'll find a page with more information and links
> > to the source code.
>


And yet you quoted back to me the text from the "info box" that has
the link about where to find the "developer" section?


To make this more clear on the website, I've changed the info box
title from "Create new programs" to "For developers" - and changed the
action link in that info box from "Create programs" to "Developers".
I've also changed the "sitenav" link in the website footer from
"Create" to "Devel". And I changed the web page title on the
https://www.freedos.org/about/devel/ page from "Create new programs"
to "For developers" to match the info box title from the main page.


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


Re: [Freedos-devel] Connection info for the virtual get-together

2024-05-07 Thread Jim Hall via Freedos-devel
[...]
> Not a typo. :-)
>
> It just happens that the 30th anniversary is a Saturday. (June 20, 1994 -
> 2024.)
>
> Now you're trying to confuse me, aren't you... 
>



Wow, of all the places to have a typo, it's in an email where I claimed no
typo. 


That should have been:
June 2*9*, 1994-2024
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] Where is the source code?

2024-05-07 Thread Jim Hall via Freedos-devel
On Tue, May 7, 2024, 10:20 PM Jim Hall  wrote:

>
>
> On Tue, May 7, 2024, 8:46 PM Green Fog via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>
>> I neither can find the source code in www.freedos.org or sourceforge.net.
>> Is this an open source project or not? I highly suggest that the source
>> code download link to be included in your main page.
>>
>
>
> It's on the website, under the "developer" section.
> [..]
>


I'll add that you can automatically install the source code when you
install FreeDOS. It is one of the installation options, very easy to find.

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


Re: [Freedos-devel] Where is the source code?

2024-05-07 Thread Jim Hall via Freedos-devel
On Tue, May 7, 2024, 8:46 PM Green Fog via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> I neither can find the source code in www.freedos.org or sourceforge.net.
> Is this an open source project or not? I highly suggest that the source
> code download link to be included in your main page.
>


It's on the website, under the "developer" section.

In the info box where it says:

*>>Create new programs*
*>>FreeDOS includes lots of compilers, assemblers, and other programming
tools so you can create your own DOS programs. You can also modify FreeDOS
itself, because we include the source code under an open source license.*
*>>*
*>>Create programs*


..click on the link, and you'll find a page with more information and links
to the source code.


I put this here because usability testing showed that people expected to
find FreeDOS source code in a place where developers would find other info
about *developing programs on FreeDOS*.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] Connection info for the virtual get-together

2024-05-07 Thread Jim Hall via Freedos-devel
On Tue, May 7, 2024, 9:23 PM Ralf Quint via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> On 5/5/2024 10:15 AM, Jim Hall via Freedos-devel wrote:
> [..]
> > We talked about doing the next virtual get-together on Saturday, June
> > 29 (11am-noon, US/Central). That's the FreeDOS 30th anniversary, so it
> > seems like a great opportunity for a virtual get-together! We
> > alternate topics, and today was "technical" - so that conveniently
> > means June 29 will be "social." :-)
>

I just checked my note that I quickly put in an online calendar the
> other day and wanted to add that to my paper/wall calendar, when I
> noticed that June 29th is a Saturday, not the usual Sunday.
> Don't know if this is just a typo or a more serious missed-take... 
>


Not a typo. :-)

It just happens that the 30th anniversary is a Saturday. (June 20, 1994 -
2024.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] Connection info for the virtual get-together

2024-05-05 Thread Jim Hall via Freedos-devel
Thanks to everyone who joined the virtual get-together today! We had
11 people on the call, and we did some virtual debugging, demo'd some
programs, and talked about other technical topics.


We talked about doing the next virtual get-together on Saturday, June
29 (11am-noon, US/Central). That's the FreeDOS 30th anniversary, so it
seems like a great opportunity for a virtual get-together! We
alternate topics, and today was "technical" - so that conveniently
means June 29 will be "social." :-)


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


[Freedos-devel] Connection info for the virtual get-together

2024-05-05 Thread Jim Hall via Freedos-devel
Hi everyone!

Here's how to connect to the virtual get-together, in 20 minutes from now.

FYI that we need to keep today's meeting to an hour. We usually go over,
but I'm not able to today.


FreeDOS virtual get-together (technical)
Sunday, May 5  •  11:00 AM – 12:00 PM
Google Meet joining info
Video call link: https://meet.google.com/nzf-gjbv-mqp



Or dial: +1 570-671-0066 PIN: 595 262 465#
More phone numbers: https://tel.meet/nzf-gjbv-mqp?pin=436657902
___
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

2024-05-03 Thread Jim Hall via Freedos-devel
On Fri, May 3, 2024, 11:19 PM Steve Nickolas via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> On Fri, 3 May 2024, Jim Hall via Freedos-devel wrote:
>
> [...]
>
> > 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.
>


Yes. I wrote an article about it when Microsoft released the earlier MS-DOS
under the same license:

https://opensource.com/article/18/10/microsoft-open-source-old-versions-ms-dos

>
___
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

2024-05-03 Thread Jim Hall via Freedos-devel
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.

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.

More info here:
https://www.gnu.org/licenses/license-list.en.html#Expat
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] FreeDOS Runtime

2024-05-02 Thread Jim Hall via Freedos-devel
Good "netiquette" is to only discuss one topic per email thread, so I
started a new thread for Runtime:

On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
 wrote:
[..]
> *Runtime*
>
> Jim's version is a small C program, 120 lines, using catgets
> for messages which can be translated in different languages.
> The binary is a 22kB EXE (31kB without UPX). There were text
> files with EN, RU, DE, HU and LV translations, I believe?
>
> My version is a small ASM program, made with NASM. It has
> a main file, circa 450 lines, and a language include file,
> circa 150 lines, which at the moment contains EN, DE, NL,
> PT, ES, FR, TR, IT, PL and RU messages :-) To add languages,
> you have to build a new binary. Not very hard, but harder
> than just editing a text file which can be used by CATGETS.
> The binary is a 2kB COM (3kB without UPX).
>
> Note that texts in all 10 language are INCLUDED in the 2kB
> COM file of my tiny version. No separate NLS files there.
>
> As a task left as an exercise for the user, one could port
> the C version to Tom's small KITTEN alternative to CATGETS.
>
> My preferred option would be to add HU and LV translations
> to my small RUNTIME and use that instead of the big one ;-)
>


I wrote the Runtime program, so I guess I'll speak to that.

This is a very old program. I don't remember why I wrote it, but I'm
sure I was doing some debugging on a program and was trying to
fine-tune the performance, and needed a way to test how long it took
to run after making improvements. There are lots of programs out there
to track the run-time of a program on DOS, and I probably gave a quick
look around - but decided it would be just as easy to write my own for
what I needed to do. It was just a quick program that I probably wrote
in ten minutes.

And I probably released it in case it was useful to someone else. I
don't think I intended it to become part of the distribution, but it
did.

I just looked at the zip file for Runtime 1.0. It's a very simple
program, just sets a timer, runs a program, then reports how long the
program ran.


That's the long version to say: I don't have a particularly strong
opinion to keep the old Runtime in the distribution. We can swap it
out.

I looked at your Runtime, and the messages are very simple:


1. seconds [as in, 'this ran in 4 seconds]

2. passed [as in, '4 seconds have passed']

3. a 1-line "about" message

4. a 1-line "usage" message

5. a 1-line "information" message

6. a "COMSPEC not found" error message


So it's just 6 messages, which seems right. It's not a very complicated program.


I'm in favor to swap out the old Runtime with this Runtime. No issues
here. I think it would be great to have those 6 messages translated
into the missing HU and LV translations, but I don't think we need to
"wait" for those messages to get translated.

What do others think? You can "+1" if you just want to agree to swap
out my old Runtime with Eric's newer Runtime.


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


Re: [Freedos-devel] FreeDOS Terminal

2024-05-02 Thread Jim Hall via Freedos-devel
Good "netiquette" is to only discuss one topic per email thread, so I
started a new thread for Terminal:


On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
 wrote:
> Willi has asked Jerome and me whether RUNTIME and TERMINAL
> in the auersoft.eu versions were real updates or just tests.
>
> Jerome asked him to ask on the LIST, so I answer HERE ;-)
[..]

Yes, and please avoid sending off-list emails. We have the email list
so we can talk about things in the open.


> *Terminal*
>
> Regarding TERMINAL, the distro contains version 3.2a 2015-05-16.
> The files in the ZIP have timestamps between 2001 and 2005 for
> source code and 2021-2022 for translations.
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/terminal.html
>
> The version mentioned by Willi, terminal-2007jun20, contains
> 2007 changes to terminal.asm, term-irq.asm and term-data.asm,
> with the following minimalist changelog:
>
> "update in V3.3 6/2007: added a forgotten in al,dx term-irq.asm:217"
>
> The change in terminal.asm are just adding the above as a comment.
> The change in term-irq.asm is just adding that "in al,dx".
> The change in term-data.asm is just changing version and date in
> the msg_hello string. Note that the sources have LONG FILE NAMES
> which somehow got lost in the download available on Ibiblio!
>
> The version on ibiblio comes with more metadata in APPINFO: The
> LSM file and small TERMINAL.xyz files in different languages xyz,
> for example the French APPINFO/TERMINAL.FR file says:
>
> Begin3
> Language:FR, 850
> Title:   terminal
> Description: Un petit terminal vt100/ansi pour tous les PC
> Keywords:terminal, rs-232, vt100
> End
>
> I guess it would be nice if the ibiblio version got updated with
> my 2007 version, but preserving the nice added ibiblio metadata.
> Please take care to preserve source LFN and timestamps, though.


I see the 2007 Terminal in the Ibiblio archive, so it looks like we
made a copy at some point. It is here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/terminal/


The 2007 version has these file dates/times:

$ ls -l
total 224
-rw-r- 1 freedos users  6014 Nov 16  2001 README
-rw-r--r-- 1 freedos users 46662 Nov 18  2001 terminal-2001nov18.zip
-rw-r--r-- 1 freedos users 48049 Nov  6  2002 terminal-2002nov06.zip
-rw-r--r-- 1 freedos users 44538 Apr 23  2005 terminal-2005apr23.zip
-rw-r--r-- 1 freedos users 44520 Jun 20  2007 terminal-2007jun20.zip
-rw-r--r-- 1 freedos users 13608 Apr 23  2005 terminal-rom.tar.gz


And:

$ unzip -l terminal-2007jun20.zip
Archive:  terminal-2007jun20.zip
  Length  DateTimeName
-  -- -   
0  06-20-2007 11:17   terminal/
 4175  10-20-2001 01:37   terminal/term-comm.asm
 6613  06-20-2007 11:17   terminal/term-data.asm
 1823  10-18-2001 14:55   terminal/term-def.asm
  635  10-19-2001 17:39   terminal/eecho.asm
 6333  04-23-2005 14:16   terminal/term-tty.asm
 3867  06-20-2007 11:17   terminal/terminal.com
  123  10-19-2001 17:40   terminal/eecho.com
11944  06-20-2007 11:17   terminal/terminal.asm
  197  11-16-2001 13:05   terminal/prn-term.inf
 7962  06-20-2007 11:16   terminal/term-irq.asm
 2516  11-16-2001 11:27   terminal/term-menu.asm
17061  10-20-2001 15:15   terminal/term-ansi.asm
 8359  10-19-2001 15:32   terminal/term-disp.asm
 3175  04-23-2005 14:14   terminal/term-set.asm
 6014  11-16-2001 13:04   terminal/terminal.txt
18349  03-01-2002 08:29   terminal/copying.txt
 3975  11-06-2002 14:04   terminal/term.bat
- ---
   103121 18 files


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


[Freedos-devel] Reminder: FreeDOS virtual get-together coming up (Sunday)

2024-04-30 Thread Jim Hall via Freedos-devel
Hi everyone!

I wanted to remind everyone of the upcoming FreeDOS virtual
get-together, happening on Sunday, May 5 at 11am US/Central (use your
favorite timezone converter to find your local time).

I'll share the link when the meeting starts. As before, we'll use Google Meet.

We alternate topics every time, and the May meeting will be
'technical.' This is a great opportunity to do live debugging, ask
about setup and configuration, and other 'tech' topics.


___
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

2024-04-28 Thread Jim Hall via Freedos-devel
On Sun, Apr 28, 2024 at 4:33 PM Han Held via Freedos-devel
 wrote:
>
> For anyone interested, Neozeed has a youtube video that he put up that walks 
> through the steps of fetching dos 4's source from github and building a 
> bootable copy of it.
> [Compiling MS-DOS 4.0 using DOSbox & Qemu]
>


I also posted a video on the FreeDOS YouTube channel, earlier today,
showing how to MS-DOS 4.00 on FreeDOS. (All credit to ecm's fixes.)
This uses a fresh, vanilla FreeDOS 1.3 "plain DOS" install, with the
FDAUTO.BAT file replaced with a single PATH statement (only because I
didn't need all the other stuff to do the build).

https://youtu.be/X7r76V_gWQ8


___
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

2024-04-26 Thread Jim Hall via Freedos-devel
To correct myself: I was getting a bunch of unrelated errors because I
made a mistake in my SETENV.BAT file. I set the CL, LINK, and MASM
variables to point to the executables (similar to what you might do on
Unix makefiles with CC, CFLAGS, etc)

But those variables are options to those commands (like DIRCMD) so
that was causing additional garbage.


If I clear out the CL, LINK, and MASM variables, my build attempt
fails in the same way that the OS/2 Museum does.


But hey, MS-DOS Edlin builds correctly - so there's that! But it won't
run on FreeDOS because "Incorrect DOS version." :-)


___
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

2024-04-26 Thread Jim Hall via Freedos-devel
Jim Hall wrote:
[..]
> > But when I try to build it, it fails in the MAPPER directory with
> > "line too long":
> >
[..]
> >> cd ..\mapper
> >> nmake
> >>
> >> Microsoft (R) Program Maintenance Utility   Version 1.00.05
> >> Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.
> >>
> >> masm -Mx -t  -I. -I..\inc -I..\dos chdir.asm,chdir.obj;
> >> D:\src\tools\MASM.EXE(1): error A2106: Line too long
>

Robert Riebisch wrote:
> UTF-8 conversion is the culprit:
> https://www.os2museum.com/wp/how-not-to-release-historic-source-code/


Well, that's unfortunate. But at least it's not just me.

Before I saw your reply, I also realized that the source files were
converted to UNIX LF ending (missing CR) so I ran unix2dos on Linux
using 'find' to get all the *.INC and *.ASM files:

unix2dos -f -ascii -437


..but that didn't help.

I'm kind of busy with other things, so I'm not going to throw myself
at this. But please share if they provide a fixed version.


___
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

2024-04-26 Thread Jim Hall via Freedos-devel
On Fri, Apr 26, 2024 at 2:28 PM Jim Hall  wrote:
>
[..]
> How did you compile it? I'm having trouble getting the compile to work.
>
> Here's what I'm doing: I've booted my system using FreeDOS but using
> their tools. My C: drive is FreeDOS, and my D: drive is empty except
> for the SRC directory from the MS-DOS 4.0 release on GitHub. I set up
> my environment by editing the SETENV.BAT and running it:
>
[..]
>
> It's interesting that line 1 of CHDIR.ASM is just an empty ";" comment
> (line 1 is 1 character long) so I don't get why MASM says line 1 is
> too long.


Also interesting is that when the build fails, CHDIR.ASM has been deleted:

> D:\SRC\MAPPER>dir chdir.*
>  Volume in drive D is MSDOS4
>  Volume Serial Number is 3353-1607
>
>  Directory of D:\SRC\MAPPER
>
> CHDIROBJ14,702  04-26-24  6:53p
>  1 file(s) 14,702 bytes
>  0 dir(s) 489,603,072 bytes free


___
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

2024-04-26 Thread Jim Hall 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.

On Fri, Apr 26, 2024 at 2:25 AM 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.


How did you compile it? I'm having trouble getting the compile to work.

Here's what I'm doing: I've booted my system using FreeDOS but using
their tools. My C: drive is FreeDOS, and my D: drive is empty except
for the SRC directory from the MS-DOS 4.0 release on GitHub. I set up
my environment by editing the SETENV.BAT and running it:


@echo off
echo setting up system to build the MS-DOS 4.01 SOURCE BAK...
set COUNTRY=usa-ms
set BAKROOT=D:
rem BAKROOT points to the home drive/directory of the sources.
set LIB=%BAKROOT%\src\lib
set INIT=%BAKROOT%\src\tools
set INCLUDE=%BAKROOT%\src\inc
set PATH=%BAKROOT%\src\tools;C:\freedos\bin
set CL=%INIT%\CL.EXE
set LINK=%INIT%\LINK.EXE
set MASM=%INIT%\MASM.EXE


This is my PATH:

> D:\>path
> PATH=D:\src\tools;C:\freedos\bin


Yes, I'm really running the Microsoft NMAKE from their tree:

> D:\>nmake
>
> Microsoft (R) Program Maintenance Utility   Version 1.00.05
> Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.
>
> NMAKE : fatal error U1051: usage : 'NMAKE' [-bcdeinpqrst -f makefile -x 
> stderrfi
> le] [macrodefs] [targets]
> Stop.


But when I try to build it, it fails in the MAPPER directory with
"line too long":

> D:\>cd src
> D:\SRC>nmake
>
> Microsoft (R) Program Maintenance Utility   Version 1.00.05
> Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.
>
> cd messages
> nmake
>
> Microsoft (R) Program Maintenance Utility   Version 1.00.05
> Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.
>
> attrib -R usa-ms.msg
> buildidx usa-ms.msg
> Index file and message file are of different levels.
> Message file and index file will be updated.
> Message file updated.
> Index file updated.
> attrib +R usa-ms.msg
> cd ..\mapper
> nmake
>
> Microsoft (R) Program Maintenance Utility   Version 1.00.05
> Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.
>
> masm -Mx -t  -I. -I..\inc -I..\dos chdir.asm,chdir.obj;
> D:\src\tools\MASM.EXE(1): error A2106: Line too long
> D:\src\tools\MASM.EXE(10): error A2106: Line too long
> D:\src\tools\MASM.EXE(11): error A2106: Line too long
> D:\src\tools\MASM.EXE(13): error A2106: Line too long
> D:\src\tools\MASM.EXE(19): error A2106: Line too long
> D:\src\tools\MASM.EXE(31): error A2106: Line too long
> D:\src\tools\MASM.EXE(34): error A2106: Line too long
> D:\src\tools\MASM.EXE(36): error A2106: Line too long
> D:\src\tools\MASM.EXE(38): error A2106: Line too long
> D:\src\tools\MASM.EXE(40): error A2106: Line too long
> D:\src\tools\MASM.EXE(41): error A2106: Line too long
> D:\src\tools\MASM.EXE(47): error A2106: Line too long
> D:\src\tools\MASM.EXE(48): error A2106: Line too long
> D:\src\tools\MASM.EXE(77): error A2106: Line too long
> D:\src\tools\MASM.EXE(88): error A2106: Line too long
> D:\src\tools\MASM.EXE(114): error A2106: Line too long
> D:\src\tools\MASM.EXE(120): error A2106: Line too long
> D:\src\tools\MASM.EXE(127): error A2106: Line too long
> D:\src\tools\MASM.EXE(141): error A2106: Line too long
> D:\src\tools\MASM.EXE(142): error A2106: Line too long
> D:\src\tools\MASM.EXE(150): error A2106: Line too long
> D:\src\tools\MASM.EXE(154): error A2106: Line too long
> D:\src\tools\MASM.EXE(156): error A2106: Line too long
> D:\src\tools\MASM.EXE(164): error A2106: Line too long
> D:\src\tools\MASM.EXE(165): error A2106: Line too long
> D:\src\tools\MASM.EXE(166): error A2106: Line too long
> D:\src\tools\MASM.EXE(167): error A2106: Line too long
> D:\src\tools\MASM.EXE(168): error A2106: Line too long
> D:\src\tools\MASM.EXE(169): error A2106: Line too long
> D:\src\tools\MASM.EXE(171): error A2106: Line too long
> D:\src\tools\MASM.EXE(172): error A2106: Line too long
> D:\src\tools\MASM.EXE(174): error A2106: Line too long
> D:\src\tools\MASM.EXE(184): error A2106: Line too long
> D:\src\tools\MASM.EXE(185): error A2106: Line too long
> D:\src\tools\MASM.EXE(188): error A2106: Line too long
> D:\src\tools\MASM.EXE(194): error A2106: Line too long
> D:\src\tools\MASM.EXE(202): error A2106: Line too long
> D:\src\tools\MASM.EXE(207): error A2106: Line too long
> D:\src\tools\MASM.EXE(218): error A2106: Line too long
> D:\src\tools\MASM.EXE(219): error A2106: Line too long
> D:\src\tools\MASM.EXE(231): error A2106: Line too long
> D:\src\tools\MASM.EXE(237): error A2106: Line too long
> D:\src\tools\MASM.EXE(239): error A2106: Line too long
> D:\src\tools\MASM.EXE(241): error A2106: Line too long
> D:\src\tools\MASM.EXE(246): error A2106: Line too long
> D:\src\tools\MASM.EXE(251): error A2106: Line too 

[Freedos-devel] The new FreeDOS wiki

2024-04-16 Thread Jim Hall via Freedos-devel
I wasn't able to finish copying over the content from our old wiki to
the new wiki before SourceForge applied another update to their web
server, which completely broke the old wiki.

But I copied over most of the wiki before then. Two things that are
obviously missing are two setup guides: Installing FreeDOS, and
Networking FreeDOS. Several other missing pages describe program
usage, which I plan to copy from Willi's HTML Help content.

Even though the old wiki is effectively broken, the content is still
on the SF server. I plan to copy the guide content directly from the
SF database and put them into the new wiki. I'll have time after May 5
to do that, so no changes planned until then.


The new wiki is at:
https://wiki.freedos.org/wiki/

I've put up a note on the old wiki to point people to the new wiki:
https://freedos.sourceforge.io/wiki/

*I just realized the wiki website "front page" still has the "coming
soon" message .. I'll turn that into a redirect:
https://wiki.freedos.org/

I've also updated the www.freedos.org "Read the wiki" link .. this
brings up an interstitial page that used to let folks know that we
were moving the wiki, and the old wiki was showing "unstyled" pages.
Now the interstitial lets folks know that the wiki has some "red"
links that will get filled in soon.

Note: While I was putting content on the new wiki, I realized we
should have more wiki pages about programs, so the red links are *not*
pages that are missing from the old wiki - they are new pages that
haven't been written yet.


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


[Freedos-devel] Edlin [was: libm-0.7 Released!]

2024-04-14 Thread Jim Hall via Freedos-devel
Tom Ehlert wrote:
> > btw: do you have a lot of communication about EDLIN?

Gregory Pietsch wrote:
>
> I did have a lot of communication about Edlin when it was first released, but 
> not as much anymore.


I actually use Edlin, and I do so without irony. It's great if you run
a command and want to make a quick BAT file out of it. I don't need
Edit for that, I can just as easily tap out a few lines in Edlin and
save it.

One thing that would make that easier is a command line option to
suppress Edlin output. Something like /QUIET or /Q to not display the
"welcome" message (copyright & license). Because if I run a command
and want to make a BAT file out of it, the extra text might push some
interesting stuff off the top of the screen.

Also, it would be nice if Edlin supported the /? option on DOS to
display the usage. Right now, it assumes any command line parameter is
a file:

> C:\> edlin /?
> edlin 2.23, copyright (c) 2003 Gregory Pietsch
> This program comes with ABSOLUTELY NO WARRANTY.
> It is free software, and you are welcome to redistribute it
> under the terms of the GNU General Public License -- either
> version 2 of the license, or, at your option, any later
> version.
>
> /?: New file.
> *

Here's an idea: if Edlin supported /? for usage, Edlin might only
display the "welcome" screen there and *not* display it during normal
program startup. That would remove my need for a /QUIET command line
option.


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


Re: [Freedos-devel] libm-0.7 Released!

2024-04-13 Thread Jim Hall via Freedos-devel
On Sat, Apr 13, 2024 at 12:35 PM Gregory Pietsch via Freedos-devel
 wrote:
>
> Submitted for your approval, the latest version of libm, FreeDOS's
> public domain math library, has been released! For this version,
> I have worked on edge cases regarding complex numbers and dug deep
> into the C99 Standard.
>[..]


Very cool!

Gregory emailed this to me so I could put it on Ibiblio. I've mirrored
this release in the usual place on the FreeDOS Files Archive:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/0.7/


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


Re: [Freedos-devel] I16GCC would need DJGPP, but DJGPP not present in FDT2404 (fixed!)

2024-04-10 Thread Jim Hall via Freedos-devel
On Wed, Apr 10, 2024 at 10:20 AM Jim Hall  wrote:
> The DJGPP environment variable just needs to point to a file called
> DJGPP.ENV (or whatever) that contains a bunch of environment settings
> for programs that were compiled with DJGPP. For example, this file
> contains stanzas for GNU Emacs, GNU Bison, and other programs.
>
> But you can point to any file. [..] my DJGPP.ENV file is basically
> empty:
>
> C:\SRC>type DJGPP.ENV
> DJDIR=
>
>
> But I can compile just fine:
[..]


And a further demo:

When I installed FreeDOS T2404, I installed the I16GCC packages, but
obviously T2404 doesn't include the DJGPP stuff. So can you compile
programs using IA-16 GCC on T2404 without DJGPP? Yes! Just do what I
did. Here's my demo:


My C:\DEVEL directory contains just OpenWatcom C and IA-16 GCC. I
added the T.ENV file (because you can call the DJGPP env file
anything) and the ARGS.C file is just a dummy program I wrote as a
demo:

C:\DEVEL>dir /b
I16GNU
WATCOMC
ARGS.C
T.ENV

C:\DEVEL>type t.env
DJDIR=

C:\DEVEL>type args.c
#include 
int main(int argc, char **argv)
{
 int i;
 for (i = 0; i < argc; i++) {
  puts(argv[i]);
 }
 return 0;
}


And now compile it by setting the DJGPP variable to point to the
(empty) T.ENV file, then run IA-16 GCC as usual:

C:\DEVEL>set DJGPP=C:\DEVEL\T.ENV
C:\DEVEL>path C:\freedos\bin;C:\devel\i16gnu\bin
C:\DEVEL>i16gcc -Wall -o args.exe args.c
C:\DEVEL>args.exe this is a test 1 2 3 4 5
C:\DEVEL\ARGS.EXE
this
is
a
test
1
2
3
4
5


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


[Freedos-devel] Proposal for new package in T2405

2024-04-10 Thread Jim Hall via Freedos-devel
Based on my other email about getting IA-16 GCC to work on T2404
without installing DJGPP, I propose adding a new package in T2405
called I16ENV that just has two files in it:

/devel/i16gnu/djgpp.env
/devel/i16gnu/setenv.bat

The DJGPP.ENV file contains just:

DJDIR=

And the SETENV.BAT file sets the PATH and points the DJGPP environment
variable to the DJGPP.ENV file, like this:

@ECHO OFF
PATH %PATH%;C:\DEVEL\I16GNU\BIN
SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV


Since it gets installed in the IA-16 GCC directory, it shouldn't get
confused with the DJGPP stuff. If the DJGPP env file is called
DJGPP.ENV, it will make more sense when people find references to
"DJGPP.ENV" in other documentation. And because the package will be
named similarly to the other IA-16 GCC packages, users will be more
likely to install it when they install IA-16 GCC. But because we
aren't updating any original IA-16 GCC packages, it keeps things clean
at the expense of a little extra "overhead" for the package. But if
you're installing a C compiler, you likely can spare the tiny extra
space.

This will be a good way for others to start testing compiling programs
using IA-16 GCC in a working default configuration on a fresh install,
starting with the next test release.

This works on my T2404 installation. Here is a copy/paste of my
FreeDOS session after a fresh reboot (using unmodified FDAUTO.BAT):

C:\DEVEL>dir /b
I16GNU
WATCOMC

C:\DEVEL>cd i16gnu

C:\DEVEL\I16GNU>dir /b
BIN
IA16-ELF
LIB
LIBEXEC
SHARE
DJGPP.ENV
SETENV.BAT

C:\DEVEL\I16GNU>type setenv.bat
@ECHO OFF
PATH %PATH%;C:\DEVEL\I16GNU\BIN
SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV

C:\DEVEL\I16GNU>type DJGPP.ENV
DJDIR=

C:\DEVEL\I16GNU>setenv.bat

.. now I'll switch to the D: drive to compile a program ..

D:\SRC>dir /b hello.*
HELLO.C

D:\SRC>type hello.c
#include 
int main()
{
puts("Hello world");
return 0;
}

D:\SRC>i16gcc -Wall -o hello.exe hello.c

D:\SRC>dir /b hello.*
HELLO.C
HELLO.EXE

D:\SRC>hello.exe
Hello world


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


Re: [Freedos-devel] I16GCC would need DJGPP, but DJGPP not present in FDT2404 (fixed!)

2024-04-10 Thread Jim Hall via Freedos-devel
On Tue, Apr 9, 2024 at 5:46 PM Paul Dufresne via Freedos-devel
 wrote:
>
> But installing I16BUTIIL,
> SET DJDIR=C:\DEVEL\I16GNU
> i16gcc -o hel2.exe hel2.c
> works!
>
[..]


The DJGPP environment variable just needs to point to a file called
DJGPP.ENV (or whatever) that contains a bunch of environment settings
for programs that were compiled with DJGPP. For example, this file
contains stanzas for GNU Emacs, GNU Bison, and other programs.

But you can point to any file. Here's an example: I started with a
fresh install of FreeDOS 1.3 (plain DOS .. and installed the "DJGPP"
package and the various I16GCC packages). The IA-16 GCC is installed
in C:\DEVEL\I16GNU, and the bin directory is C:\DEVEL\I16GNU\BIN

I set up a new directory called C:\SRC that contains this:

C:\SRC>dir /b
DJGPP.ENV
HELLO.C


The "HELLO.C" source file is just a dummy "Hello world" program:

C:\SRC>type hello.c
#include 
int main()
{
 puts("Hello world");
 return 0;
}


As I mentioned, the DJGPP stuff needs to look in the DJGPP.ENV file
for default settings. The file minimally needs to have DJDIR defined.
But in the case of IA-16 GCC, this is safe to leave empty because
IA-16 GCC is its own compiler. So my DJGPP.ENV file is basically
empty:

C:\SRC>type DJGPP.ENV
DJDIR=


But I can compile just fine:


C:\SRC>path C:\freedos\bin;C:\devel\i16gnu\bin
C:\SRC>set DJGPP=C:\src\DJGPP.ENV
C:\SRC>i16gcc -Wall -o hello.exe hello.c
C:\SRC>hello.exe
Hello world


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


Re: [Freedos-devel] FreeDOS Wiki

2024-03-26 Thread Jim Hall via Freedos-devel
On Tue, Mar 26, 2024 at 5:25 PM Jerome Shidel via Freedos-devel
 wrote:
>
> Hi,
>
> Apparently, the (old) FreeDOS wiki on sourceforge is down or broken.
>
> After visiting the FreeDOS.org website, navigating to “Read the
> wiki” and waiting, I just get a blank page after redirection to the
>
> https://freedos.sourceforge.io/wiki/index.php/Main_Page web page.


I was *this* close to getting the last two guides ("Installing
FreeDOS" and "Networking FreeDOS") copied over, but ran out of time
because of some things at work. Then SourceForge broke something on
their end a few days ago. I'll do a selective Mediawiki upgrade on SF
over the weekend to get things back to a working state so I can
copy/paste the rest of the content.

The data is still there in the database, it's just that the PHP code
is barfing somewhere because the older Mediawiki doesn't seem to work
well on the newer PHP that SF upgraded to.

After I get those two guides copied over, I'll open it up to user
accounts to anyone who wants one. And I'll add a redirect to hide the
"w" in the URL, and change the "wiki" link on the www.freedos.org
website to point to the new website.

Any content after the two guides is pretty minor (command line usage,
etc) which can get moved over time.


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


Re: [Freedos-devel] FETCH4FD

2024-03-23 Thread Jim Hall via Freedos-devel
On Sat, Mar 23, 2024 at 6:23 AM Danilo Pecher via Freedos-devel
 wrote:
>
> Neofetch is a good way to give you a quick overview of the machine's
> parameters. It's perhaps more of a gimmick under DOS, but in a unix
> environment it can be a godsent. When I was database administrator at
> Infineon I had to work with about 3000 different machines running
> either Linux, Solaris, AIX or HP-UX. So you have 3000 different
> hostnames to ssh into. Some you visit almost daily, but some test
> servers or legacy systems you only visit once in a very long while.
>
> In that case it is more than helpful to have the most pertinent
> parameters at a glance right after login.
>


Definitely neofetch (or similar .. there were other programs like that
before it) is useful when you're managing a network of servers that
have different specs. But as you wrote, I'm not sure that a program
that just collects and prints system info is particularly useful to
install by default on a DOS machine in 2024. So while I think it's
great to write a new program for FreeDOS, I'm not very excited about
including FETCH4FD in the FreeDOS install, unless there's some other
useful feature (for example, command line tests that could run
silently to automate BAT files depending on the system type, or free
disk, or available memory - such as FETCH4FD /TEST /MEM=16 returns 0
[success] if the system has at least 16MB of memory, or /TEST
/FREE=100 returns 0 [success] if the current drive has 100MB or more
of free disk space.)

In the original DOS era, there were lots of programs that did this.
One obvious example was Norton's SI (System Info) utility. And years
ago, we used to include COMPINFO in a previous FreeDOS distribution,
but I don't remember why we stopped including it. If I had to guess,
probably it was the same question of "usefulness."


I'm also not sure FETCH4FD is the best name, but that's entirely my
personal preference. To me, "Fetch" implies it's going to retrieve a
file or some other resource over a network. As in "to go for and then
bring back something for someone." Also, FETCH4FD is difficult for me
to type because of the "4" in there. To me, more obvious (and easier
to type) names include DOSINFO or SYSINFO.

Jim


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


Re: [Freedos-devel] FreeDOS wiki updates + questions

2024-03-20 Thread Jim Hall via Freedos-devel
> On Wednesday, March 20th, 2024 at 10:09 AM, Jim Hall via Freedos-devel 
>  wrote:
>
[..]
> > What to do about the "Networking How-to"? This is a collection of
> > pages that wasn't written as a typical "wiki" page (every page in a
> > wiki should stand on its own, with links to other pages for more info)
> > but as a series of pages that follow step 1, step 2, .. etc.
> >
> > Should I just copy/paste those pages into the new wiki, or move them
> > out into a new kind of "how-to" article?
> >
> > We have another collection of pages for an "Installation Guide" and I
> > have the same question there.
> >
> >
> > Related:
> >
> > I (and others) wrote a bunch of articles about FreeDOS for
> > Opensource.com before they stopped publishing (about a year ago).
> > Opensource.com is still up, and I'd like to copy/paste the FreeDOS
> > articles into a website that we control in case Opensource.com goes
> > away. At least the articles I wrote, and I can ask permission of other
> > authors if I have their contact info.
> >
[..]
> >
> > Should I just copy/paste those into the new wiki, or should I create a
> > new website to republish these, like a howto.freedos.org website .. or
> > maybe a "howto" directory on the new wiki website (but outside the
> > "wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory
> > on the main website, like www.freedos.org/howto .. what's the best
> > plan?
[..]

On Wed, Mar 20, 2024 at 1:50 PM Mercury Thirteen via Freedos-devel
 wrote:
> Personally, I'm a big fan of keeping information in one easy to access
> place. If it were me, I would put the articles in their own section
> on the wiki under a helpful title, where they could also be linked to
> from other articles in the wiki, e.g. an article on how to install
> FreeDOS could link to How-Tos detailing how one would partition and
> format their drive. I'm no SEO expert by far, but I would think that
> the fact that the articles are not simply copy-pasted but are also
> linked to from other pages on the site - not to mention that there
> is a ton of other content on the wiki, making it more than a simple
> copy-paste ripoff of the source site - would mitigate the down-ranking
> which Google et al. may otherwise do.


I'm definitely a fan of not adding more work for myself. :-)

Adding the how-to articles inside the wiki seems like a good idea,
then. And that way, it keeps all documentation in one place. Maybe
I'll create a "parent" entry like "Howto" and copy/paste all the other
how-to articles under that so you have paths like
wiki.freedos.org/Howto/(topic) or whatever.


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


[Freedos-devel] FreeDOS wiki updates + questions

2024-03-20 Thread Jim Hall via Freedos-devel
I've been moving the FreeDOS wiki content over by copy/paste. And I've
finished almost all of the tricky pages .. then it's a collection of
small pages (mostly usage pages for programs) which I think should go
quickly. Then I'll add wiki editor accounts for anyone who wants them.

The new wiki will be here:
https://wiki.freedos.org/w/index.php?title=Main_Page

(don't bookmark that yet .. the "w" part in the URL will likely go away)


Question:

What to do about the "Networking How-to"? This is a collection of
pages that wasn't written as a typical "wiki" page (every page in a
wiki should stand on its own, with links to other pages for more info)
but as a series of pages that follow step 1, step 2, .. etc.

Should I just copy/paste those pages into the new wiki, or move them
out into a new kind of "how-to" article?

We have another collection of pages for an "Installation Guide" and I
have the same question there.


Related:

I (and others) wrote a bunch of articles about FreeDOS for
Opensource.com before they stopped publishing (about a year ago).
Opensource.com is still up, and I'd like to copy/paste the FreeDOS
articles into a website that we control in case Opensource.com goes
away. At least the articles I wrote, and I can ask permission of other
authors if I have their contact info.

Again, these aren't written to be "wiki" pages, they are standalone
articles about how to do something in FreeDOS (like how to use CD and
DIR, other useful commands, conio programming, .. etc) in 800 to 1000
words.
https://opensource.com/tags/freedos

Should I just copy/paste those into the new wiki, or should I create a
new website to republish these, like a howto.freedos.org website .. or
maybe a "howto" directory on the new wiki website (but outside the
"wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory
on the main website, like www.freedos.org/howto .. what's the best
plan? Since Google's "SEO" ranking generally "down-ranks" websites
that copy/paste content from other websites, creating a new website
name like howto.freedos.org seems like a good idea, but I don't want
to create a bunch of work for myself if others have a better idea


Jim


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


Re: [Freedos-devel] Reminder: FreeDOS virtual get-together on Sunday

2024-03-10 Thread Jim Hall via Freedos-devel
Interesting! I didn't get a prompt from Google Meet to specify how
long to let the meeting continue after I left, so I was concerned that
Meet just dropped everyone after I had to leave. I'm glad it kept the
meeting going for other folks.


On Sun, Mar 10, 2024 at 4:04 PM Jerome Shidel via Freedos-devel
 wrote:
>
> Hi Jim,
>
> > On Mar 10, 2024, at 1:42 PM, Jim Hall via Freedos-devel 
> >  wrote:
> >
> > On Sun, Mar 10, 2024 at 12:09 PM Jim Hall  wrote:
> >>
> >> Thanks to everyone who joined the FreeDOS virtual get-together today!
>
> We hung out for about 45 minutes after you left. Then, I had to go. Don’t 
> know  oh w about the rest. They could still be there. :-)
>
> Jerome
> >
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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


Re: [Freedos-devel] Reminder: FreeDOS virtual get-together on Sunday

2024-03-10 Thread Jim Hall via Freedos-devel
On Sun, Mar 10, 2024 at 12:09 PM Jim Hall  wrote:
>
> Thanks to everyone who joined the FreeDOS virtual get-together today!
>
> This call was really just "social time" so we spent a lot of time
> catching up with one another.
>
> The next virtual get-together will focus on "technical." That's a
> great opportunity to do live debugging, work through issues, and cover
> other tech topics related to FreeDOS.


I'm looking ahead on my calendar, and April will be tough for me (lots
going on). Let's do the next virtual get-together on Sunday, May 5.


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


Re: [Freedos-devel] Reminder: FreeDOS virtual get-together on Sunday

2024-03-10 Thread Jim Hall via Freedos-devel
Thanks to everyone who joined the FreeDOS virtual get-together today!

This call was really just "social time" so we spent a lot of time
catching up with one another.

The next virtual get-together will focus on "technical." That's a
great opportunity to do live debugging, work through issues, and cover
other tech topics related to FreeDOS.


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


[Freedos-devel] Here's the meeting URL

2024-03-10 Thread Jim Hall via Freedos-devel
I'll start the get-together in a few minutes, but here's the URL for
anyone who needs it:

FreeDOS virtual get-together (social)
Sunday, March 10 · 11:00am – 12:30pm
Time zone: America/Chicago
Google Meet joining info
Video call link: https://meet.google.com/eua-spwn-euy
Or dial: ‪(US) +1 347-305-6319‬ PIN: ‪692 124 151‬#
More phone numbers: https://tel.meet/eua-spwn-euy?pin=5735754726737


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


[Freedos-devel] Reminder: virtual get-together

2024-03-10 Thread Jim Hall via Freedos-devel
Hi everyone

Don't forget about this morning's virtual get-together!

We are on Daylight Saving Time in the US. It's 9:00am now, so that means
the meeting is in two hours from now (11:00-12:00).


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


Re: [Freedos-devel] I'm migrating the wiki

2024-03-08 Thread Jim Hall via Freedos-devel
A quick status on migrating the wiki:

I set up a new Wikimedia instance on a new wiki.freedos.org host this
week, and yesterday I started to copy content from the old wiki into
the new wiki. This is a copy/paste exercise for a few reasons that
I've explained in another email, but here's a summary:

[begin summary]
Background: Long ago, SourceForge set up a shared Mediawiki
environment for all projects hosted at SF. Every project used the same
wiki system but had a different prefix. All SF users had a wiki login
by default. Later, SF decided to stop hosting a shared wiki, so they
made a data export available to every project and provided
instructions to set up your own Mediawiki. We did that on the SF web
host. In late-ish 2023, SF's website update meant our wiki can't use a
stylesheet. I can't blame them, the wiki software was out of date
(very difficult to update a website hosted at SF).

I could export the data from SF and import it into a new wiki, but
that would import *all* of the wiki users. And the SF database
includes *all* SF users. I don't want to import all those unneeded
accounts, so I'm setting up a fresh wiki. There aren't a ton of pages
in our wiki, so I'm copy/pasting everything.
[end summary]

SF is planning another website update on March 18. There's no reason
to think the old SF web hosting will stop working, but I am making
that a self-imposed deadline; I want to get all of our wiki content
moved by March 18. I think I'll make that deadline.

So far, it's been very do-able. I made a lot of content updates on the
"front" page of the wiki and the first few other pages I moved over. I
think I've finished the pages that needed the most updating (out of
date) so the most recent pages I've moved were a copy/paste exercise
with very minimal edits for any obvious spelling/grammar.

Dreamhost (the web hosting company) has very strict anti-spam measures
in place, so sometimes I run against that when pasting long blocks of
very technical text that might include commands. I think that's
triggering the spam protection so those pages are taking more effort
to get in (doing it in parts seems to help) but most are just
copy/paste.

As part of this exercise, I'm also making all the pages look more
consistent. That usually means pages need to have a 1-line summary at
the top, rather than starting with a long block of text.

I'm also adding more links to things that should be in the wiki. Some
of those will get "filled in" as part of the migration, others will be
new pages. So if you see red links, don't panic. That's what a wiki is
for.

If you want to see the new wiki, it is at https://wiki.freedos.org/w/

(The "w" part will go away eventually, but for now it's basically a
"hidden unless you know it's there" location.)

Once I get all the content moved over, I'll set up wiki accounts for
anyone who wants them.

Jim


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


Re: [Freedos-devel] I'm migrating the wiki

2024-03-08 Thread Jim Hall via Freedos-devel
On Thu, Mar 7, 2024 at 3:53 PM Jim Hall  wrote:
>
> Just wanted to share that I'm (finally) migrating the FreeDOS Wiki
> content. I've set up a new wiki instance on a new server, and I'm
> going through the list of pages on the old wiki, and copy/pasting the
> content on the new wiki.
>
[..]
> *Unrelated: The shared hosting service is currently experiencing an
> outage, so the website (and new wiki) is down. It should be working
> again soon. I think we can assume this is a coincidence to my working
> on the new wiki. :-)

Turns out, not unrelated, and not a coincidence. The server has an
uptime of over 49 days, so it wasn't a server failure. They looked
into other causes for me.

Short version: I had put in a few pages before I discovered the "Live
preview" feature of the Wiki. I assumed it was a client-side visual
editor or preview (it is not). After effectively spamming the server
with traffic (new preview after I keep typing) the server temporarily
blocked my IP. That's why all my websites on their shared hosting went
"down." It resolved on its own when the block was lifted.

So that was self-inflicted. I'll stop using "Live preview" but they've
added my IP to a whitelist anyway.


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


[Freedos-devel] I'm migrating the wiki

2024-03-07 Thread Jim Hall via Freedos-devel
Just wanted to share that I'm (finally) migrating the FreeDOS Wiki
content. I've set up a new wiki instance on a new server, and I'm
going through the list of pages on the old wiki, and copy/pasting the
content on the new wiki.

That sounds like a lot of work, but a lot of the content needs to be
updated anyway, so this is a good opportunity to do that.

-Jim


*Unrelated: The shared hosting service is currently experiencing an
outage, so the website (and new wiki) is down. It should be working
again soon. I think we can assume this is a coincidence to my working
on the new wiki. :-)


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


[Freedos-devel] Website has moved to new hosting

2024-03-06 Thread Jim Hall via Freedos-devel
FYI that the www.freedos.org website has moved to new hosting. It's
still at the same website hosting company, but on a new server. (This
was the web hosting company doing a planned replacement of the old
hardware.) Things look like they have moved over okay, I don't see any
issues.

They are keeping the old web server running for a while, to respond to
any requests on the old server (for example, with the old hostname in
your DNS cache). I've posted the announcement about the upcoming
get-together on both servers.

If you're curious if you're accessing the new server or the old one, I
added this temporary file on the new server. It tells you if you are
using the new server or the old one:
https://www.freedos.org/new.txt


If you can see the contents of that file, you're using the new web
server. If you get a "404" error, then you are using the old web
server (try again in a few days).

Jim


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


[Freedos-devel] Reminder: FreeDOS virtual get-together on Sunday

2024-03-06 Thread Jim Hall via Freedos-devel
Hi everyone!

I wanted to send a reminder of our upcoming FreeDOS virtual
get-together on Sunday, March 10. Same time as usual: from 11am to
noon US/Central (use your favorite timezone converter to find your
local time).

However, note that March 10 is also the start of US Daylight Saving
Time, so clocks will be "ahead" one hour. If your region doesn't
observe Daylight Saving Time, or has a different changeover date,
please be aware of the time issue.

I'll send an email to the list with the URL to join before the meeting
starts. We will do the meeting again with Google Meet, since that has
worked out well.

We alternate topics on the get-together. Last month was 'technical'
topics, this month is social time. We may still talk about technical
items, but mostly this is an opportunity to get to know folks as more
than just an email address.

See you then!

Jim


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


Re: [Freedos-devel] Updated FDAUTO.BAT file

2024-03-01 Thread Jim Hall via Freedos-devel
And I just saw the typo in DOSLFN.CON ... should be DOSLFN.COM

I don't have LFN loaded, so I didn't see this come up. :-P


Jerome: If you accept this for the next test release, please fix my typo. :-)


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


Re: [Freedos-devel] Updated FDAUTO.BAT file

2024-03-01 Thread Jim Hall via Freedos-devel
Resending with FDAUTO.BAT as a file attachment (renamed FDAUTO.TXT) so
it's easier to try out the config.


Jim
@ECHO OFF
REM - Updated AUTOEXEC file

REM - set basic environment

set DOSDRV=C:
set DOSDIR=%DOSDRV%\FREEDOS

path %DOSDIR%\BIN
if not exist %DOSDIR%\LINKS\NUL goto NOLINKS
path %PATH%;%DOSDIR%\LINKS
:NOLINKS

set NLSPATH=%DOSDIR%\NLS
set HELPPATH=%DOSDIR%\HELP

set TEMP=%DOSDIR%\TEMP
set TMP=%TEMP%

if "%CONFIG%"=="5" goto END

set OS_NAME=FreeDOS
set OS_VERSION=T2403

REM - cfgfile and autofile might be deprecated in future

set CFGFILE=%DOSDRV%\FDCONFIG.SYS
set AUTOFILE=%DOSDRV%\FDAUTO.BAT
alias cfg=edit %CFGFILE%
alias auto=edit %AUTOFILE%

REM - detect CPU, load CPU-specific configs

if not exist %DOSDIR%\BIN\VINFO.COM goto ENDCPU
%DOSDIR%\BIN\VINFO.COM /m
if errorlevel 3 goto CPU386
if errorlevel 2 goto CPU286
goto ENDCPU

:CPU286

fdapm APMDOS
ctmouse

goto ENDCPU

:CPU386
if "%CONFIG%"=="4" goto CPU286

lh fdapm APMDOS
lh ctmouse
REM lh share

if not exist %DOSDIR%\BIN\DOSLFN.CON goto NOLFN
lh %DOSDIR%\BIN\DOSLFN.CON
REM - Add other stuff here once LFN is loaded..
:NOLFN

if not exist %DOSDIR%\BIN\CDROM.BAT goto NOCDROM
call %DOSDIR%\BIN\CDROM.BAT
REM - Add other stuff here once CDROM is loaded..
:NOCDROM

:ENDCPU

REM - load other configs using external BAT files

if not exist %DOSDIR%\BIN\FDNET.BAT goto NONET
call %DOSDIR%\BIN\FDNET.BAT
REM - Add other stuff here once FDNET is loaded..
:NONET

if not exist %DOSDIR%\BIN\FDASSIST.BAT goto NOASSIST
call %DOSDIR%\BIN\FDASSIST.BAT
:NOASSIST

if not exist %DOSDIR%\BIN\WELCOME.BAT goto NOHELLO
call %DOSDIR%\BIN\WELCOME.BAT
:NOHELLO

MEM /C /N

REM - local settings

set BLASTER=A220 I5 D1 H5 P330
set DIRCMD=/O:GNE /Y
set COPYCMD=/-Y

REM nlsfunc %DOSDIR%\BIN\COUNTRY.SYS
REM display CON=(EGA,858,2)
REM mode CON CP PREP=((858) %DOSDIR%\CPI\EGA.CPX)
REM keyb US,858,%DOSDIR%\BIN\KEYBOARD.SYS
REM chcp 858
REM mkeyb UK

alias reset=fdisk /reboot
alias reboot=fdapm warmboot
alias halt=fdapm poweroff
alias shutdown=fdapm poweroff

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


[Freedos-devel] Updated FDAUTO.BAT file

2024-03-01 Thread Jim Hall via Freedos-devel
Hi everyone

The new T2403 release prompted me to finish updating the FDAUTO.BAT file.

Quick background: This started because I was looking to prevent the
CTMOUSE driver from loading .. but it was a bit hard to read the
FDAUTO file. So I simplified it on my end.

This should do everything the previous FDAUTO did - I just moved
things around. Interestingly, I also freed up a tiny amount (160
bytes) of memory. Here's the MEM output from a fresh boot before I
made changes:

> Memory TypeTotal   Used   Free
>         
> Conventional  639K33K   606K
> Upper   0K 0K 0K
> Reserved  385K   385K 0K
> Extended (XMS) 31,616K   433K31,183K
>         
> Total memory   32,640K   851K31,789K
>
> Total under 1 MB  639K33K   606K
>
> Total Expanded (EMS)8,816K (9,027,584 bytes)
> Free Expanded (EMS) 8,192K (8,388,608 bytes)
>
> Largest executable program size   605K (619,552 bytes)
> FreeDOS is resident in the high memory area.

And here's the MEM output from a fresh boot with the new FDAUTO file:

> Memory Type Total  Used   Free
>         
> Conventional  639K33K   606K
> Upper   0K 0K 0K
> Reserved  385K   385K 0K
> Extended (XMS) 31,616K   433K31,183K
>         
> Total memory   32,640K   851K31,789K
>
> Total under 1 MB  639K33K   606K
>
> Total Expanded (EMS)8,816K (9,027,584 bytes)
> Free Expanded (EMS) 8,192K (8,388,608 bytes)
>
> Largest executable program size   605K (619,712 bytes)
> FreeDOS is resident in the high memory area.

160 bytes isn't much, but I thought it was interesting. :-)

The original FDAUTO was 98 lines, my cleaned up FDAUTO file is 101
lines but I think it's easier to read. The general idea is to put
"system" stuff at the top, and "user" stuff at the end. In summary, it
sets a few env variables, then loads CPU-specific configs (for
example: LFN and CDROM on 386+, ..) then loads the "supporting" BAT
files if they are there. I moved the user's local settings (BLASTER,
DIRCMD, aliases, ..) to the end of the file:

> @ECHO OFF
> REM - Updated AUTOEXEC file
>
> REM - set basic environment
>
> set DOSDRV=C:
> set DOSDIR=%DOSDRV%\FREEDOS
>
> path %DOSDIR%\BIN
> if not exist %DOSDIR%\LINKS\NUL goto NOLINKS
> path %PATH%;%DOSDIR%\LINKS
> :NOLINKS
>
> set NLSPATH=%DOSDIR%\NLS
> set HELPPATH=%DOSDIR%\HELP
>
> set TEMP=%DOSDIR%\TEMP
> set TMP=%TEMP%
>
> if "%CONFIG%"=="5" goto END
>
> set OS_NAME=FreeDOS
> set OS_VERSION=T2403
>
> REM - cfgfile and autofile might be deprecated in future
>
> set CFGFILE=%DOSDRV%\FDCONFIG.SYS
> set AUTOFILE=%DOSDRV%\FDAUTO.BAT
> alias cfg=edit %CFGFILE%
> alias auto=edit %AUTOFILE%
>
> REM - detect CPU, load CPU-specific configs
>
> if not exist %DOSDIR%\BIN\VINFO.COM goto ENDCPU
> %DOSDIR%\BIN\VINFO.COM /m
> if errorlevel 3 goto CPU386
> if errorlevel 2 goto CPU286
> goto ENDCPU
>
> :CPU286
>
> fdapm APMDOS
> ctmouse
>
> goto ENDCPU
>
> :CPU386
> if "%CONFIG%"=="4" goto CPU286
>
> lh fdapm APMDOS
> lh ctmouse
> REM lh share
>
> if not exist %DOSDIR%\BIN\DOSLFN.CON goto NOLFN
> lh %DOSDIR%\BIN\DOSLFN.CON
> REM - Add other stuff here once LFN is loaded..
> :NOLFN
>
> if not exist %DOSDIR%\BIN\CDROM.BAT goto NOCDROM
> call %DOSDIR%\BIN\CDROM.BAT
> REM - Add other stuff here once CDROM is loaded..
> :NOCDROM
>
> :ENDCPU
>
> REM - load other configs using external BAT files
>
> if not exist %DOSDIR%\BIN\FDNET.BAT goto NONET
> call %DOSDIR%\BIN\FDNET.BAT
> REM - Add other stuff here once FDNET is loaded..
> :NONET
>
> if not exist %DOSDIR%\BIN\FDASSIST.BAT goto NOASSIST
> call %DOSDIR%\BIN\FDASSIST.BAT
> :NOASSIST
>
> if not exist %DOSDIR%\BIN\WELCOME.BAT goto NOHELLO
> call %DOSDIR%\BIN\WELCOME.BAT
> :NOHELLO
>
> MEM /C /N
>
> REM - local settings
>
> set BLASTER=A220 I5 D1 H5 P330
> set DIRCMD=/O:GNE /Y
> set COPYCMD=/-Y
>
> REM nlsfunc %DOSDIR%\BIN\COUNTRY.SYS
> REM display CON=(EGA,858,2)
> REM mode CON CP PREP=((858) %DOSDIR%\CPI\EGA.CPX)
> REM keyb US,858,%DOSDIR%\BIN\KEYBOARD.SYS
> REM chcp 858
> REM mkeyb UK
>
> alias reset=fdisk /reboot
> alias reboot=fdapm warmboot
> alias halt=fdapm poweroff
> alias shutdown=fdapm poweroff
>
> :END



Personally, I'm not a fan of cfgfile and autofile since the user could
always rename FDCONFIG.SYS in favor of using CONFIG.SYS .. but FDAUTO
will still report "Done processing startup files C:\FDCONFIG.SYS and
C:\FDAUTO.BAT" (this is actually printed in WELCOME.BAT). So I've left
a comment in the updated FDAUTO that "cfgfile and autofile might be
deprecated in future".
:-)


Jim


___
Freedos-devel mailing 

Re: [Freedos-devel] FDISK 1.3.14

2024-02-22 Thread Jim Hall via Freedos-devel
Excellent news! I'll post an item on the website about it.

I can't login to Ibiblio from where I'm at right now, so I can't
mirror it - maybe someone else with Ibiblio access can do that for me.
Otherwise I'll mirror this to Ibiblio over the weekend.


Jim

On Thu, Feb 22, 2024 at 12:25 PM Bernd Böckmann via Freedos-devel
 wrote:
>
> I imported FDISK 1.3.14 to the FreeDOS package repository. Changes from last 
> imported version are:
>
> Fixes:
> - CRITICAL: Fix a drive letter disagree between DOS and FDISK in cases
>  involving multiple disks and a mix of active and non-active
>  primary partitions.
> - HIGH: Prevent querying LBA capabilities via INT13,41, if LBA access is 
> disabled
>  by the user. This caused some broken BIOS to crash the system,
>  like BIOS version 0.9.4 of Book8088 and Xi8088.
>
> Changes:
>  - Do not check for extra cylinders by default. DR-DOS refuses to use
>partitions exceeding the BIOS reported disk size, despite being valid.
>  - Update German translation.
>
> Bernd
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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


Re: [Freedos-devel] NewDOS source code has been published!

2024-02-17 Thread Jim Hall via Freedos-devel
On Sat, Feb 17, 2024 at 8:39 AM Wilhelm Spiegl via Freedos-devel
 wrote:
>
> Hi Jim,
>
> I forgot to mention that there is another great new thing: NewDOS and its 
> source code is free since 2024-02-06!
> NewDOS itself is freeware since 2018.
>
> You can grab it here: https://www.newdos.de/home/download.htm
>
[...]
> @Jim: Would it be possible to keep a copy ad ibiblio or anywhere else?
>


Sure thing. We've mirrored a few other DOS projects when they went
offline. For example, before GNUish went offline, they reached out to
me to ask if I'd mirror GNUish at Ibilbio. And I did. Since NewDOS is
GNU GPL, I'm comfortable mirroring the last copy at Ibiblio.

As with GNUish, I mirrored this outside the standard "FreeDOS Files"
area. You can find it here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/mirrors/www.newdos.de/




*By the way, GNUish was mirrored here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/mirrors/gnuish/

..although the "gnuish" location is really a Unix symlink to here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/mirrors/ftp.sunet.se/pub/simtelnet/gnu/gnuish/


*And: If anyone here is already linking to GNUish from another
website, FYI that I just now created the 'mirrors' subdirectory, to
keep things organized on Ibiblio. If you have a website that links to
the GNUish mirror, you should change your link from
https://ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/
..to
https://ibiblio.org/pub/micro/pc-stuff/freedos/mirrors/gnuish/


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


[Freedos-devel] Directory cleanup on Ibiblio

2024-02-17 Thread Jim Hall via Freedos-devel
FYI that I've done a little reordering in the 'dos/debug' directory on
Ibiblio. We actually have three versions of DEBUG here, so I wanted to
make clear which was which:


The change: Because it was the "original" FreeDOS DEBUG, we had each
version of Vojta's DEBUG as a separate directory under
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/

These are the DEBUGversions:
> 0.95  1.01  1.06  1.08  1.10  1.12  1.14  1.16  1.18  1.20  1.22  1.24
> 0.98  1.02  1.07  1.09  1.11  1.13  1.15  1.17  1.19  1.21  1.23  1.25

And because Debug/X picked up where Vojta's DEBUG left off, we tracked
each version in the same directory at
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/

These are the Debug/X versions:
> 1.27  1.28  1.29  2.0  2.01  2.02

And because lDebug was a variation from Debug/X, I originally put them
in a subdirectory at
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/

These are the lDebug releases:
> rel1  rel2  rel3  rel4  rel5  rel6  rel7


But I wanted to make clear which versions were which. Specifically, it
seemed unclear (to me) to have Vojta's DEBUG and ecm's Debug/X "mixed"
in the same directory, but not lDebug. So I made a new directory for
'vojta' and 'debugx'. So now each variation on DEBUG has its own
directory:


*"parent" directory:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/

vojta - Paul Vojta's original DEBUG, the original FreeDOS DEBUG
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/vojta/

debugx - Japheth's Debug/X, based on Vojta's DEBUG
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/debugx/

ldebug - ecm's lDebug, based on Debug/X
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/



I'll add a text file in the "parent" directory to clarify which is which.


Jim


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


[Freedos-devel] Updated news items

2024-02-16 Thread Jim Hall via Freedos-devel
I'm assuming folks check the website pretty regularly for various news -
but in case not, I wanted to share these news items you may have missed
about recent program updates.

I try to stay up to date on new programs coming out, but I'm sure to miss
some things. If a program has a new version out, please share that here on
the email list.

















*Virtual SoundBlaster for HDA2024-02-14 4:35pmVSBHDA provides SoundBlaster
emulation for HDA (and AC97/SBLive). It is Japheth's fork of crazii's SBEMU
driver. This one works with an unmodified HDPMI32i, making it compatible
with HX. VSBHDA supports HDA (Intel's High Definition Audio), Intel ICH /
nForce, VIA VT82C686, VT8233/35/37, and VIA VT82C686, VT8233/35/37. It
emulates SoundBlaster 1.0, 2.0, Pro, Pro2, 16 in 8-bit, 16-bit, mono,
stereo, and high-speed modes. Version 1.1 is now available from VSBHDA on
GitHub.Updated Debug/X2024-02-14 4:32pmDebug/X is a package of debuggers by
Japheth, and includes Debug (like MS-DOS DEBUG), DebugX (an extended
version), and additional variants like DebugXv, DebugXg, DebugB or DebugR
that are useful in certain cases. Japheth recently released a new Debug/X
collection; version 2.02 fixes S command (position display was corrupted in
v2.00-v2.01). You can download the new version at Debug/X v2.02 or get the
source code from the Debug/X GitHub.JEMM 5.842024-02-14 4:24pmJEMM is an
"Expanded Memory Manager" (EMM) based on EMM386. Japheth updated JEMM with
a few fixes: + Simulate_IO() no longer calls trap handler + int 67h,
ax=5B01h will return error code A3h if checksum invalid + QPIEMU: new JLM
that partly implements QEMM's API + JEMMDBG: removed from binary package.
You can find it at the JEMM GitHub, or more directly from the JEMM 5.84
release.Blocek text editor minor update2024-02-09 6:24amLaaca has released
a minor update to the Blocek text editor. "The binaries are the same but I
included corrected documentation and message files. (Fixes wording and
typos.)" You can download the updated version 1.75b from the Blocek
website. *
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] Xcopy 1.5

2024-02-16 Thread Jim Hall via Freedos-devel
Answering my own question on this:

I don't know that anyone was aware of an updated version of Xcopy (1.5). So
this was just missed.

I think we should include Xcopy 1.5 in the next test release, T2403.


*We're all volunteers, if you see a new version of a program and no one is
talking about it, share that news on the email list.


On Fri, Feb 16, 2024, 11:14 PM Jim Hall  wrote:

> I noticed over on the BTTR forum, Fritz asked this question about Xcopy
> 1.5. But freedos-devel is really the best place to discuss FreeDOS
> distribution topics, so I wanted to start a thread here to make sure the
> question was asked in the right place:
>
> Fritz asked:
>
> >>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[...]version 1.5 improved Open Watcom support (utilizes
> pieces from TCC2WAT), shared.incIn xcopy.txt you can read:Compiling the
> source code-Compiling the source code is possible
> with the following compilers:- Borland C++ (tm) 3.0 or higher- Borland
> Turbo C++ (tm) 3.0 or higherVersion 1.2 and newer can also be compiled with
> the now freeware- Borland Turbo C 2.01 compiler :-)Version 1.5 and newer-
> Open Watcom C/C++ 1.9/2.0pre (includes portions of tcc2wat)So my question:
> Is it useful to implement version 1.5 into the future FDT24xx versions?*
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


[Freedos-devel] Xcopy 1.5

2024-02-16 Thread Jim Hall via Freedos-devel
I noticed over on the BTTR forum, Fritz asked this question about Xcopy
1.5. But freedos-devel is really the best place to discuss FreeDOS
distribution topics, so I wanted to start a thread here to make sure the
question was asked in the right place:

Fritz asked:

>>>






























*Hi,while searching updates for FDT24xx I noticed that xcopy uses version
1.4.You can find it at:https://gitlab.com/FreeDOS/base/xcopy
history says that the only
difference between 1.4 and 1.4a is that a html file was added.At
https://github.com/FDOS/xcopy  there is an
unpublished and uncompiled version 1.5., see: history.txt,version
1.4---version 1.4a- added xcopy.htm Help file, based on
xcopy.txt (Stephan Peters)version 1.5 improved Open Watcom
support (utilizes pieces from TCC2WAT), shared.incIn xcopy.txt you can
read:Compiling the source code-Compiling the source
code is possible with the following compilers:- Borland C++ (tm) 3.0 or
higher- Borland Turbo C++ (tm) 3.0 or higherVersion 1.2 and newer can also
be compiled with the now freeware- Borland Turbo C 2.01 compiler :-)Version
1.5 and newer- Open Watcom C/C++ 1.9/2.0pre (includes portions of
tcc2wat)So my question: Is it useful to implement version 1.5 into the
future FDT24xx versions?*
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


  1   2   >