Re: [Freedos-user] Missing CDROM drive

2024-04-07 Thread 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

2024-04-06 Thread 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

2024-04-05 Thread 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 r

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

2024-03-11 Thread 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??

2024-02-09 Thread 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??

2024-02-09 Thread 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??

2024-02-08 Thread 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

2024-01-30 Thread 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

2024-01-30 Thread 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.

2023-12-29 Thread 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/
>  
> <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 <mailto: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?

2023-12-29 Thread 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

2023-10-01 Thread 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

2023-08-28 Thread 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/ 
<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
 
<http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/ldebug.html>
[R3]: https://gitlab.com/FreeDOS/devel/ldebug 
<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

2023-08-20 Thread 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?

2023-08-07 Thread 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?

2023-08-06 Thread 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?

2023-08-06 Thread 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
 
<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 
<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.

2023-07-24 Thread Jerome Shidel via Freedos-user
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 spent on decompression. 

They could benefit a lot by excluding the 386-only software during 
installation. 

They could benefit from other improvements to the Floppy Edition as well. For 
example, SLICER (which installer the files) could have everything for the 8086 
stored uncompressed. Or better still, implement a very “high-speed and 
light-weight” compression for those files. It would decrease the compression 
level and probably require a diskette or three more. But, that could really 
speed up installation on such hardware. 

> Regards, Eric

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.

2023-07-20 Thread 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

2023-07-18 Thread 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?

2023-07-16 Thread 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] FreeDOS 1.3-RC3 News!

2023-06-07 Thread jerome
Hi Aitor,

> On Jun 6, 2023, at 6:19 PM, Aitor Santamaría  wrote:
> 
> Hello Jerome,
> 
> On Mon, 25 May 2020 at 13:26, Jerome Shidel  <mailto:jer...@shidel.net>> wrote:
> 
> Why keyb need a 286, it’s a keyboard mapper?
> 
> It does not: KEYB /9 should work on 8088 class machines.

Wow, this is an old thread (over 3 years)!

KEYB requiring a 286 or better is based solely on:

$ grep 286 *
KEYBMSG.DE:STR2_7 = 'KEYB braucht (immer noch) einen AT/286 oder besser';
KEYBMSG.NLS:STR2_7 = 'Keyb (still) requires an AT/286 or better';

Being an English language and keyboard user, I neither use nor possess 
knowledge on using various NLS support programs like KEYB. So if there is 
support for hardware older than a 286 or options that provide compatibility, I 
would not know they exist.

:-)

Jerome

> 
> Aitor
> ___
> 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] Logger

2023-05-19 Thread jerome
Hi, 

Logger is out of BETA.

Version 1.00 is now available.

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

:-)

Jerome


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


[Freedos-user] Final Logger BETA

2023-05-15 Thread jerome
Hi everyone,

I just released Logger v0.4-BETA. 

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


There is also an update demo boot disk image which
can be used with the FreeDOS 1.3 LiveCD. 

https://fd.lod.bz/redist/system/ 

This is the final BETA version. 

After a little more testing and possibly a few minor 
optimization related changes, version 1.0 is 
scheduled to be released this Friday.

:-)

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


Re: [Freedos-user] Add custom directory to LiveCD iso

2023-05-04 Thread jerome
Hi,

> On May 4, 2023, at 9:30 PM, Andrea Bolandrina  wrote:
> 
> Hi,
> 
> I've extracted the FD13LIVE.iso image, added a custom directory (with BIOS 
> upgrades) in the root (I then tried other directories too, and all sorts of 
> naming conventions).
> I know the directory is in the "iso" image, but when the LiveCD is live the 
> directory is nowhere to be found.
> 
> Is there a way to add a custom directory to the LiveCD?

That may not be necessary.

Assuming, your CD/DVD drive is supported by the drivers supplied on the LiveCD 
and you have sufficient memory available to DOS (most likely on real hardware) 
and the RAM drive is large enough and functional. There is an easy alternative.

But before that, we need to verify those things. During the boot of the Live 
Environment of the LiveCD, there should be a number of packages that are 
“Brought Online”. The final such package in FreeDOS 1.3 that is automatically 
installed into the Live Environment is “games\sayswho”. If the boot process 
does not stop on a previous package and all are either "Skipped or OK”, we know 
their is sufficient memory with a working RAM drive and the CD/DVD drive is 
supported.

This will be great news. Because, you are able to remove the LiveCD and still 
have a fully functioning FreeDOS that is running from a RAM drive. This means 
you can simply burn your Update to a separate CD (probably using ISO9660 
format). 

