Re: [Freedos-user] Missing CDROM drive

[Jerome Shidel via Freedos-user]

Hi,On Apr 7, 2024, at 6:46 PM, dnashmcp--- via Freedos-user  wrote:I have a Thinkpad X301 (I think a perfect fit for FreeDOS). I was able to install to C: from the FD-13LIVE CD and it loads a driver for the CDROM as ELTORITO, but when I boot after installation it fails on the first attempt to load a cdrom driver. The install of ELTORITO point to www.nu2.nu/eltorito but there is nothing there. I am so rusty on DOS and I need some help.
___Freedos-user mailing listFreedos-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-userI was informed that the ELTORITO driver was only good for booting from CD. This is why the driver is not automatically installed to the hard disk.However, some users have reported that it has worked for them as a general CD driver when booting from the hard drive.  You can just boot the LiveCD again and copy the driver over from the CD onto the hard drive. It is located in the \FREEDOS\BIN directory. It should be copied to the same location on the hard drive.Then reboot from the hard drive. The CD initialization process will automatically try that driver (when present) if the others don’t work.Jerome___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS install

[Jerome Shidel via Freedos-user]

Hi,

> On Apr 6, 2024, at 8:40 PM, Norby Droid via Freedos-user 
>  wrote:
> 
> One issue I find alot when tryin to install FreeDos is that it would go most 
> of the way through the install then without any reason and no explanation as 
> to why, it just stops and says there is a problem so reboot or exit.

The installer is batch based. It uses other executable utilities to perform the 
required tasks. This limits the amount of information that is passed back to 
the installer when an error occurs. 

However, there are only a couple things that generally cause an install to fail 
after packages have already started to extract successfully.

Corrupted install media.
Insufficient disk space.
File conflicts.

Around the time of the 1.3 release, there was a file conflict that would occur 
when Full+Sources was selected. One of the packages contained its source files 
and those of another package. So when selected, it would cause a conflict 
during installation. That conflict was resolved and does not occur in the 
latest test builds.

You could just install BASE with or without sources. Then after rebooting from 
the installed system, put the CD back into the drive and run FDIMPLES. 

That will make it easy to install any additional packages that could have been 
installed with FULL or those from the BonusCD.

You could also try the monthly interim test build of FreeDOS. While it is not a 
“release”, it contains many fixes since 1.3 and numerous software updates. 
However, it is a test build and some of the updated software may have issues. 
It is available on ibiblio in the test directory for distributions.

> 
> I have FD in three locations.  Second drive in my old desktop, usb drive, and 
> in connectix virtual pc in windows xp.  The glitch would happen no matter 
> which environment I use.  I decided to use 7zip to test and extract all files 
> from the liveCD and all passed and was successful.  As another test I went in 
> and tested all the .zip files found in the directories and they also all 
> passed the test.  I take from this that if the files are good then the issue 
> is with my system?

If your installing Full + Sources, possibly not.

> 
> Is there any way to find out why it crashes? 

Not really. 

When 1.3 was released, there was no reliable good was to record such 
information during installation.

Since that time, a new utility was created that can efficiently record boot 
messages, program output and other messages. That programs recording could be 
output to a log when needed. 

However, no decision has been made to use the program on the install media. If 
it were, support could be added to the installer to record more detailed 
information about the installation process. 


> I know in the latest version on ibiblio the file “TestDisk” is where it would 
> always crash.  Is it possible to just extract all the .zip files into 
> separate directories in each folder the zips reside in and still have a 
> proper FreeDos install?

Well, mostly yes. But, there are some issues with dying it that way.

Most programs that come with FreeDOS will work fine regardless of what 
directory they are located. However, a few won’t and need configured for their 
location.

Also, the directories in the zip archive are meta-directories. Many paths are 
remapped during the package installation.  

:-)
Jerome

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

Re: [Freedos-user] How to try FDT2404 (Latest test version) on QEMU

[Jerome Shidel via Freedos-user]

Hi Paul,

Just a side note about installing using the FullUSB.

One of my DOS test machines is an Acer One netbook with a 1Ghz Atom processor 
and an ancient 30Gb SSD. This machine has no CD/DVD drive. It does boot from 
the FullUSB when written to a flash drive. It takes about 5 minutes from start 
to finish (boot, partition, reboot, install, reboot) to do a Full install 
without sources. 

That machine will also boot from a USB floppy drive. 

Another side note…

You could create a second partition on the USB stick and copy the files from 
the Bonus CD to to that.

Although it can only use one at a time, modern versions of FDIMPLES can use 
different local package repositories. 

You could have different repos on different drives. Or, even multiple ones on 
the same drive in different paths.

When FDIMPLES starts, it checks the current drive for a repository in one of 
the standard paths. If it does not find one, it searches existing drives C: 
through Z: for a repository. 

You can also tell it to check a specific drive (and/or alternate path) for a 
repo at startup. 

For example,

C:\>fdimples e:
C:\>fdimples d:\repo-1

etc.  

:-)

Jerome

