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

Re: [Freedos-user] failing to create bootable install media (or at least boot from it)

[Jerome Shidel]

Hi, 

> On Dec 13, 2022, at 12:14 PM, Roderick Klein  wrote:
> 
> On 13-12-22 17:26, Jerome Shidel wrote:
>> Are you certain that the machine you are trying to install FreeDOS is not 
>> UEFI only and supports BIOS (Legacy) boot? And, that is enabled in the BIOS 
>> settings?
>> 
>> Most modern Linux installers can boot both ways. Unfortunately, UEFI is not 
>> an option for FreeDOS at present.
> 
> Well will it ever be an option possible to implement UEFI for FreeDOS?
> 
> I personally think its not possible The issue is that UEFI is mostly the same 
> as a BIOS. But one of the issue's is that during boot a UEFI loader calls 
> ExitFromBootServices() if you could keep these services active...  But that 
> is not possible I think. FreeDOS depends on a lot of BIOS calls.
> 
> You MIGHT be able to write a UEFI loader that provides BIOS services to 
> FreeDOS with SeaBIOS. But there is much code involved. You would effectively 
> write half a VM more or less...
> 
> Roderick
> 

Correct. It would be a good deal of work to boot FreeDOS that way. 

Alternatively, it might be easier to just create a custom “Thin” version of 
linux to host a VM using QEMU or DOSBox. Then run FreeDOS under that VM. 
Although performance would not be as good as running on bare metal, it solves 
several other issues. For instance, network and sound cards could be supported 
through the linux host providing generic support under DOS.  

Although less work, that is not a small task to create or maintain either. They 
are the primary reasons there is only BIOS support at present and for the 
foreseeable future.

Maybe someday. But, not likely anytime soon.

:-)

Jerome




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

Re: [Freedos-user] failing to create bootable install media (or at least boot from it)

[Jerome Shidel]

> On Dec 13, 2022, at 11:46 AM, Walter Vermeir  wrote:
> 
> p 13/12/2022 om 17:26 schreef Jerome Shidel:
>> Are you certain that the machine you are trying to install FreeDOS is not 
>> UEFI only and supports BIOS (Legacy) boot? And, that is enabled in the BIOS 
>> settings?
>> 
>> Most modern Linux installers can boot both ways. Unfortunately, UEFI is not 
>> an option for FreeDOS at present.
> 
> 
> No, I am not. I assumed 'If I can boot Linux install media then it must also 
> work for FreeDOS'. I know 'secured boot' is disabled, I get that message in 
> Bios.  But the USB media listing starts with UEFI , so yes, that is the 
> problem.
> 
> So at least that makes sense now.
> 
> The new old computer I bought to use for FreeDOS also has it's challenges. It 
> does not seems to support 'boot form CD-rom'. And the diskette station is 
> broken.

Did you try to boot the LegacyCD or the LiveCD? 

Besides the LiveCD providing a Live FreeDOS Environment at boot, there are some 
technical differences between how each boot. There is a narrow window of 
machines that can boot using the method on the LegacyCD but not boot the 
LiveCD. 

As for installation, they use the same installer and install the same OS files.

> 
> Because I have a module to replace the internal hard disk with an SD-card and 
> I remembered I still have a computer in my garage I had forgotten I probably 
> can install FreeDOS on an SD-card with that computer. And then install that 
> SD-card as hard disk in the old laptop.
> 
> Walter
> 

That should work. 

You also have a couple other options.

For example, the installer supports OEM install mode. Basically, you can use a 
tool like DD under linux and just write the Full USB to that device. Then, slap 
the drive into the computer and boot. You will be able to create a new 
partition and install the OS to that. Once the OS has been installed, it will 
switch booting over to the new partition. Basically, that leaves the original 
partition as a Recover Partition and source for package installation and 
removal (without needing to insert the CD).

There are other methods as well. Videos on Youtube show installing to a VM and 
coping that to a drive. And other ways as well.

:-)

Jerome



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

Re: [Freedos-user] failing to create bootable install media (or at least boot from it)

[Jerome Shidel]

Are you certain that the machine you are trying to install FreeDOS is not UEFI 
only and supports BIOS (Legacy) boot? And, that is enabled in the BIOS 
settings? 

Most modern Linux installers can boot both ways. Unfortunately, UEFI is not an 
option for FreeDOS at present.




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

Re: [Freedos-user] UDVD2: Invoking STOP AUDIO twice should first pause, then stop audio, as some games expect

[Jerome Shidel]

Hi, 

I’ll reply to the GitLab Issue as well...

> On Dec 10, 2022, at 2:55 AM, Eric Auer  wrote:
> 
> [..]
> I'd say fixing it should be straightforward, but would unfortunately add 
> quite a bit of complexity in that bit of the code, which right now is elegant 
> in its simplicity. I could have a look at it over the weekend. Are MRs 
> accepted for this?

As the original author of UDVD2 not longer provides updates to us for the 
program, merge requests that improve the driver can be accepted. 

Jerome

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

[Freedos-user] FreeDOS Interim Builds

[Jerome Shidel]

Hi everybody,

I’m not sure if everyone is aware or not. So, I figured I mention this here…

We’ve been releasing FreeDOS Interim Builds for about 6 months now. I build 
them on the 1st of the month and push them up to the server for testing. These 
builds include the latest versions of our packages and the current state of the 
OS. These are not OS point releases. These builds are mainly for testing 
purposes and things can change a lot from one build to the next. 

We can always use more eyeballs to test things and provide feedback. If you 
interested in giving them a whirl, just head over to 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 
 
and grab it. 

Occasionally when testers visit the server, they will see an old version. This 
is in part the servers stated cache settings and in part the web browser used.  
So, you may need to force it to refresh the page when checking for a new 
version. 

When possible, any bugs or issues should be reported through the FreeDOS 
Archive on GitLab at https://gitlab.com/FreeDOS  . 
That way we can keep track of them. If you are not a member on GitLab, you can 
also use the link on the https://freedos.org/bugs/  
page to email any issues.

:-)

Thanks, 

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

Re: [Freedos-user] Freedos 1.3

[Jerome Shidel]

Hi, 

> On Oct 17, 2022, at 10:43 AM, Dale E Sterner  wrote:
> 
> 
> I recently tried to download Freedos 1.3 and had a problem.
> I used XPsp2 ; the download failed with a " unable to complete
> secure transaction".  Your download source is too restricted.
> 
> 
> 
> cheers
> DS


This is probably a result of Windows XP not supporting the minimum required 
protocols to establish a secure connection. Luckily, you can connect to the 
official download server without establishing a secure connect at the same url 
using just http instead of https. For example, 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ to 
download one of the releases or interim test builds.

:-)

Jerome

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

Re: [Freedos-user] can't see DVD reader

[Jerome Shidel]

> On Sep 18, 2022, at 2:53 PM, Glenn Holmer via Freedos-user 
>  wrote:
> 
> [..]
> There's a script that gets called from FDAUTO that tries several drivers
> -- why wouldn't that work? And why did it work during install?

There CD also has an ELTORITO.SYS driver it will try to use. For several, this 
driver is not included in the install process. 

One reason… I’ve been told this driver should only be used when booting from 
CD/DVD. However, some users have reported "it worked fine for me” when booting 
from the hard drive. So, you could try copying that to the hard drive (same 
location as UDVD2.SYS). The CD initialization script will notice the driver and 
try it if the others fail to start/work. 

Also, there are a couple other drivers that we cannot distribute for licensing 
reasons. However, they are free and easy to find online. If any of those are 
present the CD initialization will try those first. To see a list of what 
drivers are supported and the order they are attempted, run “CDROM.BAT help”

:-)

Jerome 


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

Re: [Freedos-user] djgpp bash and autoconf for dos, new gcc

[Jerome Shidel]

Hi, 

> On Sep 9, 2022, at 7:21 AM, Eric Auer  wrote:
> 
> 
> Hi! As Paul has asked for a DOS version of BASH,
> 
> http://www.delorie.com/pub/djgpp/current/v2gnu/
> 
> has version 4.2 of that. The zip unfortunately is called BSH...
> because the website unnecessarily limits itself to 8.3 names.
> Note that ACNF... in the same directory is autoconf :-)

Although they are DJGPP versions, would they not be better as their own set of 
packages, like BASH and AUTOCONF. 
Not packages like DJ_BASH and DJ_ACONF? 

Also, under the current groups… BASH as a UTILITY and AUTOCONF as a DEVEL tool?

I can go ahead and create PACKAGE projects for them in the GitLab Archive. But, 
who wants to put those new packages together? 

Also, it will be entirely up to Jim wether or not they are included on the 
Interim Test build or Next OS release. (probably on a BonusCD)

This brings up another issue… 

In the previous T2209 build, at 663.2MB the BonusCD exceeds the standard 
recommended size of 650MB. It is still under the absolute maximum of 700MB. So 
fairly soon, we will either need to weed out some stuff from the BonusCD or 
have multiple BonusCD’s (like one for Devel, Gui, etc). The RBE already knows 
how to make multiple BonusCDs. So whatever gets decided, it will be easy to do. 

:-)

Jerome

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

Re: [Freedos-user] Ré : Networking FreeDOS 1.3 on QEMU

[Jerome Shidel]

> On Sep 15, 2022, at 11:58 AM, Ralf Quint  wrote:
> 
> On 9/15/2022 2:44 AM, tom ehlert wrote:
>> 
>>> It seems I have broken packages - got networking now but having a lot
>>> of problems otherwise. Any easy way to square it all up again?
>> 
>> 42
>> 
> +1
> 
> Ralf
> 
> (and now, that doesn't make it 43  )

( Maybe... That will require some Deep Thought... I’ll get back to you on it in 
a few million years. )

> 
> 
> 
> ___
> 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] Minor Update to PGME

[Jerome Shidel]

> On Sep 8, 2022, at 4:52 PM, Liam Proven  wrote:
> 
> On Sun, 21 Aug 2022 at 15:57, Jerome Shidel  wrote:
>> 
>> Just letting you know, I spent a little time this morning and did a minor 
>> update to PGME.
>> 
>> Mostly, it improves compatibility with mouse drivers other than CTMouse.
>> 
>> For example, the old MS-DOS 6.x mouse driver should be detected and usable 
>> now.
> 
> I am off work with COVID. :-(
> 
> However, with what little powers of concentration are left to me, I've
> been poking at my little DOS-related projects.
> 
> I tried the new PGME.
> 
> No difference, I'm afraid. :-(
> 
> I did `ctmouse /u` to unload it, then loaded c:\apps\msword\mouse
> 
> This works fine in FreeDOS Edit, but PGME detects no mouse.

Hmmm, I just re-verified PGME version 8/21/22 under VirtualBox, running MS-DOS 
6.22 with its MS-MOUSE Driver v8.2. Please verify, you are running the latest 
version of PGME. Under the default theme, the Version is displayed in the upper 
right of the main window. Depending on how you installed the latest version, it 
is possible there are two copies (old and new) of PGME on your drive.

If this does not remedy the issue you are experiencing, there are a couple 
other things to look at to find out what may be going on.




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

Re: [Freedos-user] FD-NLS, was Announce: VMSMOUNT 0.6 preview release

[Jerome Shidel]

> On Sep 6, 2022, at 10:07 AM, Eduardo Casino  wrote:
> [..]
> After any bug fixes or you feel it is ready, we can merge that into the 
> "master”  branch at GitLab for the eventual next FreeDOS Release.
> 
> Great, thanks :)

+1

> 
> I've seen that some of the translations are maintained in their own project 
> at https://gitlab.com/FreeDOS/OS/fd-nls/-/tree/master/vmsmount/nls 
> . The EN, ES 
> and NL ones are also in my repository. There are a couple of new messages in 
> this release, I'm opening a merge request for the updates.

It is much easier for the translators to work from a single location for all of 
the different programs. So, all of that work is done on the FD-NLS project on 
GitHub at https://github.com/shidel/fd-nls  . 
The version at GitLab at https://gitlab.com/FreeDOS/OS/fd-nls 
 is an automatic mirror of the GitHub 
project.

The FD-NLS project was started long before we decided to open the FreeDOS 
Archive on GitLab. Eventually, we will probably move it’s home from GitHub to 
GitLab. But, we don’t want to uproot the translators to get them to switch 
over. So at least for the foreseeable future, the FD-NLS project will stay over 
on GitHub and be mirrored by GitLab. At present, any NLS contributions should 
be submitted to the GitHub repository. 

:-)


Jerome



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

Re: [Freedos-user] Networking FreeDOS 1.3 on QEMU

[Jerome Shidel]

Hi, 

> On Sep 6, 2022, at 11:43 AM, Phil Reynolds  
> wrote:
> 
> I had FreeDOS 1.2 working quite nicely, networking included, on qemu,
> but I am lost as to (a) how I originally achieved it (b) how I might do
> likewise with 1.3 - is there any specific documentation I can follow?

By default during the boot process, FDAUTO runs "FDNET.BAT start” 

The “start” option tells FDNET to only run on known compatible virtual machines 
(ie. VirtualBox and VMware).

You will need to configure QEMU with an appropriate network card. I don’t use 
QEMU much to run DOS. Can’t help you there.

Then if it is one of the Network cards supported by FDNET, you can just remove 
the “start” option.

Otherwise, you could create a custom batch called FDNETPD.BAT that knows how to 
configure your packet driver. You would then place both your custom FDNETPD.BAT 
and Packet Driver in the FDNET directory. Then running FDNET should bring up 
your networking. This prevents the need for customizing the FDCONFIG and/or 
FDAUTO every time you reinstall, upgrade the OS or update packages. 

Hope that helps at least a little.

:-)

Jerome

> 
> -- 
> Phil Reynolds
> mail: phil-free...@tinsleyviaduct.com
> Web: http://phil.tinsleyviaduct.com/
> 
> 
> ___
> 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] Announce: VMSMOUNT 0.6 preview release

[Jerome Shidel]

Hello,

> On Sep 5, 2022, at 5:23 PM, Eduardo Casino  wrote:
> 
> Hi,
> 
> I've made a preview release of the upcoming VMSMOUNT 0.6 version, so that 
> anyone who wants to can try it and report any feedback. I'm not adding more 
> features to this release, I'll just fix any bugs that come out and make it 
> final.
> [..]
> https://github.com/eduardocasino/vmsmount 
> 
> 
> Cheers,
> Eduardo

I created a “unstable” branch for VMSMOUNT 0.6 preview version in the FreeDOS 
GitLab Archive. 

https://gitlab.com/FreeDOS/net/vmsmount/-/tree/unstable 


When they exist, “Unstable” branches in are used automatically by the RBE when 
creating FreeDOS Interim Test Builds.

Next month, it will automatically include the preview version of VMSMOUNT in 
T2210. 

After any bug fixes or you feel it is ready, we can merge that into the 
"master”  branch at GitLab for the eventual next FreeDOS Release.

:-)

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

Re: [Freedos-user] Minor Update to PGME

[Jerome Shidel]

> On Aug 21, 2022, at 4:01 PM, Liam Proven  wrote:
> [..]
> Oh hurrah! Thank you.

Your welcome. :-)

In no particular order, here are a couple tips I don’t think are in the DOCS or 
help…

When you change text in an edit field, you must confirm the change by pressing 
enter. Otherwise, the text will revert. That is different than most other UI’s 
which may keep the change when you click outside the edit field or use another 
method to finish editing. This tends to give a lot of users problems and I’ll 
probably change it to be more like what users expect someday. 

(These are just the default Keybindings. They can be changed and may be 
different in other languages.)

ALT+H will bring up semi-context aware help. 
ALT+H used while in help, brings up Help on Help + current help.