Then after booting the LiveCD, you should see something like “CD-ROM configured 
as E: drive (FDCDX001)” which is to inform you the drive letter assigned to the 
CD/DVD drive. You can swap the LiveCD for your update CD, change to the 
appropriate drive letter and run your update.

> Kind regards,
> Andrea

If you do not see the “Bring games\sayswho package online. OK” message, you 
will most likely need to use an alternative method. 

:-)

Jerome


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


[Freedos-user] Logger, new output format

2023-04-26 Thread jerome
Hi All, 

As I mentioned previously, LOGGER can log both in monochrome and color. Along 
with the built in viewer, the log could be printed to include ANSI escape 
sequences for color. But, that is of very limited use. So along with the PRINT 
and ANSI commands that output the log to StdOut, there is a new output format 
in ALPHA-7. It is of little use in DOS itself. Rather, it is intended for 
sharing a full color log that can be viewed on common desktop and mobile 
operating systems. Check out the new HTML log output sample. 

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


or, download and try for yourself

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


:-)

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


Re: [Freedos-user] Wait! What did that say?

2023-04-15 Thread jerome


> On Apr 14, 2023, at 6:53 PM, Jim Hall  wrote:
> 
> Very cool! I've posted a news item about it on the website.

Thanks. :-)

> Since this is still alpha (alpha-3) I assume it's too early to mirror
> on the FreeDOS Files Archive at Ibiblio, so I haven't copied it there.


Thats fine. 

All the functionality that is referred to in the documentation and help screens 
has been implemented. And, what has been tested appears to be working properly. 
However, testing has been very limited. 

:-)

Jerome




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


[Freedos-user] Wait! What did that say?

2023-04-11 Thread jerome
Hi Everyone,

Have you every watched you DOS machine boot and find yourself saying “what was 
that message?” as it scrolled off the screen?

Wonder no more. 

I’ve just release the first version of LOGGER for testing. 

It includes a device driver that gets loaded in the FDCONFIG.SYS (or 
CONFIG.SYS) that will record all the messages at boot time. And continue 
logging during normal system usage until it is turned off. 

It also includes a program to VIEW the log (in full color when enabled), PRINT 
it to file for later and various other functions. When logging is on during 
normal system usage, it can even be used to view the output of previous 
commands similar to a “scroll-back” buffer of up to 64Mb of XMS memory. That 
would be roughly 60,000 pages or 30,000 color pages. (storage of a 80x25 page 
can range from 50 to 4100 bytes depending on the recording mode and contents).

If you are interested in giving it a whirl, you can find it at:

https://fd.lod.bz/repos/current/pkg-html/logger.html 
<https://fd.lod.bz/repos/current/pkg-html/logger.html>

:-)

Jerome


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


Re: [Freedos-user] Update wiki info on installing ftp on a virualbox guest?

2023-03-15 Thread jerome
Hi,

> On Mar 15, 2023, at 10:22 PM, Michael Brutman  wrote:
> [..]
> The only questionable thing I noticed was somebody converted the user 
> documentation to a 293KB text file.  That strips the formatting, diagrams and 
> screen shots that I have in the PDF.  Can we not do that in the future?  
> Nobody is going to want to wade through a 293KB text file.

I don’t recall the origin of the text version. It is also regarding the 
2015-07-05 release and most likely contains outdated information. I will delete 
it from the GitLab Archive and it won’t be in any future interim builds or OS 
releases. 

I do recall that it was included because PDF documents are not easily viewed 
under DOS. I don’t think we even provide a PDF viewer at present. We do provide 
a couple web browsers. I hope you will consider providing an additional version 
of the documentation in HTML format with future versions. 

Jerome

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


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

2023-03-08 Thread jerome
Hi, 

> On Mar 8, 2023, at 1:33 PM, C. Masloch  wrote:
> [..]

I added the new release to my repo [1], and the official package update repo 
[2][3] on ibiblio. 

> [7]: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/rel4/
>  
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/rel4/>
I don’t generally do any file management in the mirrors section in ibiblio. 
But, I went ahead and replaced the REL4 version as you requested. 

> [8]: 
> https://gitlab.com/FreeDOS/devel/ldebug/-/commits/master/SOURCE/LDEBUG/case-specific
>  
> <https://gitlab.com/FreeDOS/devel/ldebug/-/commits/master/SOURCE/LDEBUG/case-specific>