> On Apr 4, 2024, at 11:45 PM, Paul Dufresne via Freedos-user 
>  wrote:
> 
> Hi! Especially to Lunduke fans having their "second part" of DOS week... 
> about one year and a half after first part.
> So from April 3 to April 10 2024.
> I am not a paid subscriber to lunduke.locals.com and just observing it from 
> far.
> 
> I decided to retry FreeDOS after not using it for too many months.
> 
> And as I do in this time... I search back the messages I have previously left 
> on the list to help me know how to launch qemu...
> as I don't think the wiki have an article about it...
> But it has been a long time... and I am seeding a new message for the next 
> time(s).
> 
> So FDT2404 is out: "
> ###
> FreeDOS 2404-Test ("FreeDOS T2404")
> ###
> 
> Warning: This is a FreeDOS development build and is for testing purposes.
> It may exhibit behavior vary different from a release build and may not be
> suitable for regular use. For general use, please consider using the latest
> release build available at http://freedos.org
> "
> 
> And can be found at:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/readme.txt
> 
> This time, I  have chosen to use 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2404-FullUSB.zip
> rather than the usual 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2404-LiveCD.zip
> Mostly, I find a disk image, a more simple and logical format that a CDROM or 
> DVD image format (iso file).
> 
> So with an iso file I would use -cdrom image.iso... but the FullUSB.zip 
> contains an .img file, that I will use the same
> qemu parameter as the hard drive destination image: -drive 
> format=raw,file=$DISK where DISK=T2404FULL.img
> 
> Steps goes about like this:
> Download and extract 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FDT2404-FullUSB.zip
>  in FDT2404 directory.
> cd FDT2404
> qemu-img create fdos.img 1000M
> DESTDISK=fdos.img
> INSTALLDISK=FDT2404FULL.img
> 
> At install time, I present first INSTALLDISK, then DESTDISK:
> qemu-system-i386 -cpu 486 -name FreeDOS -machine pc-i440fx-4.2 -m 64 -drive 
> format=raw,file=$INSTALLDISK -drive format=raw,file=$DESTDISK -audiodev 
> pa,id=mysnd -device sb16,audiodev=mysnd -device adlib,audiodev=mysnd -machine 
> pcspk-audiodev=mysnd -vga cirrus -display sdl -net nic,model=pcnet -net user
> 
> After installation, I present first DESTDISK containing the installed 
> FreeDOS, and then INSTALLDISK (not so much needed anymore):
> qemu-system-i386 -cpu 486 -name FreeDOS -machine pc-i440fx-4.2 -m 64 -drive 
> format=raw,file=$DESTDISK -drive format=raw,file=$INSTALLDISK -audiodev 
> pa,id=mysnd -device sb16,audiodev=mysnd -device adlib,audiodev=mysnd -machine 
> pcspk-audiodev=mysnd -vga cirrus -display sdl -net nic,model=pcnet -net user
> 
> Information given at boot seems to say E: is the INSTALLDISK... but it is 
> really D: ... I don't know why.
> 
> Games seems to work often better than it did in my memory.
> Was it on VirtualBox that color palette was wrong?
> 
> Also... Magic Mirror game seems to start... and I did not remember to have 
> seen it working before.
> 
> For me DHCP seems not really working... but I run this on Vanilla  OS ... 
> with apx run $command  and so I think maybe it does not work because the 
> virtual machine
> is running inside the Ubuntu sub-machine (an other virtual machine as far as 
> I know).
> 
> So it seems to be the gist of what I wanted to say.
> 
> 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> 

Re: [Freedos-user] QEMU - Max size of Linux access folder

[Jerome Shidel via Freedos-user]

Hi,

Since you said, the source code is about 640MB and is on an old XP machine….

Why not just boot the FreeDOS Live CD, enable LFN support by installing the 
driver to the Live Environment and running it.

Then install the compiler to the Live Environment.

Then just compile the source directly from the hard disk drive.

Or, just create a 2GB hard drive for QEMU and put the OS, sources and any 
needed software on that drive. Then compile it in the VM.

I don’t understand why those are not viable options. I must be missing 
something.

Jerome

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

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[Jerome Shidel via Freedos-user]

Hi Ralf,

> On Feb 9, 2024, at 2:16 PM, Ralf Quint via Freedos-user 
>  wrote:
> 
> Are you guys trying to have DOS behave like macOS? 
> 
> Beside that any trickery with the keyboard controller would only work on an 
> AT keyboard, where the controller chip is actually on the motherboard of the 
> computer, and thus accessible with an I/O port, on XT/PC keyboards the 
> controller is in the keyboard itself and not/far less accessible for any 
> programming..
> 
> 
> Ralf

You don’t really need to reprogram the keyboard controller. You just need to 
take control away from the BIOS. It is what happens in my game engine. Now 
processing the keystrokes at that level gets a little weird. The incoming scan 
codes can very widely based on the keyboard controllers state. There aren’t 
just E0+ codes. Plus on top of that, you can get multiple codes for a single 
keypress or release.

Nothing insurmountable. 

:-)

Jerome


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



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

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[Jerome Shidel via Freedos-user]

Well, 

If I were making something to support typing those extra/alternate characters, 
the driver would probably behave like this…

Normal typing and continuous key press would behave as normal. This includes 
key repeating at the set typographic rate.

I would implement some of the techniques used in my gaming engine to support 
keys that are not supported by DOS and DOS programs. By default, it would 
probably bind to the Fn (Function) key. However, could be changed to any 
physical key such as the Win, Left-Alt, Right-Shift. Or even very special keys 
like Play, WWW, Search, etc. 

When the Fn (The default bound key)  was pressed, the driver would wait for 
another key such as “a”. Each time the letter “a” was pressed it would cycle 
through the special keys configured for Fn+a. These combinations could be 
different for Shift+Fn+a. The cycling would just involve sending a Backspace 
then the New Key. When the user finally released the Fn key, the system should 
continue processing keys normally.

The driver would also probably support longer key sequences and macros. Like 
possibly Fn+Ctrl+D could type out the current date.

The driver could include “accessibility” support. When enabled, do things like 
disable autorepeat and AUTOSHIFT letters when the key is held down. Plus allow 
making Fn sticky. Press once for special combinations, press again to go back 
to normal. Etc.

This is all stuff I’ve considered adding directly to the V8Turbo Command 
Interpreter/Shell. Along with support for different such mappings based on what 
program is running. 

Hopefully, I’ll find the time to return to it’s development at some point. I 
want to restructure it to make it even more efficient before continuing much 
further. I just don’t have the spare time at present. 

:-)