ALT+Q to quit.
ALT+F to search.

ENTER / RETURN to launch a program. (Or click Execute, or just double click the 
item)

On the main screen, UP and DOWN keys change the selected Program Menu Item. 
Using SHIFT + UP/DOWN will change the menu.

Generally, you should launch it using the PGM.BAT helper (installed in 
%DOSDIR%\BIN). That will allow PGME to use the "free all memory” option and 
complicated launch processes. Otherwise, PGME will always have a roughly 10k 
memory footprint and be stuck doing only simple launches.

When you run PGME from the command line, you can have it jump to menus or even 
specific items (spaces are ignored when searching). For example…

pgm games
pgm floppybird
pgm what’s new

To use the “Disable CPU Cache” for running really old programs. The SLOWDOWN 
package for FreeDOS needs installed. I think it is installed automatically 
which FULL in FreeDOS 1.3.

There are also ways to have menus and items more or less automatically appear, 
disappear, change, etc.  

:-)

Jerome





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

[Freedos-user] Minor Update to PGME

[Jerome Shidel]

Hi all,

Just letting you know, I spent a little time this morning and did a minor 
update to PGME. 

Mostly, it improves compatibility with mouse drivers other than CTMouse.  

For example, the old MS-DOS 6.x mouse driver should be detected and usable now. 

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


:-)

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

Re: [Freedos-user] CD drive always gets the letter H: - can't change

[Jerome Shidel]

> On Aug 2, 2022, at 8:14 PM, Eric Auer  wrote:
> 
> 
> Hi!
> 
> To be a bit more productive than just complaining, how about this?
> 
> /* Automatically partition the selected hard drive */
> void Automatically_Partition_Hard_Drive()
> 
> could be patched using:
> 
>> --- FDISKIO.C.bak2022-08-03 02:10:06.914145715 +0200
>> +++ FDISKIO.C2022-08-03 02:10:27.141382832 +0200
>> @@ -110,7 +110,7 @@
>> (pDrive->total_head+1)*
>> pDrive->total_sect / 2048; */
>>   }while(  (pDrive->ext_part_largest_free_space > 0)
>> -&& (Determine_Drive_Letters()<'Z') );
>> +&& (Determine_Drive_Letters()<'D') );
>> }
>> }
>> 
> 
> That would at least somewhat limit the damage done by /AUTO :-)
> 
> One could also change the following part to NOT use type 6:
> 
> /* Create a primary partition...if the size or type is incorrect,  */
> /* int Create_Primary_Partition(...) will adjust it automatically. */
> Determine_Free_Space();
> Set_Active_Partition(Create_Primary_Partition(6,2048));
> 
> By using FAT32, the whole extended/logical partition creation
> hassles could be dropped, making a FAT32 variant of /AUTO much
> simpler than the original. Both could co-exist with different
> command line options in a patched FDISK, e.g. /AUTO32 and /AUTO.

Instead of changing the existing behavior, it may be better to just create 2 
new switches.

/AUTO16 - Create one partition, as large as possible, up to 2GB.
/AUTO32 - Create one partition, as large as possible, using entire drive 
(probably). 

Or possibly even better, 

/AUTOMAX n - limit number of created partitions to n.
/AUTO32 - Create FAT32 partition(s).

Maybe even an,

/AUTOSIZE n - to specify a maximum size of automatically created partition(s). 

> 
> Eric
> 

Just a thought. 


:-)

Jerome



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

Re: [Freedos-user] CD drive always gets the letter H: - can't change

[Jerome Shidel]

> On Aug 2, 2022, at 6:26 PM, Eric Auer  wrote:
> 
> A word to the install wizard app, if it were a person:
> 
> That was a great way of shooting yourself in the foot :-D
> 
> Running out of drive letters by trying to avoid FAT32. In 2022.

I’m getting kind of tired of explaining this… But, he we go once again.

The Installer has NO way to tell FDISK to auto partition the drive as a single 
partition. FDISK automatically breaks it into 2GB sections. If there was a way 
to tell FDISK just use the entire drive, the installer would have it create a 
single large FAT32 partition. Or, possible ask if the user wanted to use the 
whole drive or partition it manually.

Until someone decides to improve FDISK to support such operations, the current 
installer is limited in what can be done regarding partitions. 

Jerome

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

Re: [Freedos-user] PGME [was: DOSshell replacement]

[Jerome Shidel]

> On Jul 31, 2022, at 12:06 PM, Liam Proven  wrote:
> 
> On Sun, 31 Jul 2022 at 00:08, Jim Hall  wrote:
>> 
>> There's PGME (Program Manager Eternity) which we include in FreeDOS.
>> It's on the LiveCD under Applications. It gets installed to C:\PGME
> 
> OK, so, now I have tried this. I have encountered quite a few issues
> with it, unfortunately, and I don't think it will be an answer for me
> either.
> 
> I know Jerome is a regular poster here, but I do not want to cause any
> offence or hurt. So, here are a few of the issues; should I open
> GitHub issues for these, or are they not things you are interested in
> changing?

I’m generally fairly thick skinned. :-)

> 
> * CTMOUSE driver regularly goes crazy on hardware (maybe because my
> test machines have both a trackpad and a trackpoint); PGME can't be
> operated with keyboard alone. That is a deal-breaker for me.

Actually, the primary screen can be operated strictly by using the keyboard. 
(more on that below)

At present (by default), sub screens and dialogs for things like adding menus, 
items 
and changing settings really needs a mouse to edit/navigate.

PGME is fully customizable. It uses events to trigger all actions. These events 
are bound
to internal commands and the commands can be bound to any keystroke. In other 
words, 
with a lot of knowledge, fiddling and customizing (which not easy and I don’t 
actually 
recommend attempting it), nearly anything PGME can do can be bound to a 
keystroke.

> * I replaced CTMOUSE with the Microsoft mouse driver. This works fine
> and works in FreeDOS Edit etc. PGME seems not to detect it, though.
> The pointer won't move.

Intersting. I’ll need to look into that when I have the spare time. But, I’m 
kind of swamped with other things. So, you should definitely file a bug
report so I don’t forget to look into it.

> * No way to move between the list of entries on the current menu, on
> the left, and the list of menus on the right, with the keyboard.

Actually, that is not necessary. By default, UP, DOWN and other navigation 
keys are bound to the list of programs and move the highlight bar up and down.

Using SHIFT + UP/DOWN are bound to the list of menus. 

> * I read left-to-right. Most Roman/Cyrillic/Greek alphabet users do.
> ;-) I feel the categories should be on the left and menus on the
> right. I can't see any option to rearrange them.

Not an issue. :-)

PGME is fully customizable. In fact, it includes a theme called
CAVEMAN that does exactly that. However, that theme also
changes the colors. But, you could easily modify those to your
own liking by editing the CAVEMAN.THM file.

If you really dig into the themes and read that section of the DOCS,
you could move all kind of stuff around. For example, hide the clock and
put the menu list above the menu. Or, whatever. 

:-)

> 
> * I need to be able to move between those 2 panes with left and right,
> or Tab, or both. With highlighting of which has keyboard focus,
> perhaps by changing the colour of the box

(Covered above)

> 
> * I need to be able to edit the menus with the keyboard, and see what
> the keystrokes are, ideally in the traditional way by underlining the
> active letters.

Along with a couple other things, that is part of the underlying and completely 
custom object oriented framework that powers PGME. Unfortunately since most
users prefer a mouse, it has not been a priority and is something I have not 
got 
around to yet. 

On a side note, when editing text… PGME requires you to press ENTER. Otherwise,
it will revert the text assuming you changed your mind. While in and of itself 
it is not
a bad practice, it is very different from most UIs and sometimes gives new 
users a lot 
of problems (wondering why won’t it accept their changes). At some point, I 
will probably
make it behave more like other UIs.

> * I suggest fonts, sound effects. etc off by default, but maybe that's just 
> me.

You cannot really turn off PGME fonts. PGME does not use the DOS font or 
codepage system. 
There are a couple reasons for that. 

First, even though it runs in text mode, you can have a very large (like 8x24) 
font. 

Second, by design, it is intended for users to launch things and never need to 
return to DOS. 

Just an example. You could use PGME on a KIOSK. Have all menus locked and read 
only, Exit to DOS prohibited, irrelevant things like (edit button) hidden and 
Menu entries that switch languages, fonts, keybindings to what the user wants. 
Including language specific menu items and much more. 

On a personal note, I have a some really old games. So when PGME launches 
those, it tells the computer to run slowly and configures the audio card mixer 
to turn up the microphone (inside the case next to the pc-speaker) and launches 
the game. Afterwards, turns off the microphone and speeds the machine back up. 

> 
> ===
> 
> PGME let me find some other programs I didn't know about.

PGME has several default menus included specific to FreeDOS. 

Re: [Freedos-user] Creating a minimal freeDOS bootable image that runs a simple text editor

[Jerome Shidel]

Hi,

> On Jul 14, 2022, at 12:28 AM, Rugxulo  wrote:
> 
> Hi,
> 
> On Wed, Jul 13, 2022 at 10:20 PM Jerome Shidel  wrote:
>> 
>>> On Jul 13, 2022, at 2:29 PM, Rugxulo  wrote:
>>> 
>>>> FDAUTO.BAT
>>>> ——
>>>> set DOSDRV=C:
>>> 
>>> If you're using FreeCOM and already in the root directory from bootup, try 
>>> this:
>>> 
>>> REM ... should be "C:\" ...
>>> set DOSDRV=%_CWD%
>> 
>> Actually, if you are going to set an env for the drive (like in the small 
>> example), you probably just want the drive portion (C:) and not a path (c:\).
>> 
>> This allows dropping small batch files somewhere in the path with cluttering 
>> the PATH setting. For example, you can put a MYGAME.BAT in the DOSDIR. 
>> Something like…
>> 
>> @echo off
>> %DOSDRV%
>> cd GAMES\GAME42
>> QLUE.COM
> 
> Don't forget that FreeCOM also supports "cdd" (IIRC, this will also
> work for fully-qualified filenames!):
> 
> * https://help.fdos.org/en/hhstndrd/cdd.htm 
> <https://help.fdos.org/en/hhstndrd/cdd.htm>

Yep. 

Also, there is PUSHD and POPD. Those can work with full DRIVE+PATHs as well. 
Then afterwards, return to the original directory.

Depending on what exactly is required, there can be several ways to accomplish 
it.

:-)

Jerome

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

Re: [Freedos-user] Creating a minimal freeDOS bootable image that runs a simple text editor

[Jerome Shidel]

Hi,

> On Jul 13, 2022, at 2:29 PM, Rugxulo  wrote:
> 
> Hi,
> 
>> On Mon, Jul 11, 2022 at 6:09 AM Jerome Shidel  wrote:
>> 
>> FDCONFIG.SYS
>> 
>> !LASTDRIVE=Z
> 
> You probably don't actually need that many drives, I'd suggest "G" or
> "P" instead (to save RAM).
> 
>> FDAUTO.BAT
>> ——
>> set DOSDRV=C:
> 
> If you're using FreeCOM and already in the root directory from bootup, try 
> this:
> 
> REM ... should be "C:\" ...
> set DOSDRV=%_CWD%
> 

Actually, if you are going to set an env for the drive (like in the small 
example), you probably just want the drive portion (C:) and not a path (c:\).

This allows dropping small batch files somewhere in the path with cluttering 
the PATH setting. For example, you can put a MYGAME.BAT in the DOSDIR. 
Something like…

@echo off
%DOSDRV%
cd GAMES\GAME42
QLUE.COM

However, since the original question is about a single use setup for a text 
editor. Probably, do away with setting a drive variable and just do…

set DOSDIR=%_CWD%FREEDOS
set PATH=%DOSDIR%\BIN

Or, do away with such things, shrink the env size and use full paths in the 
FDAUTO.

Lots of options.

:-)

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] Creating a minimal freeDOS bootable image that runs a simple text editor

[Jerome Shidel]

Hi, 

My 2 cents worth…

Like Mateusz mentioned… There is no guarantee that the BIOS will permit disk 
writes to a booted USB stick. However since you intend on supporting only your 
personal machines, you can just do a quick test and not worry about that. A 
quick and dirty test would be to burn the FreeDOS install media to USB, boot 
it, create a file, reboot and verify it still exists. 

Assuming you can write to a booted USB… I’d keep using FreeCOM and just start 
with a clean FDCONFIG and FDAUTO and minimal drivers. Probably, very 
conservative memory and a mouse driver. Then for FDAUTO, just run your editor. 
However after the editor, perform a system shutdown. 

Probably something like this…

FDCONFIG.SYS

!COUNTRY=001,858:\COUNTRY.SYS
!LASTDRIVE=Z
!BUFFERS=20
!FILES=80
DOS=HIGH
DEVICE=\FREEDOS\BIN\HIMEMX.EXE
SHELL=\COMMAND.COM \ /E:1024 /P=\FDAUTO.BAT

FDAUTO.BAT
——
@echo off
set DOSDRV=C:
set DOSDIR=%DOSDRV%\FREEDOS
set PATH=%DOSDIR%\BIN
set TEMP=%DOSDRV%\TEMP
CTMOUSE
EDIT
FDAPM POWEROFF
ECHO System failed to power off. Please turn it off manually now.


However if you need CD/DVD support or some other functionality provided by the 
normal FreeDOS boot configurations, I would just add the specifics to the end 
of the normal FDAUTO.BAT file.

:-)

Jerome

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

Re: [Freedos-user] FD13 floppy installation attempts

[Jerome Shidel]

Hi,

> On Jun 27, 2022, at 6:47 PM, Pierre LaMontagne  wrote:
> 
> 
> First of all, I think FreeDOS is an outstanding replacement for the 
> discontinued MS-DOS!!!
> 
> I've been a happy camper & been a big fan of FreeDOS since v1.1. I use it 
> mainly on my 'ancient' PC. This PC has been around since the late 1990s. I  
> built it myself. It has an Intel Pentium III 450mhz CPU on an Asus P3b-F 
> motherboard with one 256kb DIMM for RAM & VGA graphics on an AGP-4x video 
> card (I think it's an NVIDIA 6200 GPU???).
> 
> I usually use Linux (Ubuntu 20.04). It's on  another OLD, but not quite as 
> old PC, (about 10 years old) ... I've become a big fan of freeware!
> 
> My 3rd PC (about the same age as the Linux PC) has Win 10 on it. I rarely use 
> it anymore especially with the Win 11 release. ("I seen the writing on the 
> wall" with Win11)
> 
> I've recently wanted to upgrade my oldest PC as much as I could which 
> includes going  from FreeDOS 1.1 to FreeDOS 1.3. I dowloaded the packages 
> that I thought I needed.
> 
> I haven't tried it, but I'm pretty sure this oldest PC of mine won't boot 
> from a CD. So I extracted the legacy ZIP which contained a floppy boot image 
> & a CD ISO file. I then tried to extract the floppy IMG file to a 
> new-never-used 1.44 mb floppy in hopes to later create a boot floppy in 
> Ubuntu, but I couldn't even get that far because the floppy image file 
> wouldn't fit on the new 1.44mb floppy. I then tried using the DVD drive to 
> put the floppy IMG file on it but, writing to the DVD drive in a DOS 
> environment won't work (at least not with my limited knowledge)...
> 
> So now I'm stuck & don't know what else I can do. :(
> Any suggestions/help???


First, do not extract the files from Floppy Boot Diskette Image for the 
LegacyCD and try to use those files to make a boot diskette. While it can be 
done, it is tedious and error prone. 

What you want to do is write the Boot Diskette Image to the Floppy Device. So, 
what you want to do is the following…

1) insert the Floppy Diskette you want to overwrite. (Either an old school one 
using the floppy controller or even a newer USB floppy drive)

2) figure out the the device name (probably /dev/floppy or /dev/floppy0).

3) unmount the floppy device. But, do not eject the diskette.