I also updated the package on the GitLab FreeDOS Archive. So, it will be 
automatically included in the next Interim Build T2304. When creating an 
interim OS build or actual version release, the packages are pulled from the 
projects on GitLab. If you desire the ability to push commits directly to the 
version on Gitlab[4], no problem granting access. 

:-)

Jerome

[1] - https://fd.lod.bz/repos/current/pkg-html/ldebug.html 
<https://fd.lod.bz/repos/current/pkg-html/ldebug.html>
[2] - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/ldebug.html
 
<https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/ldebug.html>
[3] - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/ldebug.html
 
<https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/ldebug.html>
[4] - https://gitlab.com/FreeDOS/devel/ldebug 
<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


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

2022-12-13 Thread 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)

2022-12-13 Thread 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)

2022-12-13 Thread 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

2022-12-10 Thread 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

2022-12-01 Thread 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

2022-10-17 Thread 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

2022-09-18 Thread 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

2022-09-15 Thread 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

2022-09-15 Thread 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

2022-09-09 Thread 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

2022-09-06 Thread 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 
> <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 <https://github.com/shidel/fd-nls> . 
The version at GitLab at https://gitlab.com/FreeDOS/OS/fd-nls 
<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

2022-09-06 Thread 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

2022-09-06 Thread 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

2022-08-22 Thread 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

2022-08-21 Thread 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

2022-08-03 Thread 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

2022-08-02 Thread 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]

2022-07-31 Thread 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. 

> 
> =

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

2022-07-14 Thread 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

2022-07-13 Thread 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

2022-07-11 Thread 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

2022-06-27 Thread 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

2022-06-18 Thread 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

2022-06-15 Thread 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

2022-06-13 Thread 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

2022-05-31 Thread 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

2022-05-23 Thread 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

2022-05-17 Thread 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

2022-04-17 Thread 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.

2022-04-04 Thread 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.

2022-04-04 Thread 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

2022-03-14 Thread 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

2022-03-14 Thread 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

2022-03-08 Thread 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

2022-03-05 Thread 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

2022-03-04 Thread 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

2022-03-03 Thread 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

2022-03-02 Thread 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

2022-03-01 Thread 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

2022-03-01 Thread 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

2022-03-01 Thread 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

2022-02-28 Thread 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

2022-02-26 Thread 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

2022-02-26 Thread 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

2022-02-23 Thread 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.

2022-02-21 Thread 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 <http://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

2022-02-21 Thread 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.

2022-02-21 Thread 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.

2022-02-20 Thread 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

2022-02-18 Thread 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

2022-02-06 Thread 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

2022-01-26 Thread 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

2022-01-25 Thread 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/ <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 <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

2022-01-23 Thread 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

2022-01-18 Thread 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.

2022-01-14 Thread 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.

2022-01-13 Thread 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

2022-01-12 Thread 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)

2022-01-03 Thread 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

2021-12-31 Thread 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 
> <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 
> <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/ 
<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/
 
<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

2021-12-28 Thread 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

2021-12-21 Thread 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
 
<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 
<https://fd.lod.bz/repos/current/pkg-html/fdimples.html>

Or, even from the GitLab Archive at:
https://gitlab.com/FreeDOS/apps/fdimples 
<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

2021-12-18 Thread 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

2021-12-18 Thread Jerome Shidel
he 
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 issues that I need to look into. But, it makes creating a release 
easy, consistent and reliable. 

I think anyone who’s really into FreeDOS should try running it sometime.
By default, it runs in non-verbose mode.  But, change it to verbose, you 
will see gigabytes of text scroll by. And that is still only a summary of 
everything it needs to do to push out a release. It is kind of amazing to watch.

I know of only one other person who uses the RBE. They use it to create a 
custom spin of FreeDOS that includes some Assistance software. 

> Nevertheless, this is a fun
> optimization job, and I'm getting slightly better results using
> standard tools.

Have fun squeezing bits. :-)

You could always create a spin yourself. Maybe include extra stuff, like 
network programs or games or something. 


>> There have been requests to add very useful programs like EDIT to that boot 
>> diskette.
> 
> This might be doable; I will look at it.

:-)

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

2021-12-18 Thread 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
&

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

2021-12-17 Thread 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

2021-12-16 Thread 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
 
<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

2021-12-15 Thread 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

2021-12-15 Thread 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 
<https://gitlab.com/DOSx86/slicer> or on the FreeDOS GitLab Archive at 
https://gitlab.com/FreeDOS/archiver/slicer 
<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

2021-12-08 Thread 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 
<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/
 
<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/ 
<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


  1   2   3   4   5   >