Jerome

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

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[Jerome Shidel via Freedos-user]

Hi,


> 
> To fake shifts, one can just modify the flags at 40:17 and 18.
> It will not update the keyboard LEDs, but that is acceptable.
> The BIOS itself uses 40:96 and 97 to track its own status.
> 

It has been a very long time. But, if I recall correctly, I’m fairly sure you 
can programmatically change the LEDs as well. But, I don’t recall the details. 
But, I might have code sitting around somewhere that has that functionality. 

However excluding CAPS LOCK LED, I don’t think I’ve had a keyboard with the 
other LEDs for a very long time.  No real way for me to test that at present.

> Of course the details can get a bit more complicated, as
> you also have press and release events for shift keys etc.
> and special E0 ... key combinations and so on. But if you
> are happy with just the most mainstream keys acting in that
> "long press means shift" style and only while no actual
> ctrl, shift, alt or similar modifier keys are pressed, it
> should be quite feasible to implement this.


Special and multiple key combinations was something I built into the keyboard 
driver in the “Danger Engine.” That is the game and application framework I 
made for some programs provided with FreeDOS. 

The keyboard driver it has can track things like Left-Control+Right-Alt+A+P or 
Up+Left+Tab. No real limit on total simultaneous keys in the driver. Plus, it 
recognizes keys not normally supported under DOS. For instance, the Volume keys 
and Browser buttons on my ancient Logitech Media Keyboard.

But, that driver is not very efficient. Being a prototype experiment, it is 
cobbled together. Now that the issues involved were worked out, it needs to be 
rewritten from scratch.

Even though the Danger Engine does some neat stuff, the same goes for the 
entire thing. It definitely needs a rewrite.

:-)

Jerome

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

Re: [Freedos-user] Date check

[Jerome Shidel via Freedos-user]

> On Jan 30, 2024, at 8:01 AM, Jürgen Wondzinski via Freedos-user 
>  wrote:
> 
> Hi Jerome,
>  
> Perfect! Thanks for the pointer to that VSTR utility!
>  
> wOOdy

Your welcome

:-)

>  
> Von: Jerome Shidel via Freedos-user  <mailto:freedos-user@lists.sourceforge.net>> 
> Gesendet: Dienstag, 30. Januar 2024 13:38
> An: FreeDOS Users  <mailto:freedos-user@lists.sourceforge.net>>
> Cc: jer...@shidel.net <mailto:jer...@shidel.net>
> Betreff: Re: [Freedos-user] Date check
>  
> Hi,
> Sure. 
>  
> You can have date output the current date and save it in an environment 
> variable. 
> The test the return string against the known BAD value.
>  
> Something like…
>  
> set /e TODAY=date /d
> if “%TODAY%” == “Current date is TUE 01-30-2024” goto BadDate
> goto GoodDate
> :BadDate
> date
> time
> :GoodDate
> set TODAY=
>  
>  
> Or, if you want to get a little more fancy…
>  
> date /d | vstr /b /f “ “ 5- | set /p TODAY=
> if “%TODAY%” == “01-30-2024” goto BadDate
> (see above)
>  
> Or, even just check the year…
>  
> date /d | vstr /b /f - 3 | set /p YEAR=
> if “%YEAR%” == “2024” goto BadDate
> (see above)
>  
> Or, even better…
>  
> date /d | vstr /b /f - 3 | set /p YEAR=
> if NOT “%YEAR%” == “1980” goto GoodDate
> date
> time
> :GoodDate
> set YEAR=
>  
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net <mailto:Freedos-user@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-user 
> <https://lists.sourceforge.net/lists/listinfo/freedos-user>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Date check

[Jerome Shidel via Freedos-user]

Hi,

> On Jan 30, 2024, at 7:00 AM, Jürgen Wondzinski via Freedos-user 
>  wrote:
> 
> Hi all,
> 
> I'm currently facing some users which seem to have a bad BIOS battery and 
> therefor aren't using the current date. 
> Those users aren't even noticing that wrong date on their printed invoices of 
> that day...  
> 
> Is there a simple way to check from Autoexec/FDAUTO for the year of the date, 
> and if lower than 2024 prompt for a correct setting?
> 
> Thanks!

Sure. 

You can have date output the current date and save it in an environment 
variable. 
The test the return string against the known BAD value.

Something like…

set /e TODAY=date /d
if “%TODAY%” == “Current date is TUE 01-30-2024” goto BadDate
goto GoodDate
:BadDate
date
time
:GoodDate
set TODAY=


Or, if you want to get a little more fancy…

date /d | vstr /b /f “ “ 5- | set /p TODAY=
if “%TODAY%” == “01-30-2024” goto BadDate
(see above)

Or, even just check the year…

date /d | vstr /b /f - 3 | set /p YEAR=
if “%YEAR%” == “2024” goto BadDate
(see above)

Or, even better…

date /d | vstr /b /f - 3 | set /p YEAR=
if NOT “%YEAR%” == “1980” goto GoodDate
date
time
:GoodDate
set YEAR=


Jerome

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

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

Re: [Freedos-user] Is networking unsupported on QEMU? Pilot error suspected.

[Jerome Shidel via Freedos-user]

Hi,