4) as superuser write the image file to the floppy device. example: “sudo dd 
if=FD13BOOT.img of=/dev/floppy” You can add options for block size and count. 
However, it usually works fine without them. WARNING: make sure it is actually 
the floppy and not a hard drive or other device. If you write it to the wrong 
device, you will destroy the filesystem on that device. 

Depending on the speed of your floppy drive, it will probably take 5-7+ minutes 
to write the image. But once finished writing, your done. You will have a 
Floppy Boot Diskette for the CD ROM. 

:-)

Jerome


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

Re: [Freedos-user] Need help with networking

[Jerome Shidel]

Also, if your connection is just to a Linux box.

EtherDFS works great. 

You do need to run it’s server on the linux Box.

> On Jun 18, 2022, at 2:26 AM, Eduardo Casino  wrote:
> 
> 
> Hi,
> 
>> I would very much like to get the networking setup so that I can create 
>> shares to be able to exchange files with the host machine, but for some 
>> reason ‘net’ and related commands don’t seem to be present.
>> 
> 
> You might want to give vmsmount a try, a free implementation of VMWare's 
> shared folders protocol. It is also included in the "Networking" category in 
> the CD or you can download it from the FreeDOS package repository:
> 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/vmsmount.html
> 
> Eduardo
> ___
> 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] DOS Fonts

[Jerome Shidel]

Like Aitor mentioned there are some basic tools for it. (Like GNU and Display)

Also, there are some others.

V8PowerTools VFONT.COM can load the normal raster fonts (like GNU load font) 
temporarily. When the video mode is reset (or changed) the fonts will revert 
back to their previous state.

ImgEdit can edit standard raster fonts and always uses that file format for 
8x?? size fonts. Fonts wider than 8 bits use a different format and are for the 
“Danger Engine” and graphics modes only.

PGME uses a different font file format and includes its own editor (EFNTDSGN). 
However, it also comes with utilities to convert from its format to/from raster 
format. It also includes tools to temporarily load them. It even includes a 
utility that can turn the font into a stand alone executable TSR that keeps the 
font persistent for mode resets and changes.

There are other tools as well.

:-)

Jerome





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

[Freedos-user] SBPmixer

[Jerome Shidel]

Hi All,

Today, I released the NASM port of my ancient (Turbo Pascal) Sound Blaster Pro 
(and compatible) Mixer driver. It is a program-loadable device driver for 
adjusting mixer settings like volume levels. The driver can also be compiled 
into executables. The release also includes a 2.5K command line program for 
viewing and adjusting mixer settings. If you only want to use the command-line 
tool, you can just delete the driver file. The utility has the driver compiled 
into it and does not need or use the external driver file. 

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


:-)

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

Re: [Freedos-user] SoundBlaster volume control for the distro

[Jerome Shidel]

> On May 31, 2022, at 4:06 AM, Eric Auer  wrote:
> 
> 
> Hi! I just noticed that I had mailed you off-list,
> but given that you say the release is not official
> yet, how can we get the news back to the public
> freedos-user list where e.g. Stas can see it? :-)
> 
> Eric

Stas was following the GitHub discussion. 

I let him know through that channel.

However, no reason to not post the information here. 

There may be some changes I want to make first. 

So, I haven’t official released it yet. 

In the meantime, it’s available if someone wants compile and use it.

:-)

Jerome

> 
> 
> 
>> Hi,
>>> On May 30, 2022, at 7:23 PM, Eric Auer  wrote:
>>> 
>>> 
>>> Hi!
>>> 
> It seems our distro has no volume control or mixer tool yet,
> so it would be nice to add one. We can start with the command
> line tool SBMIX, although something with Text-graphical user
> interface would of course be even more cool :-)
> 
> https://www.bttr-software.de/products/sbmix/
> 
> Thanks! Regards, Eric
 Well, there are several such mixers available with suitable licenses.
 I wrote one myself back in the early 90’s. I recall it was a painful 
 task...
>>> 
 I suspect the BTTR version is probably better.
>>> 
>>> The BTTR version can set mixer / volume parameters from the command line, 
>>> which can be nice :-) However, it would be cool to also have an interactive 
>>> mode, maybe text-graphical, similar to the classic tools which came with 
>>> sound cards: Using cursor keys to navigate between different volume sliders 
>>> and slide them around, that is :-)
>>> 
>>> Eric
> 
> 
> 
>> Well, I did port my mixer driver to NASM. It can be loaded or compiled into 
>> a program.
>> I also wrote a new command line utility to view and adjust mixer settings. 
>> It is in assembly and has the mixer driver compiled into it. That way it 
>> requires no extra files.
>> The new utility (with built in mixer) all the status text and help text and 
>> switch processing. Comes in at under 2.5k and is to small to UPX compress.
>> The original user who was wanting a mixer program has tried it and said “it 
>> works great for what he needs”
>> Also, most of the functionality it provides also works under DOSbox.
>> I won’t be officially releasing it for a few days, maybe a week or so. Going 
>> forward, it is going to be the normal release model for my new DOS stuff. It 
>> permits my Patreon Supports early access. It also allows me to possibly find 
>> and fix any bugs or make changes before releasing to the general public.
>> But, if you want to take a look, you can grab the sources from 
>> https://gitlab.com/DOSx86/sbpmixer
>> and run the build script (BAT or sh) to create the driver and binary. Only 
>> need NASM in your path for the compile.
>> Maybe someday I’ll add a text UI to it. Or possibly, a separate program. Or 
>> maybe not. We will see.
>> :-)
>> Jerome
> 


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

Re: [Freedos-user] SoundBlaster volume control for the distro

[Jerome Shidel]

Hi, 

> On May 11, 2022, at 4:09 PM, Eric Auer  wrote:
> 
> 
> Hi!
> 
> It seems our distro has no volume control or mixer tool yet,
> so it would be nice to add one. We can start with the command
> line tool SBMIX, although something with Text-graphical user
> interface would of course be even more cool :-)
> 
> https://www.bttr-software.de/products/sbmix/
> 
> Thanks! Regards, Eric


Well, there are several such mixers available with suitable licenses. 

I wrote one myself back in the early 90’s. I recall it was a painful task that 
took several long days. It involved a lot of guessing and test probing my sound 
card I/O ports. It resulted in numerous system freezes, crashes and reboots. 
Once I worked it all out, I created a <6k command line mixer program and a 
separate (not used by the cmdln program) <1k program loadable/embeddable 
driver. 

Back when I made a bunch of my ancient pascal code publicly available, I put 
the sources and precompiled versions up on GitHub at 
https://github.com/shidel/DustyTP7  . I 
still have a bunch of other things to put up there. However, I just haven’t had 
the time or motivation to figure out what unit versions go with what program 
sources and other such mundane things. My code repos were not as nicely 
organized back then. 

Anyhow, I just thought I’d mention the one I made back then. I suspect the BTTR 
version is probably better. After all, mine was made with a lot of "guess 
work", "trial and error” and has not been updated in roughly 3 decades. 

:-)

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

Re: [Freedos-user] FDCONFIG.SYS

[Jerome Shidel]

Hi Daniel, 

> On May 17, 2022, at 5:45 AM, Daniel  wrote:
> 
> This may be a crazy or even insane thing to ask, nevermind do, but is it 
> possible to create a new config file and use that.  For instance rename 
> fdconfig.sys to the MSDOS config.sys?

You can use either FDCONFIG.SYS or CONFIG.SYS with FreeDOS. Nothing special is 
needed. You can just rename FDCONFIG.SYS so the kernel will then look for 
CONFIG.SYS. 

However, there is an advantage to using FDCONFIG instead. 

Older commercial programs that have their own installers and modify the config 
file, were generally bad at making good changes to the CONFIG.SYS and 
AUTOEXEC.BAT files. Often duplicating or creating conflicting settings. 
Sometimes even reducing things like FILES=80 to FILES=40. 

This was even an issue sometimes when installing programs created circa MS-DOS 
3 onto later versions of MS-DOS like 6.2 or installing into PC-DOS. 

Also, there are also some differences when it comes to what drivers and their 
settings get used by FreeDOS. 

Using FDCONFIG and FDAUTO provides an relatively easy way to use those old 
installers and not break your system configuration. Then afterwards, you can 
manually include any needed changes.

:-)

Jerome

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

[Freedos-user] FreeDOS and Rufus

[Jerome Shidel]

Hi All,

A first time user reported having issues booting the 1.3 LiveCD after creating 
a USB stick with Rufus. Other than a few minor things, I don’t use windows. So 
if one of you are familiar with the tools they are using, they could probably 
use some help or at least some pointers on getting a bootable USB stick. 

https://gitlab.com/FreeDOS/issue-reporting/-/issues/27 


Thanks,

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

Re: [Freedos-user] MKEYB 0.48 works on PC and XT machines.

[Jerome Shidel]

Hi Tom, 

> On Apr 4, 2022, at 12:56 PM, tom ehlert  wrote:
> 
> Hi Jerome,
> 
>>> On Apr 3, 2022, at 11:50 AM, tom ehlert  wrote:
>>> 
>>> Hi everybody,
>>> 
>>> mKEYB used to need AT class machines or better to work.
>>> 
>>> Davide Bresolin taught mKEYB to run on PC's and XT's.
> 
> I forgot to add:
> 
> WITHOUT increasing the resident footprint for AT+ class machines.
> 
>>> now he has a 700 byte keyboard driver, saving 2.3 KB wrt XKEYB
>>> and 5 KB wrt. MS KEYB.
>>> 
>>> announcement 
>>> https://forum.vcfed.org/index.php?threads/the-quest-for-a-small-keyboard-driver.1238141/
>>> download https://github.com/davidebreso/mkeyb/releases/tag/v0.48
>>> 
>>> Tom
> 
>> Since this version is not on your page, I have some questions…
> 
>> Does it mean you are passing development off to Davide and I need
>> change the package LSM to show it is maintained by him? Including
>> the primary download site be changed to his GitHub repo along with 
>> maintained at URL?
> 
>> Or, does it simple mean you plan on continuing development and I
>> should just add such things to the LSM?
> 
>> Or, does it mean you plan on incorporating his changes and the metadata is 
>> fine as it is now?
> 
> reasonable questions.
> 
> in the moment I'm not in reach of a DOS environment, so I am not able
> to test his drivers. looking at his source changes, I am fairly
> confident this should work (and of course he tested this himself).
> 
> as soon as I have tested this in my environment (not long), I plan to
> incorporate his changes, and the metadata is fine as it is now.

Sounds good. I’ll keep an eye out for your official update. Thanks.

:-)

Jerome



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

Re: [Freedos-user] MKEYB 0.48 works on PC and XT machines.

[Jerome Shidel]

Hi Tom, 

> On Apr 3, 2022, at 11:50 AM, tom ehlert  wrote:
> 
> Hi everybody,
> 
> mKEYB used to need AT class machines or better to work.
> 
> Davide Bresolin taught mKEYB to run on PC's and XT's.
> now he has a 700 byte keyboard driver, saving 2.3 KB wrt XKEYB
> and 5 KB wrt. MS KEYB.
> 
> announcement 
> https://forum.vcfed.org/index.php?threads/the-quest-for-a-small-keyboard-driver.1238141/
> download https://github.com/davidebreso/mkeyb/releases/tag/v0.48
> 
> Tom

Since this version is not on your page, I have some questions…

Does it mean you are passing development off to Davide and I need change the 
package LSM to show it is maintained by him? Including the primary download 
site be changed to his GitHub repo along with maintained at URL?

Or, does it simple mean you plan on continuing development and I should just 
add such things to the LSM?

Or, does it mean you plan on incorporating his changes and the metadata is fine 
as it is now?

Thanks 

Jerome



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

Re: [Freedos-user] [freedos:news] FreeDOS 1.3 discussion

[Jerome Shidel]

> On Mar 13, 2022, at 5:49 PM, Ruben Figueroa  
> wrote:
> 
> The above notes :"the return of networking"  I installed FreeDOS as the OS 
> which has a ethernet port.  After installing what I thing I need and reboot I 
> get this message "Physical hardware networking is not supported at this 
> time."  I've see youtube videos where installed in a VM like Oracle and it 
> works.  Is that what I need to do?

Setting up networking on Real Hardware usually requires a packet driver from 
the manufacturer. Most of which are not open source. 

When FDNET is invoked from the FDAUTO.BAT file, it is started with the option 
‘START’. This is basically the same as when you just run FDNET from the command 
line. It will do a quick hardware test for known supported virtual machine 
platforms (like VirtualBox and vmWare). If it is running on one of the 
supported platforms, it sets up networking. 

But on real hardware and other platforms, it gets a more complicated. 

You can attempt to force FDNET to setup networking anyway, using ‘FDNET try’. 
It will attempt to use the supplied packet drivers and if successful, 
networking will be up. You would then just replace the ‘start’ with ‘try’ in 
the FDAUTO.BAT file.

If that does not work, you will need to find a packet driver to support your 
NIC. You can create a FDNETPD.BAT file that simply loads that driver. And place 
your FDNETPD.BAT in the FDNET directory. When FDNET is run, it will see the 
custom driver loading batch and run it. Then afterwards it will start the DHCP 
client.

Or, you will need to do/add full manual network configuration to your startup 
config files and not use FDNET to bring up the connection. 

> 
> Sent from sourceforge.net because you indicated interest in 
> https://sourceforge.net/p/freedos/news/2022/02/freedos-13/ 
> 
> To unsubscribe from further messages, please visit 
> https://sourceforge.net/auth/subscriptions/ 
> 

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

Re: [Freedos-user] [freedos:news] FreeDOS 1.3 discussion

[Jerome Shidel]

> On Mar 13, 2022, at 5:49 PM, Ruben Figueroa  
> wrote:
> 
> The above notes :"the return of networking"  I installed FreeDOS as the OS 
> which has a ethernet port.  After installing what I thing I need and reboot I 
> get this message "Physical hardware networking is not supported at this 
> time."  I've see youtube videos where installed in a VM like Oracle and it 
> works.  Is that what I need to do?
Setting up networking on Real Hardware usually requires a packet driver from 
the manufacturer. Most of which are not open source. 

When FDNET is invoked from the FDAUTO.BAT file, it is started with the option 
‘START’. This is basically the same as when you just run FDNET from the command 
line. It will do a quick hardware test for known supported virtual machine 
platforms (like VirtualBox and vmWare). If it is running on one of the 
supported platforms, it sets up networking. 

But on real hardware and other platforms, it gets a more complicated. 

You can attempt to force FDNET to setup networking anyway, using ‘FDNET try’. 
It will attempt to use the supplied packet drivers and if successful, 
networking will be up. You would then just replace the ‘start’ with ‘try’ in 
the FDAUTO.BAT file.

If that does not work, you will need to find a packet driver to support your 
NIC. You can create a FDNETPD.BAT file that simply loads that driver. And place 
your FDNETPD.BAT in the FDNET directory. When FDNET is run, it will see the 
custom driver loading batch and run it. Then afterwards it will start the DHCP 
client.

Or, you will need to do/add full manual network configuration to your startup 
config files and not use FDNET to bring up the connection. 


> 
> Sent from sourceforge.net because you indicated interest in 
> https://sourceforge.net/p/freedos/news/2022/02/freedos-13/ 
> 
> To unsubscribe from further messages, please visit 
> https://sourceforge.net/auth/subscriptions/ 
> 

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

Re: [Freedos-user] Fdnet

[Jerome Shidel]

> On Mar 8, 2022, at 4:44 AM, Björn Morell  wrote:
> 
> I run MTCP and have for a while and it works great, ftp server etc. I have 
> fresh installatio of 1.3 on an
> 
> old fujitsi-siemens 1000 mhz, with an intel 815 chipset so the e1000pkt works 
> fine with DHCP and it
> 
> updates the .cfg. I ran the wattcp.bat and have a wattcp.cfg in freedos\bin. 
> Paths to wattcp and MTCP
> 
> cfgs in fdauto.bat and this, as suggested in freedos wiki instructions, 
> fdauto:
> 
> "if not exist %dosdir%\bin\fdnet.bat goto NoNetwork
> 
> e1000pkt 0x60
> 
> call %dosdir%\bin\fdnet.bat start
> 
> c:\ddhcp\ddhcp /w /f"
> 
> But i get this at boot (ftpsrv, browsing etc. works though) ;
> 
> 
> "
> 
> Packet Driver for Intel (R) PRO/1000 Family of Desktop & Server adapters v0.50
> 
> Copyright (C) Intel Corportation 2006. All rights reserved.
> 
> PCI BIOS is required for this driver
> 
> HERE COMES THE STRANGE PART
> 
>Physical network not supported at the moment (My translation from swedish).
> 
> IP address : 192.168.1.247
> 
> Netmask   : 255.255.255.0
> 
> Gateway   : 192.168.1.1
> 
> DNS sever : 192.168.1.1
> 
> Lease time: 43200 "
> 
> 
> What am I doing wrong to get the same Message as before I configured anything 
> ?
> 
> things work though !
> 
> Have good day :)

FDNET only supports a select set of drivers. It is displaying that message.

Since, networking is configured, you are manually loading a packet driver and 
manually configuring dhcp, there really is no reason to call FDNET. 

Simply REM the call to FDNET. It will prevent the message. 


> 
> Bear
> 
> 
> 
> 
> 
> 
> ___
> 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] retro gamer review of FreeDOS 1.3

[Jerome Shidel]

> On Mar 5, 2022, at 8:49 AM, Eric Auer  wrote:
> 
> 
> Hi!
> 
>>> - it sounds like a very bad idea to create a zillion FAT16 partitions
>>>   and format only one of them, while using FreeDOS FDISK etc. by hand
>>>   made it easy for the reviewer to just create ONE FAT32 drive :-p
> 
>> When the installer verifies there is no drive readable to DOS ... it
>> asks FDISK to please auto-partition the drive. There are no auto-partition
>> options to make only one that uses the entire drive.
> 
> FDISK is open source, so the auto-partition feature could and should
> be updated from "100 FAT16 drives" to "1 FAT32 drive" if possible, but

Or, at least be ably to specify that from the command line. 

> 
>> So, it comes down to making everyone (including novices with no idea how
>> to use fdisk) partition the drive manually or let fdisk do what it wants.
> 
> It was a completely normal part of DOS life that when you were planning
> to install MS DOS you would have to take the time to understand and use
> FDISK, so I would certainly prefer manual partitioning over autocreated
> FAT16 C: to ZZZ9: drives of which only C: gets formatted anyway ;-)

Yes, I was normal. But, it really isn’t the norm any more. But, there is 
nothing preventing a knowing user from pre-partitioning their drive prior to 
installing. In fact, if you plan on dual booting or using a custom partition 
scheme, you should do that. It isn’t hard to do and the installer will see it 
is done and be happy to move along without auto-partitioning or throwing the 
user into FDISK. 

At least FDISK puts all those other partitions inside an extended partition. 
You can get rid of them, by simply deleting the extended partition. Thankfully, 
you don’t have to delete them one at a time.

> 
>> Without such an update to fdisk, I still think the benefits provided by
>> auto-partitioning out weigh making everyone manually partition their drive.
> 
> That is the part where I disagree and that youtube reviewer is not the
> first person to make fun of that FDISK "feature". We already have the
> same discussion on the list :-) As said, remembering that FDISK had a
> non-free toolchain and no active maintainers, I would prefer to just
> let people use FDISK by hand if no C: is found.

There is nothing preventing you from manually partitioning. 

What I would like to see is the ability for for FDISK to auto-partition 1 
drive, with the option of making it FAT16 (2GB) or FAT32 (Whole Drive). 

With that ability, I think the installer could by default just make a single 
big FAT32 partition. And for advanced mode, it could offer the choice of whole 
disk FAT32 or single 2GB FAT16 to provide compatibility with older DOS 
platforms. 

> Regards, Eric
> 
> PS: Odd that the youtuber has even tried the floppy installer at all,
> as he spends half of his video talking about CD-ROM game support :-o
> 
> 
> 
> ___
> 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] retro gamer review of FreeDOS 1.3

[Jerome Shidel]

> On Mar 4, 2022, at 3:57 PM, Eric Auer  wrote:
> 
> - it sounds like a very bad idea to create a zillion FAT16 partitions
>   and format only one of them, while using FreeDOS FDISK etc. by hand
>   made it easy for the reviewer to just create ONE FAT32 drive :-p

When the installer verifies there is no drive readable to DOS and there is a 
drive that can be used that has NO partitions and that drive can be safely 
partitioned, it asks FDISK to please auto-partition the drive. There are no 
auto-partition options to make only one that uses the entire drive.

So, it comes down to making everyone (including novices with no idea how to use 
fdisk) partition the drive manually or let fdisk do what it wants. 

It would be great if there were an option to just use the whole drive or only 
create the first 2GB partition. But there isn’t. 

If fdisk were updated accordingly, then the installer would do that instead. 

Without such an update to fdisk, I still think the benefits provided by 
auto-partitioning out weigh making everyone manually partition their drive. 


> - one of the installers took 20 minutes, but the legacy one was fast?

He was talking about the FloppyEdition taking 20 minutes. This has to do with 
pass-through compression. However, the FloppyEdition is primarily designed to 
install from Floppy Diskette. When doing that, the largest bottleneck is actual 
floppy speeds. I have done performance comparisons on real hardware against 
MS-DOS 6.2. Obviously, different systems could yield other results and FreeDOS 
is much larger. To be fair, total time/total disks FreeDOS was about 5% faster. 
This is negligible and not usually worth mentioning. It could also be a little 
slower on other systems.  But for all intents and purposes based on their size, 
install speed is comparable.




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

[Freedos-user] Too difficult

[Jerome Shidel]

I'm wondering if BlockDrop still gets to difficult too fast. 

Getting past level 10 is really hard. 
And level 11, will probably eat all remaining lives.
At level 11, there are still a bunch of other color and special blocks that 
haven't even appeared yet.

Have you tried it?
What do you think? 
Should I slow the difficulty increase even further?

After all, if you like to torment yourself, you can skip a level before it 
starts by pressing the TAB key. You don’t get any points for that level, but 
thats up to you. Also, within limits restricted by your level, you can usually 
speed up and slow back down using +/- keys. Has no effect on score and it won’t 
slow below a minimum for a level. Mostly, that is to keep the lower levels from 
being too boring for experienced players.

Opinions? 

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

[Freedos-user] FreeDOS on Vinyl

[Jerome Shidel]

Hi all, 

I don’t know if you’ve seen this or not.

Booting FreeDOS from a vinyl record. It was mentioned on Hack a Day episode 95, 
starting just before the 13 minute mark 
https://hackaday.com/2020/11/27/hackaday-podcast-095-booting-freedos-from-a-vinyl-record-floating-on-mushrooms-and-tunneling-through-a-living-room/
 

 

There is also a quick article and video of the boot at 
https://hackaday.com/2020/11/23/booting-a-pc-from-vinyl-for-a-warmer-richer-os/ 

 

This reminds me so much of the days I used to load programs from cassette tape. 

:-)


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

Re: [Freedos-user] ECHO vs @ECHO

[Jerome Shidel]

> On Mar 1, 2022, at 3:29 PM, tom ehlert  wrote:
> [..]
> I'm still surprised the
> 
>   ECHO Off | VGoToXY Up | VEcho /N /E
> 
> line doesn't work, but as I don't care about MSDOS 3.x anyway I will
> be able to live with that
> 
> Tom

+1

I don’t spend much time using MS-DOS 1 & 2 or any other < 3.3. So, I can live 
with it too. 

:-)

Jerome

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

Re: [Freedos-user] ECHO vs @ECHO

[Jerome Shidel]

Hi, 

> If I run either TEST1.BAT or TEST2.BAT with MS-DOS 3.0, 3.1, or 3.2, it 
> crashes.

That is definitely possible. Since the earliest version of DOS I really only 
every used was MS 3.3, I never have worried about pre-3.3 compatibility. 

> If I run them with MS-DOS 3.3 or 4.01 the session looks like this:
> 
> C:\>test1
> 
> 
> C:\>  ECHO Test Line 1
> Test Line 1
> 
> C:\>  ECHO Test Line 2
> Test Line 2
> Test Line 2
> 
> C:\>test2
> 
> Test Line 1
> Test Line 2
> Test Line 2
> 
> C:\>

Interesting, I wonder where the duplicate “Test Line 2” is coming from. vecho 
does not use STDOUT to display text, it uses the BIOS. Same for scrolling, etc.

> If I run them in MS-DOS 5.0 thru 6.22 the session looks like this:
> 
> C:\>test1
> 
> 
> C:\>  ECHO Test Line 1
> Test Line 1
> 
> C:\>  ECHO Test Line 2
> Test Line 2
> 
> C:\>
> C:\>test2
> 
> Test Line 1
> Test Line 2
> C:\>
> 
> If I run them in DR-DOS 6.0 thru 8.0 the session looks like this:
> 
> C:\>test1
> 
> Test Line 1
> Test Line 2
> C:\>test2
> 
> Test Line 1
> Test Line 2
> C:\>
> 
> If I run them in FreeDOS 1.2 or 1.3 the session looks like this:
> 
> C:\>test1
> Test Line 1
> Test Line 2
> C:\>test2
> Test Line 1
> Test Line 2
> C:\>
> 

It looks like the OS is forcing a CR after execution. Which is down right 
inconvenient. A possible remedy would at boot set a env variable for the OS 
(which you probably already do). The after erasure, if not running on FreeDOS, 
perform a additional vgotoxy up or possible or double that vgotoxy up up.

echo off | vgotoxy up | vecho /n /e
if not “%OS% == “FREEDOS” vgotoxy up up

> As you can see, there are extra blank lines (though that problem is not a 
> deal-killer), extra ECHO's, and extra DOS prompts (extra  keys being 
> pressed) depending on the specific environment.  I think FreeDOS is the only 
> one works the way I think it should (no extra "stuff" appearing on the screen 
> anywhere).

There is one other thing to try via v8power tools. Instead of using vgotoxy up 
| vecho /n /e, there is another combination to do it as well.

echo off | vgotoxy up | vdelete

vdelete  doesn’t display text. It literally deletes a row and feeds a blank 
line in from the bottom. It can be told to remove multiple lines. However, 
defaults to 1 line. Outside of a couple rare situations they rarely get used. 
So, I sometimes forget about them.

Anyhow, vdelete is a far simpler program than vecho. You may even have better 
compatibility results. 

However, you may be better off writing a HUSHECHO program that does all of 
this. It could test the DOS Version and perform any additional stuff required. 
As you find exceptions, just add a little more to it. Probably only be 100-200 
byte com file total even with the exceptions. 

:-)

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] Looking for easy to follow instructions on how to connect to Samba share

[Jerome Shidel]

Hi,

I’m no expert on Samba shares. But from personal experience, your probably not 
going to have much luck. 

I have a Linux server on my home network. When I let it use a minimum of SMB2, 
all but one ancient Mac will chat with it. No problem. 
But to get that one Mac working, requires lowering the minimum to NT4. When I 
do that, all of the Macs (new and old) are happy. The Linux machines are happy. 
But, the Windows 10 machines get snobbish and no longer talk to it. So, I 
pretty much need to use a minimum of SMB2. Then relay the old Mac through a 
newer one.

I mention that only to say that I doubt you’ll get it working in DOS with SMB2 
and using a lower minimum will just cause problems.

But, there is possibly an alternative. If you are not limited to only using 
Samba and have a Linux server, consider using EtherDFS. It’s lite weight and 
works pretty good.

There are a couple minor hoops to jump through. But once setup, you don’t even 
notice.

Basically, my Linux server has a FAT disk image that gets mounted to a 
directory. EtherDFS shares that dir for my DOS machines. Also, that dir is 
shared via Samba to everything else.

The only issue I’ve noticed is with long file names. If I store something in 
that DIR that uses a non-DOS 8.3 filename, the file appears over EtherDFS but 
is not accessible from DOS. 

Otherwise, I’ve seen no issues.

Jerome 




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

Re: [Freedos-user] ECHO vs @ECHO

[Jerome Shidel]

Hi Bret,

> On Feb 28, 2022, at 6:42 PM, Bret Johnson  wrote:
> 
> This to me seems like a solution that could actually do what I'm wanting to 
> accomplish.  I may experiment with that and see what happens.  As you note, 
> there may be compatibility issues with some DOS versions (V8 power tools may 
> not work with older versions of DOS).

As for compatibility, I was just referring to the “piped one-liner”.

99% of the code in the V8Power Tools talks directly to hardware or the the 
BIOS. The exceptions being things like loading resource (translation files), 
performing stdout/in (file handles, not FCBs), looking up environment variables 
and termination. Other than program terminate, none of that would be used in 
the two line “vgotoxy up + vecho /n /e” combo. So, it would definitely be good 
down to a very low version of DOS. I need to dig out the books to see if it 
would work in DOS 2.00 (exit code + PSP structure). 

:-)

Jerome

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

Re: [Freedos-user] ECHO vs @ECHO

[Jerome Shidel]

Oh, one more thing... 

It could also possibly be a one-liner, like so:

echo off | vgotoxy up | vecho /n /e

But, it will display all of that before erasure. Also, I have no idea if there 
would be compatibility issues under some DOS platforms or their different 
versions. But, it works fine in FreeDOS as a one-liner. 

:-)




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

Re: [Freedos-user] ECHO vs @ECHO

[Jerome Shidel]

Well, I guess I’ll put in two cents worth of a non-standard solution…

If you don’t want to have the “echo off” on the screen and don’t want to clear 
the screen either, you can do it using two utilities in V8Power tools 
(available and provided with FreeDOS). 

It would look something this…

—— TEST.BAT ——

echo off
vgotoxy up
vecho /n /e
echo hi

—— END ——

So what happens is this:

echo off# displays the command echo off
vgotoxy up  # moves the cursor back up one line
vecho /n /e # tells vecho not to perform a CRLF when finished and 
tells it to clear everything from the cursor to the end of the line.
echo hi # prints hi where “echo off” originally was located.

While technically, echo off is printed then erased. It happens very quickly. 
Also, if you redirect output to a file, you will see the “echo off” that 
appears first. 

:-)

Jerome



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

Re: [Freedos-user] 286 Installation on CF Card

[Jerome Shidel]

> On Feb 23, 2022, at 3:57 PM, Frank Pioch  wrote:
> 
> 
> Hi,
> 
> I am trying to install Freedos 1.2 or 1.3 on a 286 with a CF card.
>  Unfortunately, I don't have a floppy disk drive on my Win10 PC, so I make 
> the detour via this trick:
> 
> http://theinstructionlimit.com/installing-ms-dos-6-22-on-a-486-without-a-floppy-drive-using-a-cf-to-ide-adapter
>  
> 
> 
>  However, with 1.3 I get a strange error message: this installation is only 
> suitable for 80386 or higher. The installation via the floppy disk version 
> also failed despite "setup 286" as option. 