> On Dec 27, 2023, at 1:04 PM, andrew fabbro via Freedos-user 
>  wrote:
> 
> Greetings!
> 
> I'm a bit perplexed trying to get networking working for FreeDOS 1.3 on QEMU. 
>  My physical host is an M1 Mac (Apple Silicon).
> 
> FreeDOS installs and boots fine, but I get this message:
> 
> QEMU network detected.
> Physical hardware networking is not supported at this time.
> 
> Here is my QEMU invocation:
> 
> qemu-system-i386 -boot order=cd -m 32M -k en-us -name FreeDOS1 -cdrom 
> FD13BNS.iso -drive FreeDOS1.img,format=raw,media=disk -net nic,model=pcnet 
> -net user
> 
> I've also tried model=ne2k_pci, model=e1000, etc.  Also tried similar setup 
> in UTM, which is a graphical front end for QEMU.
> 
> But looking at FreeDOS's startup scripts, I'm thinking maybe QEMU networking 
> is not supported...?
> 
> At line 84 of FDAUTO.BAT, "%dosdir%\bin\fdnet.bat start" is called.  Looking 
> at fdnet.bat, at line 92, "vinfo /m" is executed.  When I execute this myself 
> at the command line, errorlevel is set to 102.  In fdnet.bat, this branches 
> to a label called NoAutoQEMU on line 109.  There, since %1 is "start" there's 
> a goto NoStartQEMU.  That gives the "QEMU network detected" message.  Then 
> there's a goto NoHardware, which gives the "Physical networking is not 
> supported at this time" and end.

Although I am not looking at the batch at present, that sounds about right. 

When the default “start” option is provided, FDNET will only attempt to start 
networking support under VirtualBox and VMware. On real hardware and other 
virtual platforms, it will just provide that error message and exit. 

The reason for this is simple. It is known to work under those virtual machines 
with the available open source drivers (by various authors) which included with 
the FDNET package. 

It’s been a few years. However, I think I also provided a “try” option which 
will try anyway.

It also supports custom initialization batch files that could be simply dropped 
into it’s directory for other hardware and proprietary drivers. That can 
alleviate the requirement of modifying the FDAUTO.BAT every time a OS install 
is performed. 

> So is networking under QEMU completely unsupported?

Mostly, it comes down to time and resource constraints. QEMU is more 
customizable than other Virtual Platforms and would most likely require more 
testing and inclusion of instructions on how to make it work.

> Strangely, I found this forum post in which someone has it working just fine, 
> so I'm thinking that maybe I'm doing something wrong?
> 
> https://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/freedos-in-qemu-no-internet-connection-4175638386/
>  
> 

FDNET works well enough for it’s intended purpose. At least for the foreseeable 
future, I cannot devote the time needed for supporting other platforms. 

It would be great for someone knowledgeable in DOS networking to adopt FDNET 
and give it the love and attention required to make it the best it could be. 
Maybe even including support for real hardware and all of those CRYNWR drivers. 

:-)

Jerome


> -- 
> andrew fabbro
> and...@fabbro.org 
> 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

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

Re: [Freedos-user] What DOS programs represent the 1980s and early 90s?

[Jerome Shidel via Freedos-user]

During the DOS years, I used XTree a lot for moving things and general file 
management. 

During the early DOS years, I used Professional Write. Eventually, I moved on 
to the Lotus Suite. 

But as with the platforms that came before, I spent most of my time in DOS 
writing code. Mainly that consisted of GW-BASIC, followed by Microsoft 
QuickBasic then moving to Turbo Pascal (and it’s inline assembler). 

:-)

> On Dec 24, 2023, at 11:33 PM, Jim Hall via Freedos-user 
>  wrote:
> 
> I'm thinking about doing a video that shows how to do real work on DOS. I 
> sometimes see comments on YouTube with people asking "could you really do 
> *work* with DOS?" And the answer is of course you can, that happened every 
> day.
> 
> So I'm collecting a list of things you'd do in the 80s and 90s with DOS to do 
> work. Sure, I'll put a game it two in there, but I'm focusing on getting work 
> done.
> 
> What programs or types of programs would you like to see?
> 
> __
> 
> *For myself:
> I've done some videos about DOS apps, but nothing like "here's how I did 
> everyday work." When I think back to my 1980s and 1990s (especially the early 
> 90s) I think of my time at university as a physics undergrad. So that's a 
> spreadsheet and a word processor for sure. Probably make a simple chart then 
> include that chart in a "lab report" document (or at least leave room in the 
> document to print it when I print on a dot matrix printer). Probably a dialup 
> terminal to talk to the uni committee lab? File manager. And a compiler to 
> write my own tools.
> 
> The only difference is for the video I'll try to highlight FreeDOS distro 
> tools as much as possible, like Doszip for the file manager. 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

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

Re: [Freedos-user] HIMEMX zip file dates

[Jerome Shidel via Freedos-user]

Hi Jim,