I assume you are referring to 1.3 Final and not RC5, RC4, etc. 

Like FreeDOS 1.3, the primary installer can only run from CD/USB and requires a 
386+. 

The Floppy Edition requires only a 8086 with EGA or better graphics. The 
support for lesser video cards is planned to eventually remove the EGA 
requirement. That requirement for EGA would/should not cause an invalid 
op-code. However, more information is required to determine what the cause of 
the problem you are experiencing with the Floppy Edition.

> With version 1.2, at some point during the boot process, a message regarding 
> incorrect opcode is displayed and the lines scroll through. 

The install process for 1.2 requires either a CD-ROM or USB. Therefore uses 
some tools that require a 386 or better. Only a manual installation performed 
by hand was possible on sub-386 machines with that release. 


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

Re: [Freedos-user] Re (2): Installing FreeDOS 1.3.

[Jerome Shidel]

> On Feb 21, 2022, at 1:25 PM, pe...@easthope.ca wrote:
> 
> Jerome,
> 
>> While it should get FreeDOS booting, I don=E2=80=99t think it will =
>> provide enough flexibility for what you want.
> 
> Afraid of that!   =8~/
> 
>> ... it is free 
>> just not open source. It has very strict =E2=80=9Ccan distribute if you =
>> change absolutely nothing=E2=80=9D license. 
> 
> No problem for me.
> 
>> ... dozens of options regarding the MBR/Partition tables. 
> 
> Setting the bootable flag on sdb1 might be a good first step.  Should 
> anything else in the partition table change?  Obviously partition 
> structure should not change.
> 
Possibly the boot code. 

> 
> Isn't at least one file missing from sdb1?  The kernel?  Command 
> interpreter?

They should be there. You boot the CD and double check the drive C: for 
KERNEL.SYS and COMMAND.COM . If there missing, then simply 
doing a SYS C: (May work from the RAM DISK or CD-ROM, otherwise from the drive 
A: emulated floppy) might get the system working.

> Thx!   ... P.

:-)

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

Re: [Freedos-user] How to upgrade 1.3 RC5 to 1.3

[Jerome Shidel]

> On Feb 21, 2022, at 3:31 PM, Björn Morell  wrote:
> 
> How do  I upgrade 1.3 RC5 to 1.3 on a 486 ( I can use bootcd ) ?

There is a CD Boot Floppy image included in the LiveCD and LegacyCD zip files 
alongside the appropriate ISO.

You can run the normal Installer. However, you may wish to run it in advanced 
mode for greater control on what happens (setup adv). Also, the Floppy Edition 
installer is an option as well. It can be run from a set of floppy diskettes. 
Or, even from the subdirectory (FDI-x86) on the CD-ROM. It is a completely 
different installer and is less CPU/disk intensive. It to has an advanced mode.

> 
> 
> 
> ___
> 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] Installing FreeDOS 1.3.

[Jerome Shidel]

>> If that does not work or if you prefer, you can use FDISK and SYS to 
>> update the boot code.
> 
> Are instructions available?

Only as far as the individual programs help. 

> 
> The advanced installation process of FreeDOS might also provide a 
> resolution.

While it should get FreeDOS booting, I don’t think it will provide enough 
flexibility for what you want.

> 
> If all else fails I can repeat the FreeDOS installation with MBR 
> included. Then make Oberon the primary boot again.  Then reinstall 
> Boot Manager.  Then each of the systems should be bootable.  Fixing 
> FreeDOS directly is preferable.  =8~)

Well, if you want to just try and “fix” what is already installed. Head over to 
my server and grab the mirrored copy of MBRTOOL. The original site doesn’t 
exist anymore. However, it is free just not open source. It has very strict 
“can distribute if you change absolutely nothing” license. So, it isn’t 
provided with FreeDOS or on the official or my download repos. But, it is a 
great little utility with dozens of options regarding the MBR/Partition tables. 
There are two versions mirrored on my server. The last v1.x that is strictly 
command-line interface and the last 2.x which also has a text UI. Both work 
fine. However, 2.x version is much larger and not as suited for boot/recovery 
floppies.

https://fd.lod.bz/redist/disk/MBRtool/ 


> Thx!   ... P.
> 
> 
> -- 
> mobile: +1 778 951 5147
>  VoIP: +1 604 670 0140
>   48.7693 N 123.3053 W
> 
> 
> ___
> 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] Installing FreeDOS 1.3.

[Jerome Shidel]

> On Feb 20, 2022, at 6:09 PM, pe...@easthope.ca wrote:
> 
> Just installed the plain FreeDOS 1.3 running the .iso installer image 
> against Qemu in Linux Debian bullseye.
> 
> Installation was to a drive brought from another machine and 
> temporarily connected to the Linux system.  The drive was already 
> formatted with four primary parts. The installer didn't ask which part 
> to target.  =8~/  Luckily it installed where intended; /dev/sdd1.  
> =8~)
> 
> When the drive is returned to the original PC and it is booted this 
> message appears.
> 
> Loading FreeDOS No KERNEL SYS
> =8~(
> 
> Questions.
> 
> (1) Can the installer recognize a part beyond the first? I might want 
> to install to /dev/sdd2 for example.

Show Quoted Content
> On Feb 20, 2022, at 6:09 PM, pe...@easthope.ca wrote:
> 
> Just installed the plain FreeDOS 1.3 running the .iso installer image 
> against Qemu in Linux Debian bullseye.
> 
> Installation was to a drive brought from another machine and 
> temporarily connected to the Linux system.  The drive was already 
> formatted with four primary parts. The installer didn't ask which part 
> to target.  =8~/  Luckily it installed where intended; /dev/sdd1.  
> =8~)
> 
> When the drive is returned to the original PC and it is booted this 
> message appears.
> 
> Loading FreeDOS No KERNEL SYS
> =8~(
> 
> Questions.
> 
> (1) Can the installer recognize a part beyond the first? I might want 
> to install to /dev/sdd2 for example.

It installs to the First drive whose partition is compatible to DOS and 
enumerated by the kernel as drive C:.

Unless, you run it in advanced mode. Then other hard disks could be targeted 
for install.

> 
> (2) Why won't the installed system boot.  Isn't the intention to have 
> a working system?

It was decided to be less forceful when it comes to updating the boot code on 
hard drives.

During installation on real hardware, you should have been prompted to update 
your MBR. If you select no and there is not a compatible boot loader in the 
MBR, the system won’t boot.

If you boot the Install media, you can try running MBRZAP (or ZAPMBR, it’s been 
a while). It will run the portion of the installer that updates the boot 
loader. (Or, at least it used to, I haven’t tested it in a long time)

If that does not work or if you prefer, you can use FDISK and SYS to update the 
boot code.
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Total newby question

[Jerome Shidel]

> On Feb 18, 2022, at 2:16 AM, John Vella  wrote:
> 
> Equally newb reply... It's there any advantage over installing virtualbox and 
> running freedos there? 
> 
> On Thu, 17 Feb 2022, 23:29 Joseph Kelchner,  > wrote:
> Hello,
> 
> I’m wondering if Freedos could be used as my operating system on a Windows 10 
> pro Hyper-V Virtual Machine?
> 
> Thanks!
> 
> Joe 
> 
I don’t use Hyper-V. But, I can tell you a couple general things to consider.

Modern UEFI only systems and DOS don’t play well together at all. VirtualBox 
will let you run DOS on such systems under a host OS.

There very few programs under DOS that can talk to most on-board audio in 
modern machines. VirtualBox will provide a sound card emulation layer that can 
be used by many programs and games.

Under VirtualBox you will need to live without sound for programs that use the 
PC speaker for audio under DOS. 

VirtualBox does not fully emulate all the features of VGA. While generally that 
isn’t a problem. Some programs and games may not be able to work as designed or 
at all. 

Some games and programs just don’t work under VirtualBox or most other 
Emulators for unknown reasons. 

The basic networking support provided with FreeDOS works fine under VirtualBox. 
However, there are only a handful of programs that will be helpful in doing any 
kind of remote drive mapping. So, getting files in and out of the VM requires a 
little more effort.

You may consider one of the DOSBox variants instead. 

Basic networking is not supported. However, you can install FreeDOS in a hybrid 
mode (default under DOSBox). That install mode installs FreeCOM and all the 
other bells and whistles. However, it does not install the FreeDOS kernel. 
Instead it uses the DOSBox kernel. This allows direct access in the DOSBox to 
specific folders on the Host as if they were DOS drives. 

DOSBox has pretty good emulation for sound card support under DOS.
DOSBox emulates many of those obscure VGA features not provided under 
VirtualBox.
DOSBox emulates the PC speaker.
DOSBox can be sped up or slowed down for older games that have problems on fast 
machines.
Of those occasional programs and games that just don’t work in VirtualBox, most 
work fine under DOSBox. Although, there are a couple that only seem to work on 
real hardware.

>  
> 
> ___
> 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 mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DEV0 LegacyCD: AHCI.SYS CD driver problems with both Installers

[Jerome Shidel]

>> FATAL ERROR: error code #21, unsepcified error with 
>> "D:\FDOS_X86\SLICED\FREEDOS.SAF" 
>>   Failed. 

Error #21 is a DOS error code, Disk Drive Not Ready.

Does not sound good.

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

Re: [Freedos-user] Watcom compiler on FreeDOS 1.3 RC5

[Jerome Shidel]

Hello Fabian,

I just did several tests and am unable to replicate the issue you are having. 
More information is needed.

> On Jan 26, 2022, at 3:32 AM, Fabian Boucsein  wrote:
> 
> Dear Freedos users,
>  
> i recently installed a base installation of FreeDOS 1.3 RC5 using the
> FullUSB edition. After that i tried to install the Watcom compiler
> with fdimples.

How did you manage that? 

USB devices are not "Plug and Play" in DOS. You would need to have the drive 
already plugged in when the system boots. That implies you booted from the USB 
stick. When you do that, the system has know idea how or where to place any 
things. You would need to set some configuration information to be able to 
install any packages. The installer does that a bunch of stuff during 
installation to permit package installs. But, those are temporary changes only 
active while the installer is running. 

> A lot of error messages appeared on the screen and
> in the end only 13 files or so were copied to the harddisk. I checked
> the md5sum of the downloaded ZIP file and it matched the one on the
> FreeDOS website.

the SUM was good for the download of FreeDOS or the Download to the WATCOM 
package?

>  
> Is that error allready known to you or is it just my system that behaves
> differently for whatever reason? 

What Errors?

>  
> After installing the Watcom from the IBIBLIO FreeDOS archive what
> do i need to configure the compiler so that i can use it?
>  
> Many greetings,
> Fabian
>  

Jerome


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

Re: [Freedos-user] Linux-freedos boot

[Jerome Shidel]

> On Jan 25, 2022, at 4:16 PM, andrea...@tiscali.it wrote:
> 
>  OK, it's an old annoing question:I have a laptop with linux installed and I 
> created another dos / fat 32 partition where I installed freedos 1.3. (before 
> installing freedos I activated C:\ms-dos with part.exe).
> OK Freedos, but disappears Linux MBR, and I can't anymore access linux 
> although I have grub installed.
> With GAG cd live you see linux but it is not loaded due to problems in the 
> MBR.
> The only way to repair the MBR and log in again in linux was to use the BOOT 
> REPAIR live cd.
> Or another way to solve the problem?
>   Thanks,
>  andrea

During installation, the installer creates two backups and stores them in 
C:\FreeDOS\ as BOOT.MBR and BOOT.BSS. The MBR is created by FDISK when it is 
told to update the boot code. The second is created by the SYS command. You 
should be able to use FDISK to restore the MBR. 

There is an excellent free DOS utility called MBRTOOL. It is not open source 
and has some other distribution restrictions. But, it is free and can be 
legally distributed as-is. Do to those restrictions it cannot be included with 
the FreeDOS release. But, you can grab a mirrored copy from my website at 
https://fd.lod.bz/redist/disk/MBRtool/  
v1.x is much smaller than v2.x. But, both work really well. It is a great tool 
to have laying around for emergencies. 

:-)

Jerome


> 
> 
> Con Tiscali Mobile Smart 70 hai 70 GB in 4G, minuti illimitati e 100 SMS a 
> soli 7,99€ al mese http://tisca.li/Smart70 
> 
> ___
> 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] Quake2 for FreeDOS

[Jerome Shidel]

Hello,

> On Jan 23, 2022, at 5:09 AM, Michał Dec  wrote:
> 
> Perhaps Quake2 could become a FreeDOS package?

This was just a quick and cursory examination. It could be completely wrong...

I see two problems with providing it as a package included with FreeDOS. 

First, I took a quick look at the pages and browsed the source and did not see 
any LICENSE or COPYING Policy. Perhaps it is mentioned somewhere, but at a 
glance I did not notice one. Without such a declaration, I think it technically 
is source-available not open-source. But, I’m no lawyer. 

Second, you mention in you “how I got it to work” section that you needed to 
copy the data files from the CD. So, I don’t see how we could legally 
include those files. Without them, it would not be playable. 

That being said. You could turn it into a package for your personal use. 
Basically, using running pkgmaker before you go through that process of 
installing and configuring it. Then once again afterwards. Then using using 
pkg2zip to create the package archive. All part of the latest PKGINFO package 
released after RC5. The version in RC5 has some issues under certain 
situations. 

Unless your going to setup and use a local software repo with FDIMPLES, it 
would probably be easier to just zip up all your work and keep it around 
somewhere for later usage.

Jerome

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

Re: [Freedos-user] UDVD2 vs SHSUCDX

[Jerome Shidel]

> On Jan 18, 2022, at 10:47 AM, Michał Dec  wrote:
> 
> I used this version of OAK 
> https://www.hiren.info/download/dos-files/oakcdrom.sys 
> 
> and the problem persists. I even tried 3 different sound cards with the CDROM 
> in UDMA and PIO modes:
> - SoundBlaster AWE64 Gold
> 
> - SoundBlaster Vibra 128
> 
> - Yamaha YMF724
> 
> It took me this long, because to avoid messing up my system, I have added 
> additional modes the system can start with, besides the basic 5 present in 
> FreeDOS 1.3 RC5. My extra modes are specific for each sound card with extra 
> /K parameter for COMMAND.COM so that the drivers are up and ready as soon as 
> I receive an interactable console. I also needed to edit the Yamaha driver to 
> add support for the southbridge.
> In all 6 tests, the CD input would produce static noise, except with Vibra 
> 128. Don't even get me started on this card, it's always been an unstable 
> mess in DOS, courtesy of JEMM386.
> Any more ideas? It used to work flawlessly in FreeDOS 1.2 with SHSUCDX 
> backported from 1.3 RC that was newest like, at least a year ago. It turned 
> out back then that SHSUCDX from FD 1.2 does not support CD playback at all.
> 
There are 3 versions at 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/shsucdx.html
 


Version 3.08 & 3.08a are the same, with just NLS updated. However, there is 
also 3.07 and 3.05.

You could try the middle one. 