> On Oct 1, 2023, at 7:05 PM, Jim Hall via Freedos-user 
>  wrote:
> 
> Eric wrote:
>> You can also find updates for JEMM and HIMEMX on Japheth's GitHub "Baron von 
>> Riedesel", even his HIMEMSX to use more than 4 GB RAM :-)
> 
> Mercury Thirteen wrote:
> [..]
>> Looks like I fell behind on keeping up with all of Japheth's updates! The 
>> downloads section at MercuryCoding.com has been updated with new versions of 
>> HiMemX and JWasm as well. Thanks, Eric, for (indirectly) pointing this out 
>> to me! :)
>> 
> 
> I didn't have the latest HIMEMX mirrored on Ibiblio, so I just grabbed
> the copies you have. I checked the file contents, and they have been
> touched since the original. For example, 3.38
> (https://github.com/Baron-von-Riedesel/HimemX/releases) was released
> Nov 21, 2022 and has file contents like this:
> 
> $ unzip -l HimemX338.zip
> Archive:  HimemX338.zip
>  Length  DateTimeName
> -  -- -   
> 6056  11-21-2022 13:01   HimemX.exe
> 6056  11-21-2022 13:01   HimemX2.exe
> 1954  04-16-2020 06:38   Readme.txt
> 4871  11-21-2022 13:01   History.txt
>81855  11-21-2022 13:01   HimemX.asm
>  296  03-24-2020 01:56   Make.bat
>  529  03-24-2020 01:58   Makefile
> - ---
>   101617 7 files
> 
> 
> It looks like you modify the zip files when you mirror them. Your
> version looks like this:
> 
> $ unzip -l 3.38/himemx338.zip
> Archive:  3.38/himemx338.zip
>  Length  DateTimeName
> -  -- -   
>0  09-23-2023 03:38   APPINFO/
>  568  09-23-2023 03:38   APPINFO/HIMEMX.LSM
>0  09-23-2023 03:38   BIN/
> 6056  09-23-2023 03:38   BIN/HIMEMX.EXE
> 2168  09-23-2023 03:38   BIN/UMBM.EXE
> 6056  09-23-2023 03:38   BIN/HIMEMX2.EXE
>0  09-23-2023 03:38   DOC/
>0  09-23-2023 03:38   DOC/HIMEMX/
> 1954  09-23-2023 03:38   DOC/HIMEMX/README.TXT
> 4871  09-23-2023 03:38   DOC/HIMEMX/HISTORY.TXT
>0  09-23-2023 03:38   SOURCE/
>0  09-23-2023 03:38   SOURCE/UMBM/
>  296  09-23-2023 03:38   SOURCE/UMBM/MAKE.BAT
>12147  09-23-2023 03:38   SOURCE/UMBM/UMBM.ASM
>0  09-23-2023 03:38   SOURCE/HIMEMX/
>  296  09-23-2023 03:38   SOURCE/HIMEMX/MAKE.BAT
>81855  09-23-2023 03:38   SOURCE/HIMEMX/HIMEMX.ASM
>  529  09-23-2023 03:38   SOURCE/HIMEMX/MAKEFILE
> - ---
>   116796 18 files
> 
> 
> (You sent your message on 9/23, so that explains the dates.)
> 
> Are you folding the source code into the "exe" zip file to create a package?
> 
> 
> At least for the mirrored files on Ibiblio, I prefer to keep the files
> as provided by the developer (Jerome creates packages, but the Files
> Archive section is a straight mirror.) So I'll re-mirror the original
> releases from GitHub.
> 

Unfortunately, GitHub and GitLab do not preserve timestamps on their own. When 
you checkout a project, the files get stamped with current time. 

The same thing happens when they create a release. The files in the zip have a 
timestamp based on the release creation and not when the file was last modified.

This was one of the primary reasons I wrote the FDVCS.SH script. It maintains a 
simple hash based timestamp data file. Which is updated and managed 
automatically through the script during commits and checkouts to preserve 
correct timestamps. The script also handles several other issues and annoyances 
when using Git.

Side note, The RBE pulls the project from the GitLab archive and uses that 
utility to adjust file timestamps before building the packages that get 
included on the release media.

Anyhow, simply refetching the release zips from Git* won’t correct the 
timestamp issue with the mirrored archives. 

Jerome 


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


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

Re: [Freedos-user] Announcement: lDebug release 6

[Jerome Shidel via Freedos-user]

Hi ecm,

> On Aug 28, 2023, at 3:50 PM, C. Masloch via Freedos-user 
>  wrote:
> 
> On at 2023-08-26 11:30 -0500 , Jim Hall via Freedos-user wrote:
>> Great news, thanks! I've been following the feature request discussion
>> on the tracker, so it's great to see the new version with the cool new
>> changes.
>> There's a lot in this announcement (because so many new features) so I
>> wasn't able to reproduce all of that in the news item for the website,
>> but I did my best. :-)
>> Jim
> 
> Hi Jim,
> 
> I noticed that the file on ibiblio isn't updated yet [1]. Likewise the 
> FreeDOS Software page [2] linked from the website [3]. Though both of these 
> list 1.3 in their pathnames, so I'm not sure what the appropriate action 
> would be. However, I do think that the website [3] should link to the most 
> recent files.
> 
> Browsing ibiblio I found that the freedos/files/repositories/latest/ tree is 
> even more outdated [4]. The ldebug/ subdirectory does have release 5, but the 
> ldebug.zip file (in the latest/devel/ directory) says it is from 2022-04-04. 
> The unstable tree has the same old files [5].

That is my fault. 

Generally, Jim does not update files under the Repositories [R1] directory. The 
files located under that path are not exact “mirrors”. They are “update 
packages”.  For the most part, that section on ibiblio is fully automated and 
basically just requires me to drop a new version of a package into the 
appropriate upload directories. The management software takes care of the rest. 
It performs some version control, creates static web pages, adjusts file system 
links and etc. 

For example, the file you referred to in [5] is just a link to the latest file 
in the ldebug sub-directory. As it turns out, if you were to have visited the 
html for the repository at [R2], it showed the latest version as release_5.zip. 
It also showed an older/alternate version for release 4 as simply ldebug.zip.

This was probably caused be me being lazy and just dropping the updated version 
directly into the unstable repository (at present, the latest repo is just a 
link to the unstable repo). Generally, the management software will catch this 
and adjust the links. But, not always when a full verification of the repo is 
not performed.

This was easy to fix. I just deleted the link [5] to the latest file and told 
the repo to update. It adjusted it to the latest file and updated the html file 
to the appropriate file names.  

> [..]

After correcting the issue with [5], I updated the package on the GitLab 
FreeDOS Archive [R3]. That way Release 6 will be in the next FreeDOS interim 
Build. Then, I uploaded copies to the repos (1.3 and Unstable) on ibiblio. 

I think all looks good now. If you notice any other issues, please let me know.

Thanks,

Jerome


> [1]: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/devel/
> [2]: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/ldebug.html
> [3]: http://freedos.org/source/
> [4]: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel/
> [5]: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/devel/
> [6]: https://pushbx.org/ecm/doc/ldebug.htm#parlist
> [7]: https://pushbx.org/ecm/doc/ldebug.htm#news-r6
> [8]: https://pushbx.org/ecm/download/ldebug/
> [9]: https://pushbx.org/ecm/web/#projects-ldebug
> 