> So, where did things go wrong? Could it be possible that between FreeDOS 
> release candidates, SHSUCDX changed to fix the issue and then break it in a 
> new way?
> 
> Best regards,
> 
> Michał
> W dniu 16.01.2022 o 19:39, Louis Santillan pisze:
>> Not sure about the circumstances of your Rayman crash but I’ve read many 
>> posts about issues with that game on DOS. Apps that access the file system 
>> or hardware directly, disk caches can cause certain types of file 
>> corruption.  Whole file system corruption is odd and might indicate other 
>> issues (CPU, RAM, IDE controller, BIOS, drive).
>> 
>> You haven’t provided any details about your hardware.  That said, most 
>> drivers had compatibility with multiple drive makers.  And usually, you only 
>> had to specify the device “/d:xxyyzz”.
>> 
>> There’s a list of popular device drivers here.
>> 
>> https://www.hiren.info/downloads/dos-files 
>> 
>> 
>> MS used to license OAKCDROM.SYS and CD1.SYS for IDE drives.  You can find 
>> other cd rom drivers at 
>> 
>> https://www.allbootdisks.com/disk_contents/98.html 
>> 
>> 
>> I’d try to find your vendor’s driver disk in archive.org 
>>  or other vintage computing sites.
>> 
>> 
>> 
>> On Sun, Jan 16, 2022 at 5:09 AM Michał Dec > > wrote:
>> W dniu 16.01.2022 o 13:58, Eric Auer pisze:
>> > nothing worse than crashing should happen
>> > if you give the wrong answers.
>> 
>> After working with Rayman I am simply traumatized by crashing anything 
>> under DOS, because any and every crash can mean the destruction of the 
>> filesystem's integrity.
>> 
>> I'll try and get the OAK driver and let you know what happens next.
>> 
>> Best regards,
>> 
>> Michał
>> 
>> 
>> 
>> ___
>> 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 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] DN /2, File Wizard 1.35 etc.

[Jerome Shidel]

Hi Robert,

> On Jan 14, 2022, at 4:40 PM, Robert Riebisch  wrote:
> 
> Hi Jerome,
> 
>>> Any suggestions ? thankfull for advice.
>>> 
>>> 
>>> *Bear* 
>> 
>> As for installing, assuming you have the LiveCD inserted. You can run
>> FDIMPLES and select to install it. 
>> If for some reason that doesn’t work you can try installing the package
>> using FDNPKG or FDINST from the command line.
> 
> What question(s) do you answer to?
> I don't see any questions regarding the installation of FreeDOS.

In the original email, It seemed like (to me at least) he was having issues 
extracting the
DN2 zip file package. Without double checking, I think package is on the 
LiveCD, LegacyCD, 
Full USB and BonusCD. Which means he can put the CD in and run FDIMPLES to 
install that
package. Or, even use FDNPKG or FDINST to install it. Neither FDIMPLES or 
FDINST require
XMS or large amounts of RAM. And unlike UNZIP, they do not require a 386 
either. 

This of course has little to do with whatever was causing JEMM to crash. But, 
could possible
help install the package. 

Then again, maybe I misread the problem he was having. 

> 
> Cheers,
> Robert
> -- 

Jerome



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

Re: [Freedos-user] DN /2, File Wizard 1.35 etc.

[Jerome Shidel]

Hi,

> On Jan 13, 2022, at 6:19 AM, Björn Morell  wrote:
> 
> 
> (New try without attached BMP)
> Hi I am a new here.
> 
> I am testing what can be done on a IBM Value Point M# 6482  100DX4 whith 
> 3c509 and SB16-
> 
>  Have among other OSs Freedos 1.3 RC5 and am testing file managers, allways 
> used Norton Commander but now my favorit is FW  (File Wizard) DN2 would 
> probably been cause of scroll wheel handling but I have problems with DN2, 
> first on command line it dos not take aliases as it dos not use 4dos which is 
> my COMSPEC, second when trying to extract zip file I get Jemmex: exception 0D 
> "Dos Navigator Open Source Project
> 
> Dos/32A warning (9002): PICs have been relocated to INT D8h, INT 70h
> 
> Dos Navigator /2 OpenSource 2.14 beta/D32 Based on DN by RIT Labs
> 
> 
> PKUNZIP (R) FAST! Extract Utility Version 2.50 03-01-1999
> 
> Copr. 1989-1999 PKWARE Inc. All Rights Reserved. Registered version
> 
> PKUNZIP Reg U.S. Pat. and Tm. Off.
> 
>  80486 CPU detected
> 
>  XMS version 3.00 detected.
> 
> 
> Jemmx: excepton 0D occured at CS:EIP=00D9:DC28, ERRC=
> 
> SS:ESP=2FF9:CC86 EBP=CCB8 EFL=00033006 CR0=8011 CR2=
> 
> EAX=0031 EBX= ECX= EDX=0005 ESI=BBA2 EDI=0005
> 
> DS=2FF9 ES=CCB8 GS=ECD3 [CS:IP]=67 A0 31 00 67 B0 31 00"
> 
> Any suggestions ? thankfull for advice.
> 
> 
> Bear

As for installing, assuming you have the LiveCD inserted. You can run FDIMPLES 
and select to install it. 
If for some reason that doesn’t work you can try installing the package using 
FDNPKG or FDINST from the command line.

Jerome

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

Re: [Freedos-user] DOSHEXED - memory bug

[Jerome Shidel]

Hi, 

> On Jan 12, 2022, at 8:58 AM, Michał Dec  wrote:
> 
> Hi everyone,
> 
> I'm trying to edit different files with DOSHEXED from FreeDOS 1.3RC5 CD and 
> it's just disappointing. This editor will complain it's out of memory if 
> we're trying to open a file that won't entirely fit into the leftover 
> conventional memory (<1MiB). I tried editing LOTUS.DAT (approx 1.4MB, from 
> Lotus 3: The Ultimate Challenge) and Stargunner's SETUP.EXE. Luckily the 
> second one fits, given you don't load too many drivers in DOS. Is there any 
> other hex editor for FreeDOS, which works a lot better?
> 
> Best regards,
> 
> Michał

Don’t know about feature comparison. But, UHEX works well enough for most of 
the stuff I need from a hex editor.

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

Re: [Freedos-user] DJGPP (was Re: FYI: Social media URLs updated)

[Jerome Shidel]

DJGPP has not been updated in a while for a couple reasons. 

I have nothing against it. But, I don’t use it. 

There are numerous pieces. Which aren’t needed? What relies on other things? 
Which are the most popular? Which should be included? 

I look at that large collection of components and have only a vague idea of 
what is what. I could spend hours, days or weeks working on updating them. But, 
would have no idea if the end result would even be usable by anyone. 

It needs to be updated by someone who uses it. No one has volunteered to 
provide those updated versions. 

I have too many other things to do and will not spend the time figuring it out. 
Maybe someday I’ll work on updating it. But, I don’t see that happening anytime 
in the foreseeable future.

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

Re: [Freedos-user] Free? Games

[Jerome Shidel]

Hi,

> On Jun 13, 2021, at 10:38 AM, Rafael Angel Campos Vargas 
>  wrote:
> 
> Two new free 2020 games of mine with Freedos version (freepascal without 
> sound for now, i am working on it but it is complicated). Both of them are 
> some simple.
> 
> Aventura trivial only have spanish version 
> https://juegosenlazaruscr.itch.io/aventura-trivial-ciencias7 
> . It is a 
> trivia game.
> 
> What is it? Is very simple but it has english version (it was a game made for 
> a Dos JAM). https://juegosenlazaruscr.itch.io/what-is-this 
>  It is about stereograms.
> 
> Actually I am working on a 4 minutes video for a video jam of a year of 
> duration. I am the host of the jam. You could look fot the details on the 
> links above.

I took a while for me to get around to looking at them.

Unfortunately, I wasn’t able to try them. 

When I go to the page, all I see is “Download - name your price” and the url 
itself contains to “purchase"

Maybe I’m wrong about this. But to me, this implies they are not free. Nor, can 
they be freely redistributed. 

If they can be freely redistributed, I have no problem putting them on my 
unofficial repo https://fd.lod.bz/repos/current/pkg-html/ 
 

However, for me to put them on the Official FreeDOS repo at 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/
 

 , they would need to be open source. Open source is also required to be 
considered for inclusion on future releases of FreeDOS install media or bonus 
cd.

:-)

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

Re: [Freedos-user] FreeDOS 1.3 RC5 error when installing

[Jerome Shidel]

> On Dec 27, 2021, at 9:19 PM, Pyros  wrote:
> 
> http://www.bttr-software.de/forum/img/uploaded/image24.jpg 
> 
> 
> while installing freedos 1.3 rc5 i get the error that you see in the image. 
> Now this is not your modern pc it's from the win 98/me days as it does have 
> isa slots and has an SB16 with attached wave blaster. It is a pentium machine 
> if that helps.
> 
>  
> 
>  Virus-free. www.avg.com 
> 
>  
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

I have seen a similar issue when installing to netbook using the USB stick. 
There was no problem installing FreeDOS 1.2 on that machine using USB. Very 
little (if anything) has changed in those areas of the installer since 1.2. 
However, many things the installer relies upon have been updated. For example, 
Kernel, FreeCOM, Drivers, FDISK, etc. have all been updated. With these issues 
only seem to be occurring on real hardware, it will take a little time to 
narrow down the cause either resolve the issue and/or notify the appropriate 
developers. ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] FDIMPLES support for BonusCD

[Jerome Shidel]

Hello All,

> On Dec 19, 2021, at 2:58 PM, Radek Krzyśków  wrote:
> [..]
> 
> 1) How to use `FDIMPLES` with Bonus CD?
> 
> Running `FDIMPLES` with "FD13BNS.ISO" shows "Package media not
> found!", so I install additional software by manually unpacking ZIPs.
> `FDIMPLES` only recognizes "FD13LIVE.ISO" and I don't know how to
> enable it with the Bonus CD packages.


With all the recent and last minute changes, I completely forgot to make sure 
FDIMPLES worked with the BonusCD prior to releasing RC5. Not that it matters. 
But basically, changes to that CD caused it to drift slightly out of compliance 
to how FDIMPLES identifies local package sources. 

Anyhow...

I’ve just updated FDIMPLES to version v0.11.2. It now has better support for 
such things and works the BonusCD. Of course, the new version will be on the 
next OS release. Nut, you probably don’t want to wait until then. 

You can download it directly from the Official FreeDOS repository on ibiblio at:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/fdimples.html
 


Or, from my personal FreeDOS repo at:
https://fd.lod.bz/repos/current/pkg-html/fdimples.html 


Or, even from the GitLab Archive at:
https://gitlab.com/FreeDOS/apps/fdimples 


Or, if you have networkings support in you installation of FreeDOS, you should 
be able to just run:
fdnpkg update fdimples

:-)

Jerome

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

Re: [Freedos-user] FreeDOS and LFN

[Jerome Shidel]

Hi Joseph,
 
> I do notice that the dir command doesn’t seem to display them, and I saw 
> nothing in the help for dir about lfn’s.

I keep thinking about doing a new directory lister. I’ve never been fond of the 
DOS one. It’s been decades since the last version of my D.EXE program. If I 
ever find the time, I’d make a new one with LFN support. Someday. Hopefully.

:-)

Jerome

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

Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5

[Jerome Shidel]

> On Dec 18, 2021, at 4:19 PM, Darik Horn  wrote:
> 
>> That starts to get complicated when trying to just use a program like UNZIP. 
>> At nearly 200K for just the binary,
> 
> The unzip-5.52 binary in the repack is 50,229 bytes.  Which versions
> are you using?

The latest version we have 6.0. 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unzip.html
 


It is a 1.6m package with Sources.
It is 132K compressed without sources.
The Binary is 192.5K uncompressed.

It is not 8086 compatible and requires DPMI. So That is another 20.8K. 
So, just for the current UnZIP and CWSDPMI binaries about 220K is required.

> Compare versus 27,814 + 39,910 = 67,724 bytes for slicer and gzip in
> FreeDOS 1.3-RC5.
> 

I think that could be a little mis-leading. 

For this reason… At present, both UnZip and Gzip are installed on 386+ 
machines with the FloppyEdition. So, their overall size is not very important.
What does matter is the amount of space required on the boot/install diskette.
Whether UnZip needs 220k or 50k, that is still bigger than 27k needed by 
Slicer. Gzip, is not on the boot disk. It is first in the archive and extracted 
by Slicer. Slicer then begins using it automatically. So, the size of GZip
is not relevant. Actually, a few kbytes could be squeezed out of the archive
by splitting Gzip into 2 pieces. The first piece would be just the 8086 EXE.
The second piece could then be compressed with the 386 version and 
everything else in the current Gzip package. 


> 
>> But, for your tests. They should be split at the same size 59K for user 
>> diskette compatibility.
> 
> Why is this the right size?  The current slice size of 60,416 bytes
> doesn't have a filesystem overhead, which seems intentional, but it
> isn't apparent how the end-user benefits.

In Part, the RBE only needs to create one Archive (using DOS), then
it can just spread it out across the different media quickly using Linux.
It is also less code in the RBE. The User benefits by not only getting 
a single 1.44mb version. 

The 59k slices spread nicely across the different media.

720k only 3k remaining.
1.2mb only 4.5k remaining.
1.44mb only 6.5k remaining.

Intent is also to eventually do a little restructuring of the boot disk
and installer to allow provide 360k version as well. But, that is an 
extremely low priority. It would have around 1-2k free space 
remaining.

The smaller slice size also allows the usage of not 100% healthy 
disks that have had bad sectors mapped out. You would need to
know how to do that and manually copy the slices. But, it is still
an option.

> 
> I'm getting better results with larger files by doing this...
> 
> In a 1.44MB image, a default "format a:" has 1,457,664 bytes usable,
> less directory overhead and cluster slack of a few kilobytes.  (eg:
> The FreeDOS boot disk.)
> 
> If I tune the image with "mformat -c4 -r1 a:" and put one big file
> inside, then I get an additional 12,800 bytes of payload space, am
> guaranteed to get zero directory overhead and zero cluster slack, and
> get maximum throughput from the floppy drive.
> 
> This savings won't always matter, but it is the reason why the
> ZipSplit build has one fewer disk than the Slicer build.
> 
>> I don’t feel a couple percentage points better compression work the time and 
>> testing to
>> make large changes to the FloppyEdition installer. But, it’s not like it 
>> cannot be changed.
> 
> This is reasonable given how late it is in the release cycle, and the
> gzip enhancement is indeed good.  

I think the level of compression provided with pass-through Gzip is 
“good enough”. An overall performance is on par with MS-DOS.
A recent test install of MS-DOS onto my Pentium-Pro took roughly 
5-6 minutes to copy and extract the DOS files from floppy. Installing
RC5 from floppy to an Intel Atom based Netbook took about 7-8 
minutes to extract the 5 diskettes of FreeDOS packages. There are 
numerous hardware difference between the two machines. So, it
was not a benchmark speed test. But, does show it takes a similar
about of time per disk. 

There would need to be a very large improvement in compression
to make it worthwhile in adding additional overhead or just reworking
the portion of the RBE that creates the FloppyEdition.

The RBE was a lot of work to create. It fully automates the creation of
a release. Basically, anyone can follow the directions in the wiki and
create a HOST VM for the RBE. Use git to checkout the RBE. Then
run install as sudo/superuser to configure the system automatically.
Once that is done, to create a release… type “make” and hit enter.
Go to lunch, come back you’ve got a FreeDOS release with the 
latest packages, in all the various formats that is ready to send out
the door. 

By no means is the RBE perfect. This is version 3 and it may have a 
couple minor 

Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5

[Jerome Shidel]

> On Dec 18, 2021, at 11:43 AM, Darik Horn  wrote:
> 
> Jerome,
> 
>> Did your repack include ALL packages included in the FloppyEdition not just 
>> i386.
> 
> Yes, the repack contains 1,177 files.
> 
> 
>> For example, VirtualBox and VMWare include FDNet as well as the set for 386s.
> 
> Note that these things have empty categories in the official build, per below.

Technically correct. 

When the installer sees it is running on a VM, it includes a tag for that VM.
That tag doesn’t have any correlation in the archive at present. 

But, when the installer sees it is running on VirtualBox or VMWare, it also
throws in the Network Tag. Which includes FDNet. And possible other
network based programs in the future. 