[R1]: http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/ 

[R2]: 
http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/ldebug.html
 

[R3]: https://gitlab.com/FreeDOS/devel/ldebug 



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

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

[Freedos-user] Online Get-together

[Jerome Shidel via Freedos-user]

I think the monthly online get-together is today. 


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

Re: [Freedos-user] How do I change screen resolution?

[Jerome Shidel via Freedos-user]

> On Aug 6, 2023, at 5:48 PM, Mateusz Viste via Freedos-user 
>  wrote:
> 
> On 8/6/23 23:34, Ralf Quint via Freedos-user wrote:
>> DOS is using *text *mode, you just can't select a*graphics *mode and expect 
>> to get text output in that mode.
> 
> BIOS text output functions still work in most graphic modes, hence having a 
> DOS shell running in graphic mode is nothing unusual. Of course problems may 
> arise for text applications that make assumptions about the terminal size or 
> that write directly to VRAM without re-setting a proper text mode.

Generally even with text support by the BIOS in graphics mode, they do not work 
well for the command line prompt. 

Often, there is a lack of text cursor, no scroll support or just very slow 
rendering.

> 
>> And btw,  80x25 character text mode in fact is technically a 640x480 "VGA 
>> mode"
> 
> It's 720x400.

Yep. 

9x16 VGA font, 720x400. However, that 9th bit is just a little bit odd (puns 
intended).

8x16 VGA font 640x400. 

It’s been a while. But if I recall correctly, I think there were some VGA 
tricks that could be done to get 480 raster lines in text mode. Kind of like 
mode X. But, I don’t recall if anything that actually did that for text mode. 
For some reason, I keep thinking about having an 80x30 text mode available. 
But, that could just be 80x28 (8x14 EGA font loaded on VGA hardware). 

There were a lot of such “tricks” that could be done with real VGA hardware. 
Stuff like smooth scrolling in text mode. All part of the VGA specs. Few of 
which are supported by Virtual Machines like VirtualBox.

:-)

Jerome



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

Re: [Freedos-user] How do I change screen resolution?

[Jerome Shidel via Freedos-user]

> On Aug 6, 2023, at 5:25 PM, EdzUp via Freedos-user 
>  wrote:
> 
> I was testing in virtualbox.

Like PC speaker emulation…. I don’t think provides any support for higher 
resolution text modes.




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

Re: [Freedos-user] How do I change screen resolution?

[Jerome Shidel via Freedos-user]

First…

There seems to be a general misunderstanding that DOS only supports 80x25 
columns. While it is possible that an extremely lazy programmer would hard code 
for that resolution, most did not. Even back in the early days the display 
could be in 40x25, 80x43, 80x50 and numerous other text resolutions. Through 
the use of special text mode fonts, most VGA cards could even support different 
font heights producing very unusual display resolutions such as 80x20, 80x16, 
40x22, etc. Therefore it was always a bad idea to hard code support for a 
single display resolution into software. 

Overall, the operating system software provided with FreeDOS, MS-DOS and the 
others work fine in all text mode resolution as long as they have BIOS support. 
 As for other none-base software, you may have mixed results. It just depends 
on skill of the programmer and how much effort they put into that aspect of 
their software.

The real issue lays with BIOS support of text modes over 80 columns. 

Back in the 386/486 days, many cards supported “high resolution” graphics 
modes. Since DOS was still a primary market for such cards, many vendors 
included support for higher resolution text modes in the BIOS (like 132x43). 
Those higher resolution modes generally worked fine under DOS.

As Windows and graphical desktops in general became popular, the card 
manufacturers changed their focus away from text mode. With each iteration, 
fewer and fewer cards included support for high resolution text modes in the 
BIOS.

The newer the video card, the less likely it is to support text modes with over 
80 columns. Out of the older hardware I have laying around, my 486 has the most 
text modes and PentiumPro only has a few extras. But, all the newer stuff 
doesn’t have any. Sure they have way more graphics modes, but none of the newer 
stuff includes any high resolution text modes. 

If you want to see what text video modes are supported by your hardware, try 
LISTVESA. As the name suggests, it will show all the VESA modes supported by 
the card. 


http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/listvesa.html
 


Although VESA is the generally the standard way to discover such modes in DOS, 
some vendors were known to provide access to additional modes using the 
standard BIOS mode change function. Those can be problematic to discover.

For example, DOSBox has a couple such modes. It provides a 132x25 as mode 0x55 
(I think) and mode 132x43 as mode 0x54 (I think). 

A tool to easily change to those standard, additional or VESA modes is the 
VMODE utility. It is part of V8Power Tools. However, earlier versions did not 
support those additional modes that were non-standard (like 0x55). So, make 
sure you have the latest version of V8Power Tools. The newest version can 
switch to standard, additional and VESA modes.

https://fd.lod.bz/repos/current/pkg-html/v8power.html 


:-)

Jerome

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

Re: [Freedos-user] the freedos 1.3 floppy install edition.

[Jerome Shidel via Freedos-user]

Hi Eric,

First… 

The Standard Install Media (CD, USB, LiveCD, etc) require a 386 or better. 
There are several reasons I have mentioned before why those require a 386. But 
for those who may have missed or forgotten why those require a 386, these are 
the primary reasons. USB did not exist on sub-386 hardware. The CD drivers 
available to FreeDOS require a 386. Finally, the primary installer currently 
uses grep (requires 386+) to parse some of the package lists. (eventually, I’ll 
add some stuff to V8Power Tools to remove the grep dependency.) So, the primary 
installer always installs the packages that may requiring a 386. 

Everything else in this message only applies to the Floppy Edition and it’s 
installer.