In theory, we could include a SOURCE tag that would then include the
appropriate sources. But, that would needlessly bloat the FloppyEdition. All 
the sources are available on the CD/USB media and online. So, there is no need
to waist space with them on the diskettes.

The TAG system and hardware detection, may be expanded in the future to 
include things like Mouse, Joystick, Printer, etc. 

Each program is also tagged with it’s name. That way if someone for some reason
wanted to extract just that program, they can. But the installer doesn’t use 
those 
TAGS either. 

I just remembered, there is one inefficiency in the archive that is not related 
to
SLICER itself and would account for more of the %5 difference to ZIP. Basically,
the RBE creates a fake package called FDINST specifically for machine that 
cannot support 386 or better programs. FDINST is part of FDNPKG. At present,
the RBE includes two packages FDINST and FDNPKG. At some point, it will
be told to handle that differently. At present, the files related to FDINST are 
in the
the archive twice. It is not a SLICER issue, just something I haven’t got 
around to
make the RBE build the archive more efficiently.

> 
>> Does it make any accommodations for different hardware?
> 
> Yes, the hardware detection logic is unchanged.
> 
> 
>> Or just install everything wether or not it is supported by the target 
>> platform?
> 
> In the RC4 repack, yes, the @LISTFILE method is equivalent to the
> "slicer /g" switch.
> 
> In the RC5 repack, no, it just does the same thing as "/g *".
> 
> //
> 
> Two unexpected results from the second experiment are:
> 
> * The tarball method isn't worthwhile, despite using a solid archive format.
> * The InfoZIP zipsplit method is better than the PKZip spanning method.

This made me think of another thought…

For maximum diskette capacity compatibility (and not requiring the end user to 
re-split an archive),
slicer is using 59K slices. That size wastes only a little space on 360K,720K, 
1.2M, 1.44M. It would also 
be workable on smaller sizes. But no-one is going to use a 120K diskette. It’s 
doubtful anyone will ever
try to use 360K or smaller diskettes. But, if they are lucky enough to have the 
hardware and diskettes, a 
user may want to stick the release on a couple 2.88M diskettes.

But, for your tests. They should be split at the same size 59K for user 
diskette compatibility.

Also, you be sure to consideration the extra space required for the archiver. 
Some are quite large. Slicer
gets around that problem. The first thing it extracts is GZIP which is 
uncompressed in the archive. 
Everything after that is Gzip compressed. 

That starts to get complicated when trying to just use a program like UNZIP. At 
nearly 200K for just the binary,
it won’t fit on the 720k boot diskette. At present, that diskette has only 120K 
free and that may be reduced
somewhat as well. There have been requests to add very useful programs like 
EDIT to that boot diskette.

> 
> //
> 
> In the official FreeDOS 1.3-RC5 floppy edition, %TTAGS% for things
> like networking and virtualization are empty.  When I manually unpack
> FREEDOS.SAF, I get these categories and file counts:
> 
> 186: 919
> 286: 1027
> 386: 1155
> 486: 1155
> 586: 1155
> 686: 1155
> 8086: 919
> 8088: 919
> AMBHELP: 11
> AMBREAD: 7
> APPEND: 14
> ASSIGN: 17
> ATTRIB: 11
> CALLVER: 6
> CGA: 807
> CHKDSK: 6
> CHOICE: 33
> COMP: 7
> CPIDOS: 27
> CTMOUSE: 34
> CWSDPMI: 14
> DEBUG: 17
> DEFAULT: 0
> DEFRAG: 7
> DELTREE: 11
> DEVLOAD: 9
> DISKCOMP: 7
> DISKCOPY: 19
> DISPLAY: 10
> EDIT: 10
> EDLIN: 40
> EGA: 1177
> EXE2BIN: 13
> FC: 26
> FDAPM: 9
> FDHELPER: 26
> FDIMPLES: 16
> FDINST: 5
> FDISK: 26
> FDNET: 20
> FDNPKG: 21
> FDXMS: 13
> FDXMS286: 12
> FIND: 27
> FORMAT: 13
> FREECOM: 48
> FREEDOS: 1177
> GRAPHICS: 11
> GZIP: 11
> HIMEMX: 10
> JEMM: 24
> KERNEL: 26
> KEYB: 10
> KEYB_LAY: 25
> LABEL: 13
> LBACACHE: 13
> MEM: 19
> MIRROR: 16
> MKEYB: 10
> MODE: 8
> MORE: 33
> MOVE: 19
> NANSI: 8
> NETWORK: 20
> NLSFUNC: 11
> PRINT: 7
> RECOVER: 7
> REPLACE: 9
> SHARE: 6
> SHSUCDX: 8
> SHSUFDRV: 12
> SORT: 21
> SWSUBST: 7
> TREE: 22
> UDVD2: 7
> UNDELETE: 11
> UNFORMAT: 12
> UNZIP: 11
> V8POWER: 144
> VGA: 1177
> XCOPY: 19
> ZIP: 18

Interesting. 

I don’t feel a couple 

Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5

[Jerome Shidel]

Hi Darik, 

Quick questions…

Did your repack include ALL packages included in the FloppyEdition not just 
i386. For example, VirtualBox and VMWare include FDNet as well as the set for 
386s.

Does it make any accommodations for different hardware? Or just install 
everything wether or not it is supported by the target platform?


> On Dec 17, 2021, at 3:36 PM, Darik Horn  wrote:
> 
> 
> Hi all,
> 
> Pursuant to earlier feedback, three new FDI-x86 repacks are available here:
> 
> https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing
>  
> 
> 
> 1. floppies@2021-12-16/FD13RC5-FloppyEdition+ZIP.zip
> 
> This build uses ZipSplit instead of Slicer.
> 
> Output size is similar to slicer-0.17 with the gzip enhancement.  Performance 
> is slightly better because decompression does not use temp storage.  The 
> payload in each floppy disk is a regular ZIP file that can be opened on a 
> desktop computer.
> 
> 
> 2. floppies@2021-12-16/FD13RC5-FloppyEdition+TGZ.zip
> 
> This build is a split tarball.
> 
> I tried various sort orders, and ran it through zopfli, but this build is 
> only 5% smaller than the ZipSplit or Slicer builds.  It uses temp storage 
> equal to the payload size.

That would make sense. At present, Slicer is using GZip for pass-through 
compression. 

There is some additional overhead for the TAG/Group management, embedded text, 
using smaller files to prevent the need to resplit for different size diskettes 
and a couple other minor things. 

> 
> 
> 3. floppies@2021-12-16/FD13RC5-FloppyEdition+RAR.zip
> 
> This build uses UnRAR and needs a non-free encoder.
> 
> The multivolume RAR is half the size of any other archive format, so it is 
> the benchmark for what can be accomplished with 16-bit code on a machine with 
> 1 megabyte of memory.
> 
> Big savings come from a large dictionary and solid packing, so perhaps 7ZDEC 
> can be enhanced to get a similar result.
> 
> 
> * Bundled WIL Files
> 
> The dists have INI files that can be double-clicked to open WinImage, or used 
> to create a SFX media writer for Microsoft Windows.

Interesting. There are other compression methods to try. For example, lzma, 
bzip2, arj, etc. 

On a side note… 

Support for those and more could be added to Slicer. Slicer is not locked into 
a single compression method for the entire archive. It would have no problem 
extracting one file using GZip, then the next file with Bz2, etc. In theory, it 
could be told to try different methods when adding files to the archive and 
then use the one that compressed the most.

Just saying. :-)

Overall, I think using GZip for the pass-through compression works well enough, 
supports 8086 and uses little space. 

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] slicer-0.17 error code #2

[Jerome Shidel]

Hi,

> On Dec 16, 2021, at 1:49 PM, Darik Horn  wrote:
> 
> NB: https://gitlab.com/DOSx86/slicer/-/merge_requests/1
> 
> There seems to be a related bug with /e and /i handling, which are
> no-ops on my test machine.

Could be. 

Originally, those switches we designed for mostly creating an archive. I do 
recall thinking it would be nice to have for extraction. However, I’m working 
on so many things now and over the last few years, I don’t recall how much work 
or testing I did to support that. I may have just though “that would be nice, 
but it can wait”. I honestly don’t recall if those do anything on extraction 
right now.  

One such “it can wait until later” involves the pass-through compression. NLS 
file 
https://github.com/shidel/fd-nls/blob/1684a5dfc06bab972e5774917e0e93af4ab7335c/slicer/nls/SLICER.EN#L143
 

 entry it is meant to support more than just gzip.  I went with gzip first 
because it’s small and 8086 compatible. But now that it does at least one, it 
could easily have others added. Like maybe (bz2, p7zip, etc). It wouldn’t take 
much to add them. I just don’t really have the time to do it.  

There are tons of improvements it could use. 

:-)

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] slicer-0.17 error code #2

[Jerome Shidel]

> On Dec 15, 2021, at 7:05 PM, Darik Horn  wrote:
> 
>> Please post a bug report at https://gitlab.com/DOSx86/slicer
> 
> NB:  https://gitlab.com/DOSx86/slicer/-/issues/1
> 
> 
>>> On DOSBox-X, slicer will fail on random files in a way that looks like a 
>>> race condition.
>> 
>> Under the same situation?
> 
> Yes.

Ok. 

Yep, It probably just needs a test put in at 279 
 
before trying to decompress the non-existing, not extracted file.

:-)


> 
> ___
> 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] slicer-0.17 error code #2

[Jerome Shidel]

Hi Darik

> On Dec 15, 2021, at 5:11 PM, Darik Horn  wrote:
> 
> Hi,
> 
> In FreeDOS 1.3 RC5, the new slicer handles file overwrites inconsistently in 
> interactive mode.  Reproduce the bug by doing this:
> 
>   C:\> SLICER /x /f \SLICES\FREEDOS.SAF /g * /O OUT
>   ...
>   Overwrite BIN\FDINST.EXE, (N)o/(Y)es? N
>   
>   gzip: EGA\BIN\ID583S8Q.GZ: not in gzip format
>   FATAL ERROR: error code #2, unspecified error with "EGA\BIN\ID583S8Q.GZ"
> 
> Expected behavior is that SLICER skips the current file and finishes the 
> extraction.
> 
> SLICER behaves as expected on a "Y" input, or in non-interactive mode with 
> the /o switch.
> 
> The given glob expresses the bug on the first call.  If slicer is invoked 
> with a smaller category like "/g Network", then the bug happens on the second 
> call.
> 
> On FreeDOS 1.3 RC5, slicer will always return error code #2 in the same place.

Error 2, means file not found. 

I think I may know what is happening. The addition of pass-thru compression 
support for gzip was added a couple days prior to release of RC5. And was only 
tested in automatic overwrite mode. What I think is probably happening is that 
after you tell it no, it still is trying to pass a non-extracted file to gzip 
which reports an error and extraction stops. I’ll need to look into it. Please 
post a bug report at https://gitlab.com/DOSx86/slicer 
 or on the FreeDOS GitLab Archive at 
https://gitlab.com/FreeDOS/archiver/slicer 
 . That way I don’t forget to take 
care of the issue.

> On DOSBox-X, slicer will fail on random files in a way that looks like a race 
> condition.

Under the same situation?

Jerome

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

[Freedos-user] FreeDOS 1.3-RC5

[Jerome Shidel]

Hello FreeDOS Community,

The wait for 1.3-RC5 is over. It has arrived!

There are so many changes, improvements and updates that it is not practical to 
go into it all. But, I’ll point out a couple special things to look forward to 
in RC5.

New FreeCOM 0.85a
New Kernel 2043 and an 8086 version with FAT32 support.
FloppyEdition now uses compression and requires about 1/2 as many diskettes.
The return of FDNet
Some new programs and games.
Many many many package updates.
Some updates and improvements to NLS.
Better handling of if/when to overwrite the MBR. 
Some support to automatically set the COUNTRY.SYS information.
Improved CD initialization for the boot media and installed system.
much, much more.

As discussed during the online get-togethers, we intend to eventually move bug 
reporting from SourceForge over to the https://gitlab.com/FreeDOS 
 group page on GitLab. Around the release of 
1.3-Final, we will probably freeze reporting on SourceForge entirely. This will 
not effect the mailing lists. Only bug reporting will be affected. 

With the GitLab pages being the first stop to report bugs, a contributor can 
see all the projects related to FreeDOS. Also if that project is actively 
maintained elsewhere, there is a prominent link to point them at the developers 
website for reporting issues. 

Release announcement on the Website and places like Facebook will be made at a 
later time. But, you can go ahead and grab RC5 from the Official FreeDOS 
download site at 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc5/
 

 or from my server at https://fd.lod.bz/releases/1.3/previews/1.3-rc5/ 
 .  

:-)

Jerome


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

Re: [Freedos-user] Question about FreeDOS 3.0

[Jerome Shidel]

Hmmm, I should get one. It would save me a lot of work. 


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

Re: [Freedos-user] How to redirect STDOUT and STDERR to file

[Jerome Shidel]

If all you want is a list of files and directories in a directory…

veach /a+ /d *.* /l >out.txt

VEACH is part of V8Power Tools that comes with FreeDOS. However, there have 
been important updates to V8Power Tools since the 1.3-RC4 release. I recommend 
updating the version you have to the latest one available at 
https://fd.lod.bz/repos/current/pkg-html/v8power.html 
 or just waiting for 
FreeDOS 1.3-RC5 to be released very soon. 

Since a list of files is not very useful by itself, you can have veach perform 
commands on them. For example, if you want just executable files (and no 
directories) and to perform some kind of action, you could use:

veach /a- /d *.com /d *.exe /d *.bat /s /x SOMETHIN.BAT * 

That would provide a sorted list of COM, EXE and BAT files and run SOMETHIN.BAT 
with each one.

Kinda like

SOMETHIN.BAT PROG1.EXE
SOMETHIN.BAT PROG2.COM
SOMETHIN.BAT PROG3.BAT
SOMETHIN.BAT PROG3.EXE
etc.

Or...

You can use an alternate directory listing program. Like my ancient D.EXE ( 
https://github.com/shidel/DustyTP7/blob/master/bin/D.EXE 
 ). It has several 
view options including meant for output to file.

:-)

Jerome

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

Re: [Freedos-user] SvarCOM - a nimble COMMAND.COM shell

[Jerome Shidel]

Hi Mateusz,

> On Nov 24, 2021, at 12:51 PM, Mateusz Viste  wrote:
> 
> Hello all,
> 
> I tend to use FreeDOS mostly on old computers that often have no more than 1 
> MiB of RAM. On such setups FreeDOS doesn't leave much memory to applications, 
> mostly due to FreeCOM.
> 
> This is the main reason that led me to develop a new command interpreter 
> named SvarCOM. This interpreter will soon become the standard shell of the 
> SvarDOS distribution. It's resident size is under 2K.
> 
> Today I published the first version of SvarCOM, version 2021.0. This version 
> must be considered as a "functional preview", since there are still a few 
> things missing. It is stable, though, and what is implemented works pretty 
> well. I use it since a few days on my museum-grade machines without major 
> troubles. The most annoying thing is probably the lack of an INT 24h handler: 
> it may lead to surprising results if one tries to access an empty floppy 
> drive.
> 
> While I developed SvarCOM specifically for the SvarDOS distribution, it works 
> just as well on plain FreeDOS. As such, the FreeDOS project is welcome to 
> mirror it or use it as an alternative shell, should that be of any interest 
> to the community.
> 
> Read more on http://svardos.osdn.io/svarcom/
> 
> Mateusz

Kinda busy right now, don’t know when I’ll get around to testing it. But, I did 
turn it into a package already. :-)

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


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