> On Jul 23, 2023, at 4:47 PM, Eric Auer via Freedos-user 
>  wrote:
> 
> 
> Hi!
> 
>> The CPU detection utility used by the installer has compatibility issues 
>> with some processors.
>> For example, there are some 486 systems that are detected as a 186. This has 
>> been a known issue
>> for a while. Unfortunately, I just have not had the time to resolve that.
>> As a stop gap, if the installer is told the system is less than a 386, it 
>> assumes it is incorrect and
>> installs the 386 package set. So, there should be no need to override the 
>> detected CPU on 386+ systems.
> 
> That will just break the complete install on pre-386 systems. If you
> insist on not trusting your tools, at least ASK the user whether they
> want to override the detection.

During the CPU detection, it works its way up through the processors 8086, 186, 
286, etc. If a test fails, then the maximum level of CPU supported is known. 
However, some post-386 machines fail the 286 tests which stops detection and 
returns a maximum support of 80186. 

Since the CPU detection used by the installer cannot reliably detect some 486 
processors at this time, when the installer is told the system has a sub-386 
processor by the detection program, it assumes that is incorrect and to install 
the packages that require a 386 anyway.

Tools that require a 386 or better of zero use on a pre-386 system and are just 
wasting drive space. Space that is even more precious on older systems. 

For example, the XT we had years ago shipped with a 20Mb hard disk. A FreeDOS 
install that includes the useless 386 programs would fill the entire drive. It 
also wastes the users time installing things they cannot use.

However, until I get around to fixing CPU detection, it is better just install 
everything unless.

The user can override this and force installation of only packages that support 
lesser hardware (like 286, 186, 8086). 

> 
> Or better: If the tool detects a pre-386, make sure that you install
> an 8086 compatible kernel. You can still let the config/autoexec keep
> a boot menu item a la "if you are sure that your CPU can actually do
> it, select this item to try to load EMM386 and HIMEM at your own risk."

The Floppy Edition boots the 8086 compatible kernel. By default it will install 
that kernel. 

It ONLY installs the 386 version of the kernel when the system is known to have 
a 386 or better CPU. 

Overriding the package set has no effect and does not apply to which kernel is 
made active on the installed system. 

A user cannot force activation of the 386 kernel when the CPU detection sees a 
lesser CPU. 

This means that on post-386 hardware that is detected as sub-286, the 8086 
kernel is activated. If the user wants to run the 386 kernel, they would need 
to activate it manually. Since it is included with the 386 package set, that is 
very easy to do. 

> 
>> For systems with less than a 386, you will want to override it to ensure the 
>> 8086 compatible kernel
>> is installed.
> 
> This should be the other way round. If you know what you are doing,
> you MAY override the detection result that you have no 386. If you
> do NOT know for sure, then the installer should NOT give you an
> install which would require 386.

Yes and that is what will happen when I someday find the time and motivation to 
resolve the compatibility issue in CPU detection. 

> Of course if the INSTALLER is sure that the CPU is 386 or newer,
> the whole problem does not occur. So my proposal only annoys a
> small number of people with exotic 386+ CPU, but rescues all the
> users with actual 286 or older CPU or emulators from getting an
> un-usable install due to overly optimistic automated overrides.

This is a non-problem. The installer is very pessimistic. At present, everybody 
gets all files and only known 386+ get the 386 kernel activated.

There are multiple 3rd party Youtube videos with users installing the FreeDOS 
floppy edition on sub-386 hardware. Like on real 8086s and emulators like PCem.

Listening to the users of such hardware, they really only have one complaint 
about the Floppy Edition. It is very slow on pre-386 hardware. 

Those users realize the by 8086 software standards, FreeDOS is enormous and 
most of the install time is 

Re: [Freedos-user] the freedos 1.3 floppy install edition.

[Jerome Shidel via Freedos-user]

Hi,

> On Jul 20, 2023, at 5:47 PM, Karen Lewellen via Freedos-user 
>  wrote:
> 
> Hi folks,
> did the obvious and visited the readme for the download section of freedos.
> While there is indeed a floppy only install, I understand  one should over 
> ride the 286 assumption with a switch  to allow for say a p2 or p3 install?

The CPU detection utility used by the installer has compatibility issues with 
some processors. 
For example, there are some 486 systems that are detected as a 186. This has 
been a known issue 
for a while. Unfortunately, I just have not had the time to resolve that.

As a stop gap, if the installer is told the system is less than a 386, it 
assumes it is incorrect and
installs the 386 package set. So, there should be no need to override the 
detected CPU on 386+ systems. 

For systems with less than a 386, you will want to override it to ensure the 
8086 compatible kernel 
is installed. 

> are the networking packages in this install?

The networking support package provided with FreeDOS only supports a very 
narrow range of network
interface cards. It only includes a couple drivers. Mostly to provide 
networking support for VirtualBox
and VMware. Therefore, the Floppy Edition only installs the networking support 
package on the 
known compatible virtual machines. It does not normally install the network 
support package on real
hardware. 

It is possible to override that and force the installation of the network 
support package. But, it is not 
likely to provide network support “out-of-the-box’ on real hardware. It would 
probably be easier to just 
copy the FDNET package to a floppy and install it using FDINST. 

However, it normally will only attempt to bring up networking in those known 
virtual machines and will
require a command line option to make the attempt on real hardware. If I recall 
correctly, running 
‘fdnet.bat try’ will make try on real hardware. 

> Thanks,
> Karen

Jerome



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

Re: [Freedos-user] gitlab change notifications lack commit messages

[Jerome Shidel via Freedos-user]

Hi Eric,

> On Jul 18, 2023, at 3:31 PM, Eric Auer via Freedos-user 
>  wrote:
> 
> 
> Hi!
> 
> Today I have gotten more than 60 notifications about packet updates,
> NONE of which mentioned why the affected package got updated.


First, sorry about all the notification messages. 

Earlier today, I did some general maintenance on about 1/3 of the project 
repositories.

There are couple reasons for adding a copy of the project’s LICENSE files 
there. First it makes it very easy to find and view. Also, GitLab will display 
the type of license in its button bar. 

I had previously copied a bunch of the LICENSES and today did several more. 
About 125 projects now have a copy of their LICENSE that is quick and easy to 
find. There are still about 250 more that need done.

While doing this, I also updated those projects to the latest version of the 
CI/CD pipeline files. That is what pushes out a “Package Release” when a 
project is updated. However, it creates those based on the LSM metadata Version 
number. If a “Package Release” for that version already exists, it aborts 
without creating a duplicate release. 

Of the roughly 125 projects that were updated today, about half did not have 
existing “Package Release” files. So, ones would have been automatically 
generated by the CI/CD.


> 
> I would REALLY like those notifications to include more details and
> metadata. This would also allow looking up update details in the
> archives later.

I agree. :-)

> 
> In this context I remember that this is a bug in some sort of an
> automated package update script: It lacks the feature to pass ANY
> information about the update reason, so there is none. But this
> would be valuable information, so please improve that process :-)

It is not a bug. But, it is problematic.

With some exceptions, most of the projects live elsewhere and get updated after 
a new version is released. For those, it is not practical to provide a change 
log excerpt or summary of what is new. It would be far labor intensive and time 
consuming.

But, it should be possible to update the CI/CD to include some recent commit 
messages. Possibly just the messages since the previous “Release.”

For the projects that live elsewhere, this would mostly be just ‘updated to 
v1.2.3’ or the occasional general maintenance related messages like ‘added copy 
of LICENSE to project root’

Anything would be better than the current “created by release-ci” message. 

It’s just something I will eventually need to find the time to improve.

> 
> Thank you! Regards, Eric

:-)

Jerome




> 
> PS: Below is an example of an update notification, current style.
> 
>> A new Release v6.00a for unzip was published. Visit the Releases page to 
>> read more about it: https://gitlab.com/FreeDOS/archiver/unzip/-/releases
>> Assets:
>>  - unzip - v6.00a for FreeDOS: 
>> https://gitlab.com/FreeDOS/archiver/unzip/-/jobs/4679018030/artifacts/file/package/unzip.zip
>>  - Download zip: 
>> https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.zip
>>  - Download tar.gz: 
>> https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar.gz
>>  - Download tar.bz2: 
>> https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar.bz2
>>  - Download tar: 
>> https://gitlab.com/FreeDOS/archiver/unzip/-/archive/v6.00a/unzip-v6.00a.tar
>> Release notes:
>> Created using the release-cli
> 
> (the linked release website does not provide ANY details either)
> 
> 
> 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user


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

Re: [Freedos-user] Can FreeDOS Be Installed By Means Of UNIX Commands?

[Jerome Shidel via Freedos-user]

> On Jul 16, 2023, at 10:21 AM, Jay F. Shachter via Freedos-user 
>  wrote:
> [..]
> If the answer to the first question is Yes, then I can continue this
> narrative, otherwise the remainder of this posting is moot.  I copied
> FD13FULL.img to a USB stick, stuck it into the above-described
> computer, and instructed it to boot from the USB device.  The
> installation procedure scares me.  I have already partitioned my disk
> and designated in my mind the logical slice onto which I want to
> install FreeDOS, but the installation procedure on FD13FULL.img
> implies that I must repartition my disk, and I am afraid to proceed,
> lest I irretrievably trash my entire computer.

First... Never install an OS or update an OS on a machine you are not 
willing to rebuild from scratch! I doesn’t matter how careful you are. 
I does not matter how new or great the OS and installer is. Things can
go wrong with the best of them and leave your machine broken or
not even bootable from the internal drives. Backup!

When you boot the from the FreeDOS USB stick, that drive should be
seen by the OS as drive C:. The installer then queries FDISK to see
if a drive D: is present and readable by FreeDOS. If so, it will use that
drive as a target for installation. If not, it will prompt to partition the 
drive.
If the installer is prompting to partition using FDISK, it cannot find a 
hard drive (other than the USB stick) that is suitable to install FreeDOS.

There is an advanced mode for the installer. However, that gets only
limited testing. Therefore, I recommend you install FreeDOS in a 
virtual machine or manually.

> [..]
> then populating the
> newly-created vfat filesystem by means of the cp and unzip commands
> (the packages, I noticed -- and there is a huge number of them -- are
> zip files, but there are also some files that are fundamental to
> system that are already present without having to be unzipped, which I
> envision simply copying over).  

That is not really going to work very well. The zip archives are packages. 
The contain various directory aliases that get remapped during package 
installation. While many could just be unzipped and used, others will be
in directories different from how they are configured and will not function
properly. 

You have multiple options on how you can proceed. 

1) You could run the installer in advanced mode. Based on how your 
machine is setup, this WILL most likely hose your system anyway.

2) You could install FreeDOS to a virtual machine like VirtualBox or 
QEMU. 

3) You could do a hybrid install into DOSBox. The installer defaults to 
hybrid on that virtual platform. There are DOCs and Youtube videos 
on how to do type of install. The benefit is having direct and easy
access to the DOS filesystem from the host. There are some drawbacks.
It is best suited for developers. 

4) Install manually. After setting up a partition and it’s boot sector, I would 
proceed one of two ways. I would either install FreeDOS into a VM’s 
hard drive using a flat disk image, then copy the files to the hard disk
partition. Or…. copy over the kernel and command. Then unzip the 
FDNPKG and FDIMPLES packages. If you place their files in the proper
directories, adjust the FDNPKG.CFG file and configure a few environment
variables, you could then use them to install all the other packages. 

Jerome




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