Re: [Freedos-user] FreeDOS game compatibility mass testing results/questions

[Jerome Shidel]

I have Wolfenstien 3D. It’s been a while. But, I’m fairly sure I’ve run on top 
of FreeDOS. I’ll need to check when I have the time.

I also have a couple PQ and other Sierra games laying around. I think most of 
them worked without issue. But, again it’s been a while. 

I do recall that Battle Chess (CD version) requires EMS. So, the default config 
needs changed to get it to run. 


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

Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik, 

One more thing…

The “workflow” for packages…

I download, restructure, compile, etc. the software.

It then gets staged in completely uncompressed package format as a project at 
https://gitlab.com/FDOS 
(The  sub-groups & projects there will probable be moving to 
https://gitlab.com/FreeDOS/  in the near future)

Once that is done, I zip it up using a older script I wrote a while back. 
(eventually, I’ll add support to do it to the fdvcs.sh script)

Then upload that to my personal repository.

The repo management utilities run on it hourly and will tweak a couple meta 
data fields and place in it’s repo at
https://fd.lod.bz/repos/current/pkg-html/ 


Once it appears in that repo. I download the package from my server and upload 
it to ibiblio.

The repo management utilities run on daily. It will see the metadata fields in 
the package are already modified and 
just put it in the official repository at 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/
 


(This ensures that for the packages in both locations (more on my personal 
server) are identical and hash the same)

Then we come to making a release.

The RBE downloads the latest CDROM.ISO from ibiblio (created by the repo 
management utility) and does a bunch of 
stuff to the packages. Including integrating some NLS stuff from the NLS 
project at https://github.com/shidel/fd-nls 

Finally, the RBE zips those up and produces the release media.

Although with the recent addition of package staging at GitLab and several 
other things, I think a lot of the processing
done on packages in the RBE is going to go away and move further up the chain 
to the package prep stage.

:-)

Jerome





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

Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

Also...

> On Nov 16, 2021, at 1:00 PM, Darik Horn  wrote:
> [..]
> This bash script does the same thing.  The file is also in the shared
> folder in case the listserv mangles it here.  I will submit PRs for
> additional work now that I know about the Gitlab account.

FYI, I still need to make some updates to the RBE to account for some changes 
coming in RC5. 

And it could use improvement in several areas and tons of optimization. But, it 
works and I’ve only got
so much time to spend on it, the installers, required tools, etc.

> #!/bin/bash
> # fdrepack.sh: FreeDOS repository repacking script.
> 
> fdrepack ()
> {
>  TMPDIR=$(mktemp -d)
>  pushd "$TMPDIR" >/dev/null
>  unzip -q "$1"
> 
>  if [[ -d 'SOURCE' ]]
>  then
>pushd 'SOURCE' >/dev/null
>for ii in *.7[Zz]
>do
>  if [[ -r "$ii" ]]
>  then
># Force the source package name to uppercase.
>mkdir $(basename "${ii@U}" '.7Z')
>pushd $(basename "${ii@U}" '.7Z') >/dev/null
>7z x "../$ii"
>popd >/dev/null
>rm "$ii"
>  fi
>done
>for ii in *.[Zz][Ii][Pp]
>do
>  if [[ -r "$ii" ]]
>  then
># Force the source package name to uppercase.
>mkdir $(basename "${ii@U}" '.ZIP')
>pushd $(basename "${ii@U}" '.ZIP') >/dev/null
>unzip -q "../$ii"
>popd >/dev/null
>rm "$ii"
>  fi
>done
> 
>for ii in *
>do
>  if pushd "$ii" >/dev/null
>  then
># Unpack and delete old LFN source archives.
>find -maxdepth 1 -type f -iname sources.7z -exec 7z x {} \;
> -exec rm {} \;
>find -maxdepth 1 -type f -iname sources.zip -exec unzip -q {}
> \; -exec rm {} \;
># Using the store method here makes upstream sources solid in
> the package zip.
>zip -0Xoqr "../${ii@U}.ZIP" .
>popd >/dev/null
>rm -rf "$ii"
>  fi
>done
>popd >/dev/null
>  fi
> 
>  # Use InfoZIP here for the -k and -o switches.
>  zip -0Xkoqr "${1}.repack"
>  advzip -k -p -z -3 -i 15 "${1}.repack"
>  mv "${1}.repack" "${1}"
>  popd >/dev/null
>  rm -rf "$TMPDIR"
> }
> 
> export -f fdrepack
> find ~+ -type f -iname \*.zip -exec bash -c 'fdrepack "{}"' \;
> 

Just some notes on the script. Overall, it looks fine. I did not go through 
each switch. But, I assume they are correct.

ibiblio is the official repo, OS download site and software mirror server. It 
is graciously hosted by the University of
North Carolina. Neither 7zip or advzip are installed on that server. Installing 
linux packages is out. However, we can 
and do run some “mission critical” binaries. So, depending on dependencies we 
could run them. 

${var@U} is not supported by bash on ibiblio, nor the version on my Mac (where 
I run a lot of this stuff for prep, testing, etc).
ibiblio does support ${var^^}, however the Mac doesn’t. So, basically for 
compatibility I end up using some functions that
work on both. (yes, I know they don’t support international characters.)

[[ "$(uname)" == "Darwin" ]] && MACOS=true || unset MACOS
UPPER_CHARS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
LOWER_CHARS='abcdefghijklmnopqrstuvwxyz'

function lowerCase () {
if [[ ${MACOS} ]] ; then
# Slower method not using ${variable,,}
local i c o
for ((i=0;i<${#1};i++)) ; do
c="${1:${i}:1}"
if [[ "${c//[${UPPER_CHARS}]}" != "${c}" ]] ; then
c="${UPPER_CHARS%%${c}*}"
c="${LOWER_CHARS:${#c}:1}"
fi
o="${o}${c}"
done
echo "${o}"
else
echo "${1,,}"
fi
}

function upperCase () {
if [[ ${MACOS} ]] ; then
# Slower method not using ${variable^^}
local i c o
for ((i=0;i<${#1};i++)) ; do
c="${1:${i}:1}"
if [[ "${c//[${LOWER_CHARS}]}" != "${c}" ]] ; then
c="${LOWER_CHARS%%${c}*}"
c="${UPPER_CHARS:${#c}:1}"
fi
o="${o}${c}"
done
echo "${o}"
else
echo "${1^^}"
fi
}

Obviously, they are no where near as fast as the built-in shell versions. 
But generally, are much faster than using tr “[:lower:]” “[:upper:]” and the 
like.
Technically, since using them through a sub-shell like fname=$(upperCase 
“${oname}”) 
it doesn’t really need to declare the vars as local.

Archive timestamps are lost. While technically a new zip file, it may be more 
useful to apply
the old archives timestamp to the new one. It is not difficult. I do something 
like that in the 
fdvcs.sh script (part of the PkgDevKit, another work in progress). It is just 
something that
we will need to consider.

While it would be good to reduce the sizes of the zip archives, there is 
currently plenty of 
room on the different release media. At present, I have several dozen critical 
things that
need done for RC5. After RC5, I will look into it more.

One area that could use volunteers now is package updates. There are roughly as 
dozen
BASE packages 

Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

> On Nov 16, 2021, at 1:01 PM, Darik Horn  wrote:
> 
> Jerome,
> 
>> First, the new versions would need to be checked to ensure compatibility. 
>> They would probably be fine. But, testing would still need done. I honestly 
>> just done have the time for that at present.
> 
> This work is, in part, the result of doing coverage testing on the 
> distribution.
> 
> 
>> But, I think it is to late to consider such a large unplanned change this 
>> close to the release 1.3-RC5.
> 
> Note that this fixes the fails-to-install-all-packages-with-source bug
> in the latest release candidate.

No. 

The package for HTMLHELP used a source directory as HELP which conflicted with 
another package. I’ve corrected the package on the repository. So, there is no 
longer a conflict.

>> I appreciate the effort you put into creating a PowerShell script to repack 
>> the repository. However, I do not know if we are going to do that.
> 
> This bash script does the same thing.  The file is also in the shared
> folder in case the listserv mangles it here.  I will submit PRs for
> additional work now that I know about the Gitlab account.
> 
> 
> #!/bin/bash
> # fdrepack.sh: FreeDOS repository repacking script.
> 
> fdrepack ()
> {
>  TMPDIR=$(mktemp -d)
>  pushd "$TMPDIR" >/dev/null
>  unzip -q "$1"
> 
>  if [[ -d 'SOURCE' ]]
>  then
>pushd 'SOURCE' >/dev/null
>for ii in *.7[Zz]
>do
>  if [[ -r "$ii" ]]
>  then
># Force the source package name to uppercase.
>mkdir $(basename "${ii@U}" '.7Z')
>pushd $(basename "${ii@U}" '.7Z') >/dev/null
>7z x "../$ii"
>popd >/dev/null
>rm "$ii"
>  fi
>done
>for ii in *.[Zz][Ii][Pp]
>do
>  if [[ -r "$ii" ]]
>  then
># Force the source package name to uppercase.
>mkdir $(basename "${ii@U}" '.ZIP')
>pushd $(basename "${ii@U}" '.ZIP') >/dev/null
>unzip -q "../$ii"
>popd >/dev/null
>rm "$ii"
>  fi
>done
> 
>for ii in *
>do
>  if pushd "$ii" >/dev/null
>  then
># Unpack and delete old LFN source archives.
>find -maxdepth 1 -type f -iname sources.7z -exec 7z x {} \;
> -exec rm {} \;
>find -maxdepth 1 -type f -iname sources.zip -exec unzip -q {}
> \; -exec rm {} \;
># Using the store method here makes upstream sources solid in
> the package zip.
>zip -0Xoqr "../${ii@U}.ZIP" .
>popd >/dev/null
>rm -rf "$ii"
>  fi
>done
>popd >/dev/null
>  fi
> 
>  # Use InfoZIP here for the -k and -o switches.
>  zip -0Xkoqr "${1}.repack"
>  advzip -k -p -z -3 -i 15 "${1}.repack"
>  mv "${1}.repack" "${1}"
>  popd >/dev/null
>  rm -rf "$TMPDIR"
> }
> 
> export -f fdrepack
> find ~+ -type f -iname \*.zip -exec bash -c 'fdrepack "{}"' \;
> 
> 
> ___
> 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] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

> On Nov 15, 2021, at 5:08 AM, Darik Horn  wrote:
> 
> Jerome,
> 
>> If you can figure out how to get it to work, then it will be worth 
>> considering.
> 
> It works.  Updated builds are posted here:
> 
> https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing

I’ll try to look at it later today.

> 
> * The 1.44 MB floppy set is reduced from eight to three diskettes.
> * The 1.20 MB floppy set is reduced from ten to four diskettes.
> * The 720 KB floppy set is reduced from fifteen to six diskettes.
> 
> Creating 360 KB floppies or smaller would require a big extension of
> the installation program.

Yes. The installer needs updated to support smaller disk sizes. Eventually, I 
will add it. It wont be difficult. But, 360s aren’t common compared to the 
larger capacities. Therefore, it isn’t a priority.

> 
> This update also includes forward error correction for bad media.
> 
> The nearby BOOT.diff file describes what changed to make the demo happen.
> 
> 
>> 1) Wether or not it’s License is using an acceptable open source license.
>> 2) Usage is approved. Not up to me. But if licenses are ok, it should not be 
>> a problem.
> 
> The encoder is non-free and zero-cost, but the demo otherwise
> implements all features.

Not being open source will probably be an issue.

> 
> 
>> 3) Can be told to create spans of a specific size (so can be used on all 
>> floppy variations, one size fits all).
> 
> Yes.
> 
> 
>> 4) Can replace SLICER with little to no overhead added to the installer 
>> and/or RBE (Release Build Environment)
>> ...
>> https://github.com/shidel/FDI-x86/tree/master/SETTINGS
> 
> Thanks for posting this Github link, which I will review later.  I
> looked for a FreeDOS build system earlier but didn't find it.

Your welcome. 

The RBE is at https://gitlab.com/FreeDOS/OS/builder

There are also mirrors for FDI & FDI-x86 there as well as some other stuff. 

If your interested in building a FreeDOS release using the RBE, it’s rather 
easy to setup and do. Just follow the wiki for it on GitLab. 

The RBE itself is rather complicated and is a work-in-progress. But it works. 
:-)

On a side note, here is just something to ponder… A typical end user is 
installing FreeDOS into VirtualBox on Windows… So… I sit here running a Mac. 
Using VirtualBox, to run a Linux VM for the RBE. The RBE downloads and 
processes the raw installers and packages. It then dynamically builds some 
custom boot images and runs QEMU instances with FreeDOS. Those instances run 
batch files generated by the RBE to create the different install media. That 
media then is loaded into a different machine by the end user. They then run 
another virtual machine and run the installer for FreeDOS. The installer then 
installed the OS and creates custom config files for that system.

And that was an over-simplification of a release build to install chain. Trying 
to do it by hand would be crazy making and prone to mistakes. 

> 
> 
>> 5) Can provide the same level of flexibility without the need to manually 
>> modify code when there are package/tag changes.
> 
> In the updated demo, a @LISTFILE substitutes each possible "SLICER /G
> %TPU%" invocation.
> 
> 
>> Can it display general text during the install process?
> 
> Yes, this can be scripted through the IDOS.SFX module.  The given demo
> displays progress per-file, which is the default.
> 
> 
>> Does it support NLS and provide text in the users language for prompts?
> 
> Dunno about NLS, but it can do ANSI.SYS style text in if/then/else blocks.
> 
> 
>> On systems that support change-line, can it auto-resume without being told 
>> to continue?
> 
> Dunno what change-line support is...
> 
> But the extractor won't prompt for a media change if it can already
> see the next volume, so floppy contents can be copied to a ZipDrive or
> HDD and the installer will behave properly.
> 
> 
>> After completion, can it just return an errorlevel to the installer and not 
>> stop with an “I’m done, Press OK” message?
> 
> The available %ERRORLEVEL% returns are sensible and actionable.
> 
> 
>> Those and other settings are available in the projects SETTINGS directory. 
>> Specifically, the X86_ALL.LST defines what gets what slicer tags for 
>> assembling the archive.
> 
> This RAR demo is somewhat an accident and I appreciate how licensing
> matters.  Two alternatives to using RAR or finishing SLICER come to
> mind now that I better understand the solution:
> 
> 1a. Replace FREEDOS.SAF with a FREEDOS.TGZ tarball.
> 1b. Use coreutils to "SPLIT FREEDOS.TGZ" across floppy media.
> 1c. Unpack it with a "COPY /B PART1+PART2" method and some batch logic.
> 
> This is how Linux distributions did installation before CD-R media was
> invented.  Zero new compiled code is required to implement it for
> FreeDOS, and it will cost 10 MB of temporary hard disk space at
> install time.
> 
> 2. Use the GPL licensing option in unrarlib to create a RAR2 encoder.
> Make a "grar" 

Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

I appreciate the effort you put into creating a PowerShell script to repack the 
repository. However, I do not know if we are going to do that. 

First, the new versions would need to be checked to ensure compatibility. They 
would probably be fine. But, testing would still need done. I honestly just 
done have the time for that at present.

Second, there is no way you could’ve known this. But, none of the machines 
(virtual or real) run Windows. Mostly Linux, some DOS and macOS (unix/BSD). 

There are numerous utilities and scripts we use that operate on all packages in 
the repo and elsewhere. So, whipping up something to run through them and 
recompress, is not too difficult.

But, I think it is to late to consider such a large unplanned change this close 
to the release 1.3-RC5. 

Once RC5 is released, I will look into it some and possibly add some 
recompression into the tool chain. 

:-)

Jerome


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