[Freedos-devel] FreeDOS Wiki

[Jerome Shidel via Freedos-devel]

Hi,

Apparently, the (old) FreeDOS wiki on sourceforge is down or broken. 

After visiting the FreeDOS.org  website, navigating to 
“Read the wiki ” and waiting, I just get a blank 
page after redirection to the

https://freedos.sourceforge.io/wiki/index.php/Main_Page 
 web page.

:-)

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

Re: [Freedos-devel] FETCH4FD

[Jerome Shidel via Freedos-devel]

Hi Laaca,

I included the NLS files for FETCH4FD over on the FD-NLS project. 

Berki has already provided translations for French and Turkish. 

https://github.com/shidel/fd-nls/tree/master/fetch4fd/nls 


Also if you could clarify the licensing for FETCH4FD, that would be great. 

Is it just Free w/Sources, Public Domain, or under one of the open source 
licenses?

Thanks,

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

Re: [Freedos-devel] FETCH4FD

[Jerome Shidel via Freedos-devel]

Hi

> On Mar 19, 2024, at 6:33 PM, Ladislav Lacina via Freedos-devel 
>  wrote:
> 
> Hello!
> I write own port of utility NeoFetch known from UNIXes.
> [..]

Never used NeoFetch. 

What is it for? 

Looking at the screenshot and features you listed, my guess is it reports some 
general system information. 

Like RAM, CPU and Drives.

:-)

Jerome



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

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

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Mar 10, 2024, at 1:42 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> On Sun, Mar 10, 2024 at 12:09 PM Jim Hall  wrote:
>> 
>> Thanks to everyone who joined the FreeDOS virtual get-together today!

We hung out for about 45 minutes after you left. Then, I had to go. Don’t know  
oh w about the rest. They could still be there. :-)

Jerome
> 


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

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

[Jerome Shidel via Freedos-devel]

Attached is my proposed revisions to FDAUTO.

@ECHO OFF
REM - Updated AUTOEXEC file, for 386 or better hardware

REM - set basic environment

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

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

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

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

set LANG=EN
set TZ=EST

REM Emergency Mode, no drivers should be loaded.
if "%CONFIG%"=="5" goto END

REM - Internationalization settings

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

REM - cfgfile and autofile might be deprecated in future
REM - At boot, FreeDOS can use CONFIG.SYS, but it prefers FDCONFIG.SYS

set CFGFILE=%DOSDRV%\CONFIG.SYS
if exist %DOSDRV%\FDCONFIG.SYS set CFGFILE=%DOSDRV%\FDCONFIG.SYS
set AUTOFILE=%0
alias cfg=edit %CFGFILE%
alias auto=edit %AUTOFILE%

if "%CONFIG%"=="4" goto DOSLOW
goto DOSHIGH

:DOSLOW
ctmouse
goto ENDCPU

:DOSHIGH

lh fdapm APMDOS
lh ctmouse
REM lh share

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

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

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

:ENDCPU
REM - load other configs using external BAT files

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

REM - additional customization and local settings

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

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

MEM /C /N

REM - Display drive for CD-ROM
if not exist %DOSDIR%\BIN\CDROM.BAT goto NOCDSTATUS
call %DOSDIR%\BIN\CDROM.BAT status
:NOCDSTATUS

REM - Display "Welcome to FreeDOS"
if not exist %DOSDIR%\BIN\WELCOME.BAT goto NOHELLO
call %DOSDIR%\BIN\WELCOME.BAT
:NOHELLO

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

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

[Jerome Shidel via Freedos-devel]

Hi Jim and All, 

This got me thinking about the startup files a little more. I realized there 
are several additional factors that were present during their development that 
are simply no longer relevant. 

One such factor was the simultaneous development and adjustments made between 
the installed config files and those used by the boot media(s). During the 
initial development and tests, bits and pieces would move back and forth 
between them adding additional complexity. Plus, the need for developing 
numerous skews for multiple platforms while developing the installers at the 
same time. 

That time has long since passed. The config files that get installed have 
nothing at all to do with the config files used to boot the various install 
media.

The installer(s) base the config files installed on a decision hierarchy for 
the detected platform. This means we can simplify the installed config files 
even further by eliminating the CPU testing in them. 

At present these are the possible different config files installed.

DOSBox - Dummy CFG, Platform specific AUTO.
VirtualBox - Platform Specific CFG & AUTO. VirtualBox really doesn’t 
like the option 1 in the default CFG file, it only provides 4 boot options. 
Also (at least for me), VirtualBox will lockup when running FreeDOS after a few 
minutes when FDAPM is not loaded. So, I think “#4 - Safe Mode” should be 
removed or at lead have FDAPM loaded regardless. 

286 - Platform Specific CFG, Default AUTO. (3 boot options, XMS 
Support, With & Without Drivers)
186 - Platform Specific CFG, Default AUTO. (2 boot options, With and 
without Drivers)
8086/8088 - Platform Specific CFG, Default AUTO.  (2 boot options, With 
and Without Drivers)

All others - Default CFG & Default AUTO (5 boot options)

Looking at the current Default AUTO, it is missing a a test for option 3 (No 
Drivers) when running on a 286. 

I think the end user will be best served by getting rid of the platform tests 
in the installed config files. We can simple start with the default CFG & AUTO 
files. Then reduce/adjust those files for the specific platforms. Only testing 
for specific boot options and all CPU related items can be static.

To the above list of different CFG & AUTO files, the only thing that would 
change would be custom versions of AUTO files for 286, 186 and 8086/88. And 
those would only need to be simplified versions of the default AUTO.  

Starting with the 386+ version you have been working on, we could do this…

(I will also be sending a revised version of FDAUTO.TXT with my suggestions)

> On Mar 1, 2024, at 7:16 PM, Jim Hall via Freedos-devel 
>  wrote:
> [..]
>> @ECHO OFF
>> REM - Updated AUTOEXEC file

REM - For i386 CPU or better hardware.

>> 
>> REM - set basic environment
>> 
>> set DOSDRV=C:
>> set DOSDIR=%DOSDRV%\FREEDOS
>> 
>> path %DOSDIR%\BIN
>> if not exist %DOSDIR%\LINKS\NUL goto NOLINKS
>> path %PATH%;%DOSDIR%\LINKS
>> :NOLINKS
>> 
>> set NLSPATH=%DOSDIR%\NLS
>> set HELPPATH=%DOSDIR%\HELP
>> 
>> set TEMP=%DOSDIR%\TEMP
>> set TMP=%TEMP%
>> 
>> if "%CONFIG%"=="5" goto END

Side note, on VirtualBox this is option 4.

>> 
>> set OS_NAME=FreeDOS
>> set OS_VERSION=T2403
>> 
>> REM - cfgfile and autofile might be deprecated in future
>> 
>> set CFGFILE=%DOSDRV%\FDCONFIG.SYS
>> set AUTOFILE=%DOSDRV%\FDAUTO.BAT

We can change this to simply…

set AUTOFILE=%0

>> alias cfg=edit %CFGFILE%
>> alias auto=edit %AUTOFILE%
>> 

Remove this CPU Section!
>> REM - detect CPU, load CPU-specific configs
>> 
>> if not exist %DOSDIR%\BIN\VINFO.COM goto ENDCPU
>> %DOSDIR%\BIN\VINFO.COM /m
>> if errorlevel 3 goto CPU386
>> if errorlevel 2 goto CPU286
>> goto ENDCPU
>> 
>> :CPU286
>> 
>> fdapm APMDOS
>> ctmouse
>> 
>> goto ENDCPU
>> 
>> :CPU386
>> if "%CONFIG%"=="4" goto CPU286
>> 

{end of removed}

if “%CONFIG%” == “4” goto DOSLOW

>> lh fdapm APMDOS
>> lh ctmouse
>> REM lh share
>> 
>> if not exist %DOSDIR%\BIN\DOSLFN.CON goto NOLFN
>> lh %DOSDIR%\BIN\DOSLFN.CON
>> REM - Add other stuff here once LFN is loaded..
>> :NOLFN
>> 
>> if not exist %DOSDIR%\BIN\CDROM.BAT goto NOCDROM
>> call %DOSDIR%\BIN\CDROM.BAT
>> REM - Add other stuff here once CDROM is loaded..
>> :NOCDROM

>> 
>> :ENDCPU

Moving ENDCPU  a little later.

>> 
>> REM - load other configs using external BAT files
>> 
>> if not exist %DOSDIR%\BIN\FDNET.BAT goto NONET
>> call %DOSDIR%\BIN\FDNET.BAT
>> REM - Add other stuff here once FDNET is loaded..
>> :NONET

goto ENDCPU

:DOSLOW
REM - If we are loading some drivers low, we are probably having 
REM - Boot problems and may want to skip using FDAPM, LFN,
REM - CDROM and NETWORKING. Just load the mouse driver.

ctmouse

:ENDCPU

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

I really think “MEM /C /N” should before the welcome message. 

No drivers or TSRs are loaded by WELCOME.BAT and the 
amount of memory available will not change.

Side 

[Freedos-devel] FreeDOS Interim Build T2403

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2403 for March is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes:

* Primarily, the release was switched back to HTMLHELP from AMB based Help. The 
new version of help needs testing and checking of the English text. I don’t 
think the other languages have received any significant changes and are waiting 
on verification of the English text before being translated.

2024-02-23 07:30:44 fdhelper [unstable] (Shidel): Merge branch 'unstable' into 
'unstable'
2024-02-23 07:02:54 append (shidel): updated to v5.0-0.7 (FCB bugfix)
2024-02-23 03:23:50 append (shidel): Merge branch 'master' of 
gitlab.com:FreeDOS/base/append
2024-02-23 03:23:35 append (shidel): update primary site information in metadata
2024-02-23 02:22:22 project_FDI-x86 [unstable] (shidel): Merge pull request #6 
from boeckmann/unstable
2024-02-23 02:12:13 project_FDI [unstable] (shidel): Merge pull request #20 
from boeckmann/unstable
2024-02-22 21:07:41 project_FDI [unstable] (Bernd Boeckmann): change help 
viewer to HTMLVIEW
2024-02-22 20:54:27 fdhelper [unstable] (Bernd Boeckmann): help.bat: prioritize 
HTMLHELP
2024-02-22 19:43:20 project_FDI-x86 [unstable] (Bernd Boeckmann): change help 
viewer to htmlhelp
2024-02-22 19:18:01 fdisk [unstable] (Bernd Boeckmann): update LSM
2024-02-22 19:15:15 fdisk [unstable] (Bernd Boeckmann): release 1.3.14 part2
2024-02-22 19:12:05 fdisk [unstable] (Bernd Boeckmann): release 1.3.14
2024-02-21 09:27:56 append (Shidel): Merge branch 'master' into 'master'
2024-02-21 09:27:55 append (tsupplis): Update INT21.ASM -  Major Logic Fix for 
support of FCB I/O calls
2024-02-18 04:31:39 tree [unstable] (shidel): updated to v3.7.3
2024-02-17 14:02:53 debug (shidel): updated to v2.02
2024-02-17 09:20:06 fbc_help (shidel): added override to package structure 
verification
2024-02-17 09:09:57 fbc_help (shidel): added package config file
2024-02-17 08:17:14 blocek (shidel): updated to v1.75b
2024-02-17 07:43:14 jemm (shidel): updated to v5.84
2024-02-09 20:35:19 htmlhelp [unstable] (Bernd Boeckmann): update English help 
to 1.1.0 (preview)
2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1

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

Re: [Freedos-devel] FDISK 1.3.14

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Feb 22, 2024, at 3:35 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> Excellent news! I'll post an item on the website about it.
> 
> I can't login to Ibiblio from where I'm at right now, so I can't
> mirror it - maybe someone else with Ibiblio access can do that for me.
> Otherwise I'll mirror this to Ibiblio over the weekend.
> 
> 
> Jim

Even though, I generally don’t do anything with mirrors.
Since you don’t have access right now, I took care of it.

I put a copy at:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/fdisk/1.3.14/ 


:-)

Jerome

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

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

[Jerome Shidel via Freedos-devel]

Hi Willi,

> On Feb 17, 2024, at 9:38 AM, Wilhelm Spiegl via Freedos-devel 
>  wrote:
> 
> Hi Jim,
>  
> I forgot to mention that there is another great new thing: NewDOS and its 
> source code is free since 2024-02-06!
> NewDOS itself is freeware since 2018.
>  
> You can grab it here: https://www.newdos.de/home/download.htm 
> 
>  
> NewDOS from André Olejko is no complete OS but a collection of more than 60 
> DOS commands and 3 games!
>  
> See: https://www.newdos.de/home/befehle.htm 
> 
>  
> There is a free assembler asm86 available from André Olejko, but the source 
> code has not been published till now.
> I am not sure if he will publish it at all.
>  
> See: https://assembler86.de/home/download.htm 
> 
>  
> And now the bad news:
> NewDOS and the assembler are in GERMAN only. It should be possible to 
> translate it to english, but this will be a lot of work.
>  
> André informed me that he is NOT willing to give any feedback or to answer 
> questions about his work.
> He thinks that it is very good to keep his work alive for the future, but he 
> does no longer program.
> So PLEASE DO NOT SEND MAILS ETC to him.
>  
> @Jim: Would it be possible to keep a copy ad ibiblio or anywhere else?
>  
> THX.
>  
> Willi
> 

They are small sites. So, I also mirrored them on my server as well.

They can be found along with the mirror of Eric’s website at https://m.lod.bz 


:-)

Jerome

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

Re: [Freedos-devel] Tree v3.7.3 Was: Re: Xcopy 1.5

[Jerome Shidel via Freedos-devel]

Hi Jeremy, 

> On Feb 17, 2024, at 9:58 PM, perditionc--- via Freedos-devel 
>  wrote:
> 
> On Sat, Feb 17, 2024 at 9:09 AM Wilhelm Spiegl via Freedos-devel
>  wrote:
>> 
>> Hi Jim,
>> thanks for your response. Xcopy is not the only thing, maybe you remember 
>> tree 3.72 in this forum?
>> 
> ...
>> 
>> tree: do not know the actual situation, I got a promise that someone will 
>> check whats the matter.
>> 
> ...
> 
> Good evening,
> 
> Please see http://server.fdos.org/fdos/tree/TREE373.zip for an update
> to the tree program that should fix the issues (sorry for the long
> delay).
> 
> Changes from tree v3.7.1/3.7.2
>  - reverted argument processing back to code from v3.7 [.0], the
> changes to use getopt were really broken
>  - minor tweaks to included cats to default NLSPATH to ".;.\NLS", a
> future version will update tree to kitten
>  - added extra check so if no serial# returned, assumes call failed
> and doesn't print invalid serial# (note, the way it calls int21h is a
> bit funky, in pdTree the carry flag is forced set before the call as I
> recall some kernels don't set it on error for the called function, but
> this version just clears struct and assumes if still clear then call
> failed as I'm not sure how to set the flags register prior to the
> int86 call (it's not the standard version, no regs struct passed) and
> don't have all the compiler variants easily available anymore to test
> changes to it.
>  - included in the zip is all the current? message catalogs, note:
> these are straight from the FreeDOS nls archive on gitlab, hopefully
> didn't miss/mess any up.
>  - some documentation updates to reflect that I no longer have
> @computer.org email address.
> 
> A version 4 will be released eventually, but I'm not making any
> commitments for when.  In the meantime, if anyone has any issues with
> this version, please let me know and I'll try to push out an update a
> little quicker. :-)

Great news. :-)

I created an “unstable” branch in the FreeDOS GitLab Archive. That way the new 
version will be in the next Interim Test Build for every one to try out. 

I did make a few minor adjustments to the LSM file. Mostly for compatible with 
the current automated maintenance utilities. For example, most of those tools 
can properly deal with multiple line entries. However, I can be lazy at times 
and a few other less important tools ignore text that is not preceded by a 
field identifier. 

Also, I noticed that you did not included the help translations from FD-NLS in 
the zip. So, I just included them. Although, I forget if TREE displays those 
versions of help when using a different language. 

I’ll definitely have to give it a try.

> 
> (ps a new test kernel release is pending, but I'm trying to figure
> out/fix a driver hang during load issue first).

Looking forward to that as well. :-)

> 
> Thanks,
> Jeremy

Thanks,

Jerome

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

Re: [Freedos-devel] Append

[Jerome Shidel via Freedos-devel]

Hi Eduardo, 

> On Feb 17, 2024, at 4:54 PM, Eduardo Casino via Freedos-devel 
>  wrote:
> 
> Hi Jerome, 
> 
> I'm the autor of Append. I'll have a look at it, although it's been a long 
> time... 
> 
> Thanks, 
> Eduardo

Great. 

Bernd took a look at the merge request. Other than white-space changes, only 
one line was changed from a “JZ” to a “JNZ”. 

So when you look at it, the changes should not be very difficult to verify are 
correct, sufficient and have no adverse side effects.

Thanks,

Jerome

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

[Freedos-devel] Append

[Jerome Shidel via Freedos-devel]

Hi All,

Append received a “critical” merge request in the GitLab Archive. 

https://gitlab.com/FreeDOS/base/append/-/merge_requests/1 


Since, no know developer is maintaining that program, it would be great for 
someone to volunteer to take a look at the patch, verify it is needed and 
recompile the program for testing. 

Thanks,

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

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd, 

> On Feb 12, 2024, at 5:58 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> I am one step further. I installed dosfstools via zypper and ran the RBE 
> install script again. It showed the following output:
> 
> required lower permissions for creating DOS filessystems.
> '/usr/sbin/mkfs.msdos' -> '/home/rbe/bin/make-dosfs'
> required lower permissions for labeling DOS filessystems.
> '/usr/sbin/fatlabel' -> '/home/rbe/bin/fatlabel'
> 
> So, I finally know where this make-dosfs comes from :-) Perhaps you can add 
> *dosfstools *and *unzip *to the package dependencies in the install script? 
> These are the two I had to install manually after setting up the container.

Hmmm, this is interesting. 

During my test with 15.5 earlier today, I did not need to manually install 
ether of those packages by hand. The install script for the RBE worked without 
issue. Makes me wonder why your install of 15.5 was different. But, it would 
not hurt to include those packages. 

> 
> Sadly QEMU times out. Probably because it is running without KVM. I have not 
> found yet a solution to enable it for the container. This takes longer than I 
> wanted to, so I will dump the container and set up a proper VM…

Hmmm, possibly openSUSE does not install those missing packages by default when 
installing to a container. 

Well, you could possibly just increase the timeout setting for in the 
custom.cfg file. But, if the pieces that use QEMU are so slow it will really 
drag during a couple places when it is doing stuff that can only be done in DOS 
at present. Mostly, that is installing boot loaded and generating the SLICER 
archive for the floppy edition.

Side note… When not in verbose mode, the RBE runs those without any sort of 
display. It spawns them in their own sub shell and monitors waits for that to 
finish. If the elapsed time is exceeded, it assumes it has hung, kills the 
process and the build aborts. The RBE also verifies the result of the QEMU task 
to make sure it completed without an error. 


> BTW your scripts look pretty good, and apart from the trouble caused by 
> myself this all seems to run very smooth…

Thanks.

With all the changes to many things in FreeDOS release itself, this version 3 
(i think) has resulted in a lot of spaghetti in the code. Plus adding things 
like multitasking to work on multiple packages simultaneously at different 
stages contributed to that as well. But, that cut the build time by more than 
50%. So, the increase in performance was definitely worth it.  

Going from nothing and building all the different release media. Pulling the 
different packages and sources down from the internet. Comping on all those 
different packages making metadata and ZIP archives. Modifying the FreeDOS 
installer batch code for all the different languages, keyboads and fonts. And 
that only scratches the surface of all the things that happen when building a 
release. 

It would be cool if someday we developed a standard for the DOS packages that 
would provide a simple method to compile each of the programs from source. 
Then, provide the RBE with an option to do that as well.

The RBE has received many changes over the years. It’s far from perfect and 
could still use a lot of streamlining and other general improvements. Maybe 
that will happen if I ever get around to making the next incarnation of the RBE.

Even as it is now, it is still kind of a marvel to watch in action. 

> 
> Bernd

Keep me posted on your efforts.

:-)

Jerome



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

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

So…

I booted the (Windows 10) machine that I use for creating FreeDOS builds. (Host 
OS should not be relevant.)

There was an update to VirtualBox. So, I installed that and the related new 
extension pack.

( Following the instructions in the RBE’s Wiki. Except for CPU’s, I went with 2 
cores for a reduced build time. )

I created a new VM for the RBE. 

I download a fresh copy of openSUSE 15.5 Leap DVD install for x86. (newest 
version)

( I had a little trouble downloading openSUSE. My home internet was recently 
upgraded to a 1Gb connection. With the standard mirror, I would download for a 
few seconds at very fast rate. Then just stop at some point. After switching to 
a different mirror, it downloaded without problem. It makes me wonder if the 
first server was having issues with the much faster rate. Possibly, it 
considered it a DDOS. But, it could just be Windows. After all, I was having 
issues pulling up GitLab on that machine and no issues on the Mac sitting next 
to it. Then again, maybe since the new router fully supports IPv6, IDK. Only a 
couple days since the upgrade and this was the only time I’ve had an issue. 
Time will tell. )

I installed openSUSE. 

(Note: I need to update wiki. Earlier versions of the openSUSE defaulted to 
activating online repositories. Now you have to choose. They need to be enabled 
for the install script to fetch additional required packages. Otherwise, I used 
my normal location settings and such. Finally (per wiki instructions), I 
selected the system role as server.)
 
After the install of openSUSE, I continued to the Install Builder Tools page in 
the wiki.

Used zypper to install git: git sudo zypper install git

Cloned RBE project: git clone https://gitlab.com/FreeDOS/OS/builder.git

Moved to the Builder directory: cd builder

Ran the install script for the RBE: sudo ./install

Rebooted. (End of wiki)

Logged in as normal user and changed dir to the builder dir.

Ran: make

(waited a while watching build process)

Result, Successful Build of a “Standard Release”

Ran: make clean

Edited custom.cfg to:

unstable=yes
verbose=yes

Ran: make

(waited a while watching build process)

Result, Build failed from unknown issue while creating bootable floppy. 
However, I never use verbose mode in the normal VM’s that I use to build the 
FreeDOS release media. It is possible I broke something there a while back and 
didn’t notice. Or, changes to openSUSE broke something there. Or, possible 
there is some issue with one of the packages “unstable” branch”. So, I simply 
disabled verbose output and tried again. 

Ran: make clean

Edited custom.cfg and re-disabled verbose output.

Ran: make

(waited a while watching build process)

Result, Successful Build of a “Interim Build”

In conclusion, there is an unrelated issue regarding “verbose mode” during 
release building process. This is not related to the error you encountered. The 
error you received would most likely have been cause by the RBE not getting 
installed correctly. This could be the result of a bad download of the openSUSE 
operating system. Or possibly, something failed during the RBE installation 
script and the error was not caught by that script. 

You can try to run the install script for the RBE again. Generally, it checks 
the state of the system and only changes things when needed. Primarily, that is 
because when I make major changes to the RBE, the install script can just be 
run again to “patch up” any new changes that are required. 

If that does not remedy the problem, I would trash the VM and start from the 
beginning. It could have been a corrupt download of openSUSE.

Left me know if this helped and fixes the build issue you had.

Thanks, 

Jerome




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

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi,

> On Feb 11, 2024, at 7:43 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hi Jerome,
> 
> it currently fails at:
> 
> tools/common: line 1075: make-dosfs: command not found
> 
> I am currently searching for the make-dosfs executable.//It is not under the 
> builder directory, and I have not found it as an external command in the open 
> suse package repo. Can you confirm that this is part of RBE itself?
> 
> Bernd

Yes, it uses that utility. 

I’ll create a fresh VM using the latest version of openSUSE later today and 
figure out what I need to change to make it compatible (again).

Hopefully won’t take too long. 

Thanks,

Jerome

> 
> 
>> On 11.02.2024 21:09, Jerome Shidel via Freedos-devel wrote:
>> Hi Bernd,
>> 
>>>> On Feb 11, 2024, at 2:11 PM, Bernd Böckmann via Freedos-devel 
>>>>  wrote:
>>> 
>>> Hi Jerome,
>>> 
>>> thanks for the explanations!
>>> 
>>>>> Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
>>>>> :
>>>> Oh BTW... If your interested in seeing the RBE in action, or making builds 
>>>> locally, it’s very easy to install and create builds. You can read the 
>>>> instructions for installation into a virtual machine at 
>>>> https://gitlab.com/FreeDOS/OS/builder/-/wikis/home
>>>> 
>>>> It’s been a while since I did a fresh install of the RBE. So, hopefully 
>>>> newer versions of the OS that runs the RBE haven’t broken the install or 
>>>> build process.
>>> I have setup an Open SUSE 15.5 container on my Proxmox server. When I have 
>>> the RBE running on it I will try to make the required changes for HTMLHELP 
>>> to be the default help viewer.
>>> 
>>> Bernd
>>> 
>> Great.
>> 
>> You said “when I get the RBE running”… Did you run into an issue under the 
>> latest version of openSUSE that I need to address?
>> 
>> Once the RBE is installed (and working), generating a OS build should be 
>> easy. Simple running “make” then wait.
>> 
>> Of course, there is also a “make clean” to purge all the cached data and 
>> prep for a fresh build.
>> 
>> Very easy to tell the RBE to build ether a “interm test” or “release” build. 
>> It’s just a configuration option.
>> 
>> It even uses custom “user configuration” files. That way, updates to the RBE 
>> itself don’t overwrite build customization. It’s been a while since I 
>> modified any configuration stuff for the RBE. So, I’ll need to check and let 
>> you know the file name. Personally, I just use two different VMs. One for 
>> Interim and one Release Builds. Then I don’t need to mess with changing the 
>> configuration at all.
>> 
>> You’ll just need to set it for Interm Builds. That way it pulls from the 
>> unstable repository branches.
>> 
>> Side notes…
>> 
>> If you set it to “verbose”, it will display a lot of additional information 
>> on what is happening during the build process.
>> 
>> Also, many parts of the build are multi-threaded. So, it is possible adding 
>> cores to the VM “could” result in faster builds.
>> 
>> Someday, I should cross compile a version of SLICER to run under Linux. That 
>> would boost creating the Floppy Edition a great deal.
>> 
>> :-)
>> 
>> Jerome
>> 
>> 
>>> 
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>> 
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

> On Feb 11, 2024, at 2:11 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hi Jerome,
> 
> thanks for the explanations!
> 
>>> Am 10.02.2024 um 00:18 schrieb Jerome Shidel via Freedos-devel 
>>> :
>> 
>> Oh BTW... If your interested in seeing the RBE in action, or making builds 
>> locally, it’s very easy to install and create builds. You can read the 
>> instructions for installation into a virtual machine at 
>> https://gitlab.com/FreeDOS/OS/builder/-/wikis/home
>> 
>> It’s been a while since I did a fresh install of the RBE. So, hopefully 
>> newer versions of the OS that runs the RBE haven’t broken the install or 
>> build process.
> 
> I have setup an Open SUSE 15.5 container on my Proxmox server. When I have 
> the RBE running on it I will try to make the required changes for HTMLHELP to 
> be the default help viewer.
> 
> Bernd
> 

Great.

You said “when I get the RBE running”… Did you run into an issue under the 
latest version of openSUSE that I need to address?

Once the RBE is installed (and working), generating a OS build should be easy. 
Simple running “make” then wait.

Of course, there is also a “make clean” to purge all the cached data and prep 
for a fresh build. 

Very easy to tell the RBE to build ether a “interm test” or “release” build. 
It’s just a configuration option. 

It even uses custom “user configuration” files. That way, updates to the RBE 
itself don’t overwrite build customization. It’s been a while since I modified 
any configuration stuff for the RBE. So, I’ll need to check and let you know 
the file name. Personally, I just use two different VMs. One for Interim and 
one Release Builds. Then I don’t need to mess with changing the configuration 
at all. 

You’ll just need to set it for Interm Builds. That way it pulls from the 
unstable repository branches.

Side notes…

If you set it to “verbose”, it will display a lot of additional information on 
what is happening during the build process.

Also, many parts of the build are multi-threaded. So, it is possible adding 
cores to the VM “could” result in faster builds. 

Someday, I should cross compile a version of SLICER to run under Linux. That 
would boost creating the Floppy Edition a great deal. 

:-)

Jerome


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


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

Re: [Freedos-devel] HTMLHELP

[Jerome Shidel via Freedos-devel]

Hi Bernd,

> On Feb 9, 2024, at 3:00 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Hello,
> 
> I uploaded Willis recent changes containing the HTML help 1.1.0 (English) to 
> the unstable Gitlab repo [1]. The other languages are still shipped in 
> version 1.0.8. This also contains version 5.3.6 of the HTMLHELP.EXE with 
> several bugs fixed. Crashes and display corruptions should hopefully not 
> occur anymore.

Awesome! Thanks.

> 
> Can someone please alter the interim build process, so that HTMLHELP is the 
> default help viewer, and this gets a little testing? I would do it by myself 
> but have no overview over the build process and probably not the permissions 
> needed.

The build process used by RBE (Release Build Environment) is a rather complex 
spaghetti monster. But, it is fully automated and minor changes like this are 
fairly easy to implement. 

When the RBE is putting together the Interim Test Build release, it pulls the 
lists of packages for the different media from the two installer projects on 
GitHub. 

Primary Installer Settings:
https://github.com/shidel/FDI/tree/master/SETTINGS 

(or, the unstable branch if it exists)
https://github.com/shidel/FDI/tree/unstable/SETTINGS 


Floppy Edition Settings:
https://github.com/shidel/FDI-x86/tree/master/SETTINGS 
 
(or, the unstable branch if it exists)
https://github.com/shidel/FDI-x86/tree/unstable/SETTINGS 


(unlike Version Release Builds that always pull from the master branch, Test 
builds always pull from unstable branches when they exist)

So, the first step is to verify that the Package for HTMLHELP is included in 
the release and installed. 

The two sets of package lists are similar. But, have a couple big differences. 

The sets from the Primary Installer include simple expansion macros. For 
example, the PKG_FULL.LST includes a $PKG_BASE$ macro. That tells the installer 
to also include everything in the PKG_BASE.LST file. 

So for main installer, it would probable be good to install it with BASE and 
have it “Live” on the LiveCD. A minor change to PKG_BASE.LST. Since, the LiveCD 
always tries to make all the packages in BASE live, no change will be needed to 
the PKG_LIVE.LST. 

( the current PKG_BASE.LST has a reference to HTMLHELP commented out. just need 
to uncomment it for inclusion during install )

The Floppy Edition package lists are a little different. There is only a “BASE” 
for the install called X86_ALL.LST. It does not have any macros. But, it does 
contain platform specific switches for creating the install media archive. 
Those switches resemble comments with a “tag” direction. Individual tags are 
turned off and on in the list file. It starts by turning all tags on. Then, 
when software is not compatible with specific hardware, that tag is turned off. 

Since HTMLHELP should run on the lowest supported hardware, It would be in 
section with most of the BASE packages. 

( note: there is an old reference to base\help commented out. When AMBHELP was 
added, the package for “help” was renamed to htmlhelp)

Once HTMLHELP has been added to the install list, AMBHELP and probably AMBREAD 
should be commented out for the floppy version. Possibly for the main installer 
package list as well.

That will take care of making sure new test version of  HTMLHELP gets installed 
in the next interim build. 

But, there is one more thing we may wish to do…

We probably want to update the HELP.BAT file to prefer HTMLHELP over AMBHELP. 
That will require simply updating the HELP.BAT file in the FDHELPER package on 
GitLab. https://gitlab.com/FreeDOS/base/fdhelper/-/tree/unstable/BIN 


All fairly simple to do. 

If you want to issue some pull requests with the changes thats fine. 

Otherwise, I’ll get to it sometime over the next few days. 

:-)

Jerome

Oh BTW... If your interested in seeing the RBE in action, or making builds 
locally, it’s very easy to install and create builds. You can read the 
instructions for installation into a virtual machine at 
https://gitlab.com/FreeDOS/OS/builder/-/wikis/home 


It’s been a while since I did a fresh install of the RBE. So, hopefully newer 
versions of the OS that runs the RBE haven’t broken the install or build 
process. 



> 
> Thanks! Bernd
> 
> [1] 
> https://gitlab.com/FreeDOS/base/htmlhelp/-/commit/621b781ee2bedc777dcf6f2c86065002f6d48000
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Ralf,

> On Feb 4, 2024, at 2:55 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:
>> Hi,
>> 
>>> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>>>  wrote:
>>> 
>>> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
>>>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
>>>> problem. You don't have to know a lick of C to recompile it.
>>> Well, part of the problem is that in order to recompile, you need to have 
>>> the compiler (toolchain) installed, which isn't necessarily easy for a 
>>> non-programmer.
>>> 
>>> 
>>> Ralf
>> I have occasionally compiled edlin to provide an updated version for FreeDOS.
>> 
>> As compile from source goes, EDLIN is not that bad. If I recall correctly, 
>> It just needs our Watcom-C to compile. Plus a little knowledge on options 
>> and such things.
>> 
>> In general, it is extremely cumbersome to acquire all the exact required 
>> pieces to accomplish. An fairly often after spending a few hours on trying 
>> to get a successful compile, I will end up giving up. Therefore, I do that 
>> very rarely anymore for almost anything.
> The problem with the whole NLS/i18n thing is that it is not only done with 
> just translating some text extruded from the sources. And recompiling some 
> programs which don't lend themselves well to the whole "kitten" shebang. It 
> would require a lot of testing, which needs to be done by someone with those 
> native language skills (plus some technical knowledge what it is all about). 
> A lot of command line tools might be fairly easy to do, but for anything that 
> is using a more formatted screen output, this also requires to check where 
> things are "overflowing" (for lack of a better term right now)/misalignment…

Yup. 

> And we have a very limited number of people that would have ALL the required 
> skills.

Yup. 

> IMHO, before getting too much wound up with everything that is involved, I 
> think we need to make sure to have a proper English version, for everything,

Yup. 

>> 
>> As discussed in the online meeting, it would be nice to include dependency 
>> requirements in the package metadata. This makes me think we could possibly 
>> include the build-dependency requirements as well. Plus a per package 
>> universal build batch. That would be a lot of work and probably require 
>> frequent updating when packages change.
> I see that there would be some effort initially to add that info, but 
> seriously, how much are dependencies as such changing for any given program 
> after that?

For small projects, not usually much changes or very often. 

On the other hand for large projects, sometimes different libraries come and 
go. But generally, the problem with these are based on specific versions of 
libraries. Or, sub-dependency libraries and their versions. 

However, I only extremely rarely make the exception and compile projects we 
distribute from source. So, the problem may not be as bad as I suspect.

>> 
>> But on the other hand, it would be very nice if all programs (excluding 
>> those made with commercial compilers like Turbo Pascal) could be built from 
>> source simply by installing the required build packages.
>> 
>> This leads me to think, maybe we should go back to the old days when sources 
>> were in their own separate package and not included in the binaries package.
>> 
> That was a move that I have never understood in the first place, as the vast 
> majority of people downloading FreeDOS are likely just interested in getting 
> it running, rather than doing any development. Specially if things aren't as 
> simple anymore as they (mostly) used to be in the days of DOS, too many 
> Linuxisms have crept in, which makes it so much harder for people that are 
> just trying to get back into DOS and haven't done anything programming wise 
> for the last 20-30 years, and then in things like BASIC or Turbo Pascal, 
> which are all "programma  non grata" for a lot of OSS license minded folks…

Furthermore, if the packages were split back into BIN and SRCS, we could 
provide the sources on a separate media. This could possibly cut the size of 
the release media in half. Maybe even alleviate the need for a BonusCD. 
Possibly just the LiveCD, LegacyCD and a SourcesCD. 

Change back to the split packages would require some tweaking to the installer 
and RBE. Probably FDIMPLES as well. Nothing to difficult. 

The online package repo management software used on ibiblio and fd.lod.bz is 
not designed for it. But, those places could just 

[Freedos-devel] HELP.BAT and other OS Batch files

[Jerome Shidel via Freedos-devel]

Hi Jim,

Per our discussion during the online meeting, if you are interested in updating 
some of the included connivence batch files (like HELP.BAT). Their home is at 
GitLab at in the FDHELPER project. https://gitlab.com/FreeDOS/base/fdhelper 


Some of those batch programs (WELCOME and CDROM) support NLS. Eventually, the 
others should be updated with NLS support as well. Anyway, simple changes to 
that text should be pushed to the FD-NLS project so the changes don’t get 
forgotten or accidentally overwritten by old translations. 
https://github.com/shidel/fd-nls 

Side note, the SETLANG.BAT is primarily used for setting the users language for 
the Floppy Edition Installer. However, it also worked nicely to quickly change 
languages when using the LiveCD. More work still needs done with regards to 
that. Also eventually, it would be great to have it switch languages on 
installed systems as well. 

Also, there is a placeholder batch called ONELANG.BAT. I think it would be nice 
to eventual have it support removing all additional languages if the user only 
wants to retain their current language. It could be nice on systems with 
limited storage space. 

:-)

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

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Hi, 

> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
>> problem. You don't have to know a lick of C to recompile it.
> 
> Well, part of the problem is that in order to recompile, you need to have the 
> compiler (toolchain) installed, which isn't necessarily easy for a 
> non-programmer.
> 
> 
> Ralf

I have occasionally compiled edlin to provide an updated version for FreeDOS. 

As compile from source goes, EDLIN is not that bad. If I recall correctly, It 
just needs our Watcom-C to compile. Plus a little knowledge on options and such 
things. 

In general, it is extremely cumbersome to acquire all the exact required pieces 
to accomplish. An fairly often after spending a few hours on trying to get a 
successful compile, I will end up giving up. Therefore, I do that very rarely 
anymore for almost anything.

As discussed in the online meeting, it would be nice to include dependency 
requirements in the package metadata. This makes me think we could possibly 
include the build-dependency requirements as well. Plus a per package universal 
build batch. That would be a lot of work and probably require frequent updating 
when packages change. 

But on the other hand, it would be very nice if all programs (excluding those 
made with commercial compilers like Turbo Pascal) could be built from source 
simply by installing the required build packages.

This leads me to think, maybe we should go back to the old days when sources 
were in their own separate package and not included in the binaries package. 

Jerome




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

Re: [Freedos-devel] Link for today's virtual meeting

[Jerome Shidel via Freedos-devel]

Hi Jim,

Interestingly, when you left the online meeting, it kept going at least for a 
few seconds until I clicked end-call. 

I don’t know if it would have kept going indefinitely.

We will have to try that next time.

:-)

Jerome

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

Re: [Freedos-devel] Cleaning up FDAUTO

[Jerome Shidel via Freedos-devel]

Hi Eric,

> On Feb 3, 2024, at 6:40 AM, Eric Auer via Freedos-devel 
>  wrote:
> 
> 
> Hi guys, thanks for cleaning up autoexec!
> 
>>> REM - streamlined the network test (user adds their own stuff anyway).
> 
> I hope they add it at a place where it actually gets to run :-)
> 
>>> set PATH=%DOSDIR%\BIN
>>> if exist %DOSDIR%\LINKS\NUL set PATH=%path%;%DOSDIR%\LINKS
> 
> A special test just for one app? I would prefer if LINKS came
> with a batch wrapper which gets placed in BIN, then PATH does
> not have to dynamically add the directory of LINKS.
> 
> If LINKS means such wrappers instead of the browser LINKS, then
> I suggest to just put all batch wrappers in the BIN directory.

That is not the LINKS browser. It is the LINKS path, for small batch files and 
launcher programs that whose directory is not in the PATH variable.

The path and small launchers usually exist. For example, when vim is installed 
a VIM.BAT is placed there to launch it. This prevents the PATH variable from 
growing so large it exceeds the command line length restriction.

> 
>>> set TZ=UTC
> 
> Personally, I prefer RTC having local time. Add a comment here?

The sources for FDAUTO used by the installer do not have this setting hard 
coded. 

However, at present the installer simply expands it to EST. But, we may change 
that eventually if need be.

> 
>>> alias reboot=fdapm warmboot
>>> alias reset=fdisk /reboot
> 
> You can also reboot with FDAPM COLDBOOT or FDAPM WARMBOOT.
> 
>>> :SUPPORT286
>>> 
>>> fdapm APMDOS
> 
> This sort of implies that HLT saves no power on 8086?
> On the other hand, 8086 are low on RAM, so it probably
> is best to load as few drivers as possible there, yes.
> 
> In a related thought, we should pick a KSSF swapping
> or otherwise non-XMS-swapping freecom command.com in
> ALL cases where no XMS driver is loaded. Be it because
> the CPU is too old, be it because the user choses some
> boot menu option without XMS drivers deliberately.

Well, this is base on the “Default” generic configuration files. 

It may be a better solution to make such changes in the platform specific 
versions of the files. 

> 
>>> ctmouse
> 
> You can compile CuteMouse for 8086, but that uses slightly
> more RAM. In addition, buggy versions exist where the 8086
> compile actually requires a newer CPU. Either way, as we
> are talking of mice and men, you may want to do this in an
> "either load this or load that ctmouse version" way instead
> of and "either load ctmouse or do not load it" way :-)
> 
>>> :SUPPORT386
>>> 
>>> if "%CONFIG%"=="4" goto SUPPORT386LOW
>>> 
>>> lh fdapm APMDOS
>>> REM lh share
> 
> In which way is SHARE 386 specific?
> 
>>> :SUPPORT386LOW
>>> 
>>> fdapm APMDOS
>>> ctmouse
> 
> So SHARE only gets loaded at all if loaded high?
> 
>>> if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat
> 
> Do we also have CD-ROM and DVD or BD drivers for 8086 or 286?

We do not have CD support for sub-386 machines. 

I do not recall if it is the device driver or multiplexer extension driver. 

> 
>>> if exist %DOSDIR%\bin\fdnet.bat call %DOSDIR%\bin\fdnet.bat start
>>> REM - add your own networking commands here: (if any)
> 
> I assume that batch autodetects networking at each boot?
> I believe people may just manually edit autoexec anyway.
> 
>>> if exist %DOSDIR%\bin\fdassist.bat call %DOSDIR%\bin\fdassist.bat
>>> if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat display
>>> if exist %DOSDIR%\bin\welcome.bat call %DOSDIR%\bin\welcome.bat
> 
> For my taste, the boot process is split into too many batch files.

Loading the CD drivers (like networking drivers) is not simply a single driver. 

There are multiple drivers that can be attempted which may or may not work for 
the users hardware. 
There are also drivers supported that are not and can not be provided with the 
FreeDOS release. 

Including all of that code in the FDAUTO would add an a good deal of complexity 
and confusion to the startup process.

Also, improvements to things like CD/DVD and NETWORKING support can be improved 
without concern of breaking 
anything in FDAUTO or the FDCONFIG files. 

> 
>>> REM nlsfunc %DOSDIR%\BIN\COUNTRY.SYS
>>> REM display CON=(EGA,858,2)
>>> REM mode CON CP PREP=((858) %DOSDIR%\CPI\EGA.CPX)
>>> REM keyb US,858,%DOSDIR%\bin\keyboard.sys
>>> REM chcp 858
>>> REM mkeyb UK
> 
> You probably want suggest to load all of those earlier.
> 
> If people just remove the REM, the font and keyboard
> drivers would get loaded quite late.
> 
> Regards, Eric
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

:-)

Jerome



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

Re: [Freedos-devel] Cleaning up FDAUTO

[Jerome Shidel via Freedos-devel]

Oh, one more thing.

When booting FreeDOS to “Safe Mode”, we probably do not want to load all of the 
drivers. 

Things like APM and networking should probably be skipped with that selection. 


> On Feb 3, 2024, at 5:27 AM, jer...@shidel.net wrote:
> 
> Wow, I should really wait until I’ve finished my first coffee before 
> responding to email. 
> 
> Or… 
> 
> Maybe, proofread before clicking send. Lots of typographic errors. 
> 
> LOL.
> 
> Jerome
> 
>> On Feb 3, 2024, at 5:20 AM, Jerome Shidel via Freedos-devel 
>> > <mailto:freedos-devel@lists.sourceforge.net>> wrote:
>> 
>> Hi Jim,
>> 
>>> On Feb 2, 2024, at 8:07 PM, Jim Hall via Freedos-devel 
>>> >> <mailto:freedos-devel@lists.sourceforge.net>> wrote:
>>> 
>>> Here's my second pass at cleaning up my FDAUTO.BAT file. If you like
>>> it, feel free to use it. This does a lot of streamlining from the
>>> "stock" FDAUTO.BAT in T2402.
>> 
>> Great idea. They can defiantly use simplification. The originals were made 
>> through the process of build, test, fix, build, text, fix, repeat and move 
>> on. They contained a lot of spaghetti and were long overdue for improvement. 
>> 
>> Just a couple notes for you while you work on them. 
>> 
>> 1) The initial reason behind the separation of the IF and actual CALLS to 
>> external batch files was based on command line file length restrictions. 
>> During the early days, if the user would install FreeDOS to a non-standard 
>> and longer %DOSDIR% issues could occur. However with later improvements, I 
>> don’t thing it is necessary any longer. Take the longest call out as an 
>> example:
>> 
>>>> if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat display
>> 
>> When the OS is installed to it’s default directory expands to:
>> 
>> if exist C:\FREEDOS\bin\cdrom.bat call C:\FREEDOS\bin\cdrom.bat display
>> (71 characters)
>> 
>> If the OS is installed to a non-standard directory, like 
>> C:\OS\DOS\FREEDOS\1.3\ (which I’ve done on multi-boot DOS systems), expands 
>> to:
>> 
>> if exist C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat call 
>> C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat display
>> (93 characters)
>> 
>> So, it is still fine and has room for about 15 more characters in the 
>> %DOSDIR%.
>> 
>> 2) Your changes have things loading after the WELCOME message. I think that 
>> the WELCOME message (and TEST BUILD warning) should be the last thing shown.
>> 
>> 3) These are not the only possible config files that may be installed. At 
>> present, there are 3 different FDAUTO files and 6 different FDCONFIG files 
>> that are installed based on various hardware platforms. 
>> 
>> Those can be found at: 
>> https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP 
>> <https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP>
>> 
>> There naming scheme is straight forward. AUTOEXEC.* becomes FDAUTO. CONFIG.* 
>> becomes FDCONFIG.SYS. There file extensions are based on the hardware 
>> platform.
>> 
>> *.DBX when installing to DOSBox.
>> *.VBX when installing to VirtualBox.
>> *.086 when installing to a 8086/8088 only.
>> *.186 when installing to a 80186 only.
>> *.286 when installing to a 20826 only.
>> *.DEF default file when no specific exact configuration file is 
>> required/provided.
>> 
>> Those files are used by both the Normal and Floppy Edition for installation. 
>> 
>> They also contain numerous simple macros that are processed by the 
>> installers during installation. 
>> 
>> Your changes will eventually need updated and ported and updated to these 
>> files. 
>> 
>> 4) See embedded comment(s) below.
>> 
>> 
>>> I've pared it down to just a few jump
>>> points that are more readable to me: HIGH, LOW, and LOCALCFG. At a
>>> high level, it's organized this way:
>>> 
>>> 1. "Global" settings
>>> 2. Test the CPU
>>> 3. If we can support it, use HIGH
>>> 4. If we can't, use LOW
>>> 5. Local settings
>>> 
>>> This doesn't really change the free memory (maybe a tiny savings, due
>>> to order) but the most important is that I think it's easier to read.
>>> See the REM blocks at the top to see what's changed from the "stock"
>>> FDAUTO.BAT from T2402: the first REM block is from my first pass, the
>>> second block is from my second pass.
>>> 
>>> I decided to remove the hard-coded AUTOFILE 

Re: [Freedos-devel] Cleaning up FDAUTO

[Jerome Shidel via Freedos-devel]

Wow, I should really wait until I’ve finished my first coffee before responding 
to email. 

Or… 

Maybe, proofread before clicking send. Lots of typographic errors. 

LOL.

Jerome

> On Feb 3, 2024, at 5:20 AM, Jerome Shidel via Freedos-devel 
>  wrote:
> 
> Hi Jim,
> 
>> On Feb 2, 2024, at 8:07 PM, Jim Hall via Freedos-devel 
>> > <mailto:freedos-devel@lists.sourceforge.net>> wrote:
>> 
>> Here's my second pass at cleaning up my FDAUTO.BAT file. If you like
>> it, feel free to use it. This does a lot of streamlining from the
>> "stock" FDAUTO.BAT in T2402.
> 
> Great idea. They can defiantly use simplification. The originals were made 
> through the process of build, test, fix, build, text, fix, repeat and move 
> on. They contained a lot of spaghetti and were long overdue for improvement. 
> 
> Just a couple notes for you while you work on them. 
> 
> 1) The initial reason behind the separation of the IF and actual CALLS to 
> external batch files was based on command line file length restrictions. 
> During the early days, if the user would install FreeDOS to a non-standard 
> and longer %DOSDIR% issues could occur. However with later improvements, I 
> don’t thing it is necessary any longer. Take the longest call out as an 
> example:
> 
>>> if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat display
> 
> When the OS is installed to it’s default directory expands to:
> 
> if exist C:\FREEDOS\bin\cdrom.bat call C:\FREEDOS\bin\cdrom.bat display
> (71 characters)
> 
> If the OS is installed to a non-standard directory, like 
> C:\OS\DOS\FREEDOS\1.3\ (which I’ve done on multi-boot DOS systems), expands 
> to:
> 
> if exist C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat call 
> C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat display
> (93 characters)
> 
> So, it is still fine and has room for about 15 more characters in the 
> %DOSDIR%.
> 
> 2) Your changes have things loading after the WELCOME message. I think that 
> the WELCOME message (and TEST BUILD warning) should be the last thing shown.
> 
> 3) These are not the only possible config files that may be installed. At 
> present, there are 3 different FDAUTO files and 6 different FDCONFIG files 
> that are installed based on various hardware platforms. 
> 
> Those can be found at: 
> https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP 
> <https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP>
> 
> There naming scheme is straight forward. AUTOEXEC.* becomes FDAUTO. CONFIG.* 
> becomes FDCONFIG.SYS. There file extensions are based on the hardware 
> platform.
> 
> *.DBX when installing to DOSBox.
> *.VBX when installing to VirtualBox.
> *.086 when installing to a 8086/8088 only.
> *.186 when installing to a 80186 only.
> *.286 when installing to a 20826 only.
> *.DEF default file when no specific exact configuration file is 
> required/provided.
> 
> Those files are used by both the Normal and Floppy Edition for installation. 
> 
> They also contain numerous simple macros that are processed by the installers 
> during installation. 
> 
> Your changes will eventually need updated and ported and updated to these 
> files. 
> 
> 4) See embedded comment(s) below.
> 
> 
>> I've pared it down to just a few jump
>> points that are more readable to me: HIGH, LOW, and LOCALCFG. At a
>> high level, it's organized this way:
>> 
>> 1. "Global" settings
>> 2. Test the CPU
>> 3. If we can support it, use HIGH
>> 4. If we can't, use LOW
>> 5. Local settings
>> 
>> This doesn't really change the free memory (maybe a tiny savings, due
>> to order) but the most important is that I think it's easier to read.
>> See the REM blocks at the top to see what's changed from the "stock"
>> FDAUTO.BAT from T2402: the first REM block is from my first pass, the
>> second block is from my second pass.
>> 
>> I decided to remove the hard-coded AUTOFILE and CFGFILE entries, since
>> a user could rename their FDCONFIG.SYS to CONFIG.SYS (but the
>> hard-coded values would still show the old FDCONFIG.SYS). The boot-up
>> welcome message expects these values when it prints them out, but
>> that's an easy fix.
>> 
>>> @ECHO OFF
>>> 
>>> REM - updated FDAUTO boot file
>>> 
>>> REM - changes: all command names are lowercase, all env vars uppercase,
>>> REM - all "REM" are uppercase, all goto labels are uppercase.
>>> REM - "mem" moved to end. All empty "echo." statements removed.
>>> REM - streamline INITCDROM (only needs to be one line).
>>> REM - streadmli

Re: [Freedos-devel] Cleaning up FDAUTO

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Feb 2, 2024, at 8:07 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> Here's my second pass at cleaning up my FDAUTO.BAT file. If you like
> it, feel free to use it. This does a lot of streamlining from the
> "stock" FDAUTO.BAT in T2402.

Great idea. They can defiantly use simplification. The originals were made 
through the process of build, test, fix, build, text, fix, repeat and move on. 
They contained a lot of spaghetti and were long overdue for improvement. 

Just a couple notes for you while you work on them. 

1) The initial reason behind the separation of the IF and actual CALLS to 
external batch files was based on command line file length restrictions. During 
the early days, if the user would install FreeDOS to a non-standard and longer 
%DOSDIR% issues could occur. However with later improvements, I don’t thing it 
is necessary any longer. Take the longest call out as an example:

>> if exist %DOSDIR%\bin\cdrom.bat call %DOSDIR%\bin\cdrom.bat display

When the OS is installed to it’s default directory expands to:

if exist C:\FREEDOS\bin\cdrom.bat call C:\FREEDOS\bin\cdrom.bat display
(71 characters)

If the OS is installed to a non-standard directory, like C:\OS\DOS\FREEDOS\1.3\ 
(which I’ve done on multi-boot DOS systems), expands to:

if exist C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat call 
C:\OS\DOS\FREEDOS\1.3\bin\cdrom.bat display
(93 characters)

So, it is still fine and has room for about 15 more characters in the %DOSDIR%.

2) Your changes have things loading after the WELCOME message. I think that the 
WELCOME message (and TEST BUILD warning) should be the last thing shown.

3) These are not the only possible config files that may be installed. At 
present, there are 3 different FDAUTO files and 6 different FDCONFIG files that 
are installed based on various hardware platforms. 

Those can be found at: https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP 


There naming scheme is straight forward. AUTOEXEC.* becomes FDAUTO. CONFIG.* 
becomes FDCONFIG.SYS. There file extensions are based on the hardware platform.

*.DBX when installing to DOSBox.
*.VBX when installing to VirtualBox.
*.086 when installing to a 8086/8088 only.
*.186 when installing to a 80186 only.
*.286 when installing to a 20826 only.
*.DEF default file when no specific exact configuration file is 
required/provided.

Those files are used by both the Normal and Floppy Edition for installation. 

They also contain numerous simple macros that are processed by the installers 
during installation. 

Your changes will eventually need updated and ported and updated to these 
files. 

4) See embedded comment(s) below.


> I've pared it down to just a few jump
> points that are more readable to me: HIGH, LOW, and LOCALCFG. At a
> high level, it's organized this way:
> 
> 1. "Global" settings
> 2. Test the CPU
> 3. If we can support it, use HIGH
> 4. If we can't, use LOW
> 5. Local settings
> 
> This doesn't really change the free memory (maybe a tiny savings, due
> to order) but the most important is that I think it's easier to read.
> See the REM blocks at the top to see what's changed from the "stock"
> FDAUTO.BAT from T2402: the first REM block is from my first pass, the
> second block is from my second pass.
> 
> I decided to remove the hard-coded AUTOFILE and CFGFILE entries, since
> a user could rename their FDCONFIG.SYS to CONFIG.SYS (but the
> hard-coded values would still show the old FDCONFIG.SYS). The boot-up
> welcome message expects these values when it prints them out, but
> that's an easy fix.
> 
>> @ECHO OFF
>> 
>> REM - updated FDAUTO boot file
>> 
>> REM - changes: all command names are lowercase, all env vars uppercase,
>> REM - all "REM" are uppercase, all goto labels are uppercase.
>> REM - "mem" moved to end. All empty "echo." statements removed.
>> REM - streamline INITCDROM (only needs to be one line).
>> REM - streadmline SUPPORT386 (move test to top).
>> REM - moved local settings to FINAL.
>> REM - streamlined the LFN test (REM'd out anyway).
>> REM - streamlined the network test (user adds their own stuff anyway).
>> REM - removed unneeded ONLY8086 section (prev now jumps to FINAL).
>> 
>> REM - moved ctmouse to the end (local settings)
>> REM - moved DIRCMD and CPYCMD to the end (local settings)
>> REM - moved init cdrom to FINAL, removed INITCDROM goto label
>> REM - renamed FINAL to LOCALCFG
>> REM - removed hard-coded AUTOFILE and CFGFILE entries, and REM'd aliases
>> REM -   ..this breaks the welcome message, but fix that later
>> REM - moved aliases to LOCALCFG
>> REM - renamed SUPPORT286 and SUPPORT386 to SIMPLE and HIGH clearer)
>> REM - renamed SUPPORT386LOW to LOW
>> REM - actually, SIMPLE is not needed (same as LOW) so changed vinfo goto
>> REM -   ..and removed SIMPLE block
>> REM - expanded MEM /C /N to MEM /C /NOSUMMARY
>> REM - added vinfo tests for 101-104
>> REM - moved config 4 test up, next to config 5 test, 

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Jerome Shidel via Freedos-devel]

Hi Eric, 

> On Feb 1, 2024, at 9:32 AM, Eric Auer via Freedos-devel 
>  wrote:
> 
> 
> Hi Jerome, thanks for the updates! :-)
> 
>> The FreeDOS Interim Test Build T2402 for February is now available for 
>> download at:
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 
>> 
>> Changes since T2401:
> 
> What specifically has changed in those packages?

For these: They are version updates. 

>> 2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
>> 2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
>> 2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
>> 2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
>> 2024-02-01 05:17:54 sleep (shidel): updated to 1.1
>> 2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
>> 2024-01-31 18:00:28 lzop (shidel): updated to 1.04
>> 2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21

For these: They are translation file and package description updates.

>> 2024-01-31 17:27:19 sqlite (shidel): TR package description updated
>> 2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
>> 2024-01-31 17:22:46 clamdb (shidel): TR package description updated
>> 2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
>> cardpuncher/master
>> 2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
>> andrewbird/kittenc-fixup
>> Thanks to Willi for pointing out the software that needed updated.
>> Jerome
> 

As for what specifically changed in each of those version updates, I couldn’t 
say. 

You would need to check the change log (if any) that is included in the 
respective package. 

With the wide range of text formatting and locations used by individual 
projects, I have not attempted to automate a method to parse individual project 
change logs to create a detailed summary of individual project changes. 

Although there is a lot of automation that is performed when I update packages, 
the overall process is still very time consuming. For example, from start to 
finish these few updates still took about 7 hours (from start to finish) to 
perform. However, a good piece of that time (maybe 3+ hours) was used by the 
automated tools chewing on the FreeBASIC files for things like timestamp 
preservation. 

Unfortunately, I just cannot dedicate the time required to cobble together such 
a detailed change list manually.

Thankfully, the entire process for both Interim Test Builds and Actual Release 
Builds is fully automated. All I need to do is fire up a related virtual 
machine and run “make”. The RBE will perform all the work to configure things 
and assemble a release from scratch. I come back an hour or so later and if 
there were no package or other issues (like size limitations) a release will be 
waiting.

Jerome





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

[Freedos-devel] FreeDOS Interim Build T2402

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2402 for February is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes since T2401:

2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21
2024-01-31 17:27:19 sqlite (shidel): TR package description updated
2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
2024-01-31 17:22:46 clamdb (shidel): TR package description updated
2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
cardpuncher/master
2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
andrewbird/kittenc-fixup

Thanks to Willi for pointing out the software that needed updated.

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

Re: [Freedos-devel] Next FreeDOS virtual get-together

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Jan 19, 2024, at 4:58 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> Hi everyone!
> 
> I promised to propose the next virtual get-together after the holiday
> break, so here it is. :-)
> 
> How about Sunday, February 4 for the next get-together? That's three
> Sundays from now.
> 
> Time is 11am to noon US/Central, same time as always. And we'll
> probably go over that, because we always do. :-)
> 
> 
> Jim

Did you decide on the new conferencing software? 

Jerome

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

[Freedos-devel] Bug: SET /E

[Jerome Shidel via Freedos-devel]

Hi All,

This bug has been around a very long time. I just did not think of mentioning 
it until now.

The FreeCOM SET /E bug is easy to reproduce by trying to use I/O redirection.

Example:

set /e TEST=time /d | more

Now, the behavior of pipe here is debatable. 
It could redirect from “time /d” into “set /e TEST=“. 
Or, it redirect the output from “set /e TEST=time /d” instead.
What it should not do is crash the system. 

At present, attempting that will lock up the system with a repeated PC speaker 
beep and require a reboot.

Other uses of SET do not seem to cause this issue.

For example:

echo one | set /p TEST= | echo two

Outputs two and stores one in the TEST variable. 

(Note: not redirecting input to SET when using /P will cause the system to wait 
on a carriage return from the console. That is expected behavior.)

Jerome


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

[Freedos-devel] FreeDOS Interim Build T2401

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2401 for January is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Although this update consists of only a few simple changes, it is an important 
update from T2312.

There were several packages that erroneously included a ‘.DATESTAMP’ file. 
During installation of those packages it could cause a file conflict and 
failure to install some packages. The file was not related to package 
management or the ’.TIMESTAMP’ file used to preserve file date time stamps when 
working with version control systems. It was from a different utility and meant 
for local system usage only. I think I purged all of them. If I missed any, 
please let me know.

Unlike the large number of updates in T2312, there were no other significant or 
package updates in T2401.

Jerome

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

Re: [Freedos-devel] Learning DOS assembly programming

[Jerome Shidel via Freedos-devel]

Hi,

> On Dec 26, 2023, at 11:42 AM, Jim Hall via Freedos-devel 
>  wrote:
> 
> I actually never learned DOS assembly programming, but decided I'd
> like to start.
> 
> What assembler do you recommend, and where is a good place to start
> learning about DOS assembly programming? Start with a "Hello world"
> program and eventually move up to writing an assembly version of TYPE
> and CHOICE, things like that.
> 
> I was thinking about NASM, since it's open source and we include it in
> the distribution. Looking around, I found a bunch of tutorials on
> https://asmtutor.com/ that look easy enough to follow, although it's
> for Linux. Any similar tutorials to learn DOS assembly programming?
> 
> Or would you recommend a different DOS assembler (and how-to guide) as
> a place to start?
> 

Almost everything that I do nowadays (for FreeDOS) is in assembly using NASM. 

For example, V8Power Tools is all done in NASM. (However, there was no “design” 
or any plan during its creation. It simply was written organically based on the 
immediate needs for the installer. It is a massive bowl of spaghetti with very 
few comments. I would not advise studying it to learn assembly.)

This kind of makes me want to write a series of videos on writing assembly for 
DOS using NASM. Starting with the very basics on up through advanced topics. 

:-)

Jerome

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



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

Re: [Freedos-devel] FreeDOS Interim Build T2312

[Jerome Shidel via Freedos-devel]

Minor correction in T2312 notice email...

> On Dec 2, 2023, at 3:58 PM, Jerome Shidel via Freedos-devel 
>  wrote:
> 
> Hi All, 
> 
> The FreeDOS Interim Test Build T2312 for December is now available for 
> download at:
> 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
> 
> Sorry, it is a day late. I’ve been occupied with other things.
> 
> Thank you Willi for the reminder. :-)
> 
> There are a bunch of updated programs this month:
> 
> 2023-11-22 21:20:33 fdisk [unstable] (Bernd Boeckmann): release 1.3.11
> 2023-11-22 03:16:29 doszip (shidel): updated to v2.65
> 2023-11-21 10:05:28 nethack (shidel): update to v3.6.7
> 2023-11-21 09:26:59 empong (shidel): updated to v0.92
> 2023-11-21 09:18:46 dosdef (shidel): updated to v1.1.0
> 2023-11-21 09:07:17 utf8tocp (shidel): updated to v0.9.5
> 2023-11-21 04:10:45 curl (shidel): updated to v8.4.0
> 2023-11-21 02:51:20 edlin (shidel): updated to v2.23
> 2023-11-20 21:05:29 links (shidel): updated to v2.29
> 2023-11-20 20:00:09 dosmid (shidel): updated to v0.9.7
> 2023-11-20 10:03:00 upx (shidel): updated to v4.2.1
> 
> Plus some new language translations:
> 
> 2023-11-20 13:29:16 doslfn (shidel): updated NLS
> 2023-11-20 12:18:29 usbdos (shidel): added NL translation
> 2023-11-20 11:46:49 fdisk [unstable] (shidel): added NL translation
> 2023-11-20 11:44:24 fdshell (shidel): added NL translation
> 2023-11-20 11:40:05 mirror (shidel): added NL translation
> 2023-11-20 10:10:17 label (shidel): added NL translation
> 2023-11-13 22:21:14 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to label
> 2023-11-12 01:14:20 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to fdshell
> 2023-11-12 01:07:53 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to dosusb.
> 2023-11-12 00:35:23 project_FD-NLS (Gert Van Waelvelde): Create mirror.nl
> 2023-11-12 00:17:11 project_FD-NLS (Gert Van Waelvelde): Create fdisk.nl
> 2023-11-01 06:08:38 dojs (shidel): Updated to version 1.11.0

dojs should be in the first list with the other updated programs. :-)

That makes 12 updates for this month. 

It might keep you busy through DOSember. 

:-)

Jerome

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

[Freedos-devel] FreeDOS Interim Build T2312

[Jerome Shidel via Freedos-devel]

Hi All, 

The FreeDOS Interim Test Build T2312 for December is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Sorry, it is a day late. I’ve been occupied with other things.

Thank you Willi for the reminder. :-)

There are a bunch of updated programs this month:

2023-11-22 21:20:33 fdisk [unstable] (Bernd Boeckmann): release 1.3.11
2023-11-22 03:16:29 doszip (shidel): updated to v2.65
2023-11-21 10:05:28 nethack (shidel): update to v3.6.7
2023-11-21 09:26:59 empong (shidel): updated to v0.92
2023-11-21 09:18:46 dosdef (shidel): updated to v1.1.0
2023-11-21 09:07:17 utf8tocp (shidel): updated to v0.9.5
2023-11-21 04:10:45 curl (shidel): updated to v8.4.0
2023-11-21 02:51:20 edlin (shidel): updated to v2.23
2023-11-20 21:05:29 links (shidel): updated to v2.29
2023-11-20 20:00:09 dosmid (shidel): updated to v0.9.7
2023-11-20 10:03:00 upx (shidel): updated to v4.2.1

Plus some new language translations:

2023-11-20 13:29:16 doslfn (shidel): updated NLS
2023-11-20 12:18:29 usbdos (shidel): added NL translation
2023-11-20 11:46:49 fdisk [unstable] (shidel): added NL translation
2023-11-20 11:44:24 fdshell (shidel): added NL translation
2023-11-20 11:40:05 mirror (shidel): added NL translation
2023-11-20 10:10:17 label (shidel): added NL translation
2023-11-13 22:21:14 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to label
2023-11-12 01:14:20 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to fdshell
2023-11-12 01:07:53 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to dosusb.
2023-11-12 00:35:23 project_FD-NLS (Gert Van Waelvelde): Create mirror.nl
2023-11-12 00:17:11 project_FD-NLS (Gert Van Waelvelde): Create fdisk.nl
2023-11-01 06:08:38 dojs (shidel): Updated to version 1.11.0

:-)

Jerome


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

Re: [Freedos-devel] Question about JEMM license

[Jerome Shidel via Freedos-devel]

Hi,

> On Nov 29, 2023, at 2:57 PM, Jim Hall via Freedos-devel 
>  wrote:

> [..]

> The source to JEMM386/JEMMEX is in the "src" directory. Several of the
> *.ASM files indicate public domain. Here are the exceptions that I
> found:
> 
> src/DMA.ASM
> ;--- DMA port trapping code
> ;--- originally written by Harald Albrecht
> ;--- modified for Jemm by Japheth
> ;--- copyright (c) 1990 c't/Harald Albrecht
> 
> src/EMS.ASM
> ;--- EMS implementation
> ;--- EMS 4.0 is Public Domain, originally written by Michael Devore,
> ;--- extended and modified for Jemm by Japheth
> ;--- the EMS 3.2 part is copyrighted and has therefore
> ;--- been moved into a separate include file (EMS32.INC)
> 
> src/EMU.ASM
> ;--- privileged opcode emulation
> ;--- copyright Tom Ehlert
> 
> src/INIT16.ASM
> *No source comments, but found this oin line 152:
> szCopyRight DB NAMEMOD, '. Parts (c) tom ehlert 2001-2006 c''t/H.
> Albrecht 1990', LF, 0
> 
> src/JEMM32.ASM
> ;*
> ;** This is the main 32bit ASM part of JEMM.
> ;**
> ;** JEMM contains code of FreeDOS Emm386, which in turn used the source of
> ;** an EMM made public in c't (a german IT magazine) in 08/90, page 214,
> ;** written by Harald Albrecht.
> ;**
> ;** some parts the code which is based on FD Emm386 is copyright protected and
> ;** licensed under the Artistic License version (see LICENSE.TXT for details).
> ;**
> ;** 1. EMS 3.2 functions (file EMS32.INC)
> ;**   (c) 1990   c't/Harald Albrecht
> ;**   (c) 2001-2004  tom ehlert
> ;** 2. DMA support (file DMA.ASM)
> ;**   (c) 1990   c't/Harald Albrecht
> ;** 3. privileged opcode emulation (file EMU.ASM)
> ;**   (c) 2001-2004  tom ehlert
> ;**
> ;** The rest of the 32bit source is Public Domain.
> ;**
> ;*
> 
> 
> Those are the only *.ASM files that don't seem to be public domain.
> These seem to originate from an article written by Harald Albrecht in
> C't magazine, but I searched their website and couldn't find the
> article. I may have found something in the archives, but it requires
> purchasing the backissue to find out, and I didn't do that.
> 
> I don't know what license C't uses for code published in their
> magazines. From other magazines I've written articles for (about
> programming) the source code is usually released into the public
> domain, or at least some very broad permissive license, because
> readers are encouraged to reuse it to learn more about the topic.

As you say, the code based on articles is most likely under a very
loose license or public domain.

I guess it is also possible that something similar to what occurred with 386Max.

If you recall, 386Max was originally commercial software, But, a little
while back the source code was open sourced. However, none of the 
code comments was updated to reflect the change. The sources even
still contain all the user registration code as well. As it sits, 386Max is
not usable as open source as it stands now. But, it is open source
and someone could spend the time updating the comments and removing
the registration stuff. Or, us it in another project.

It would probably be a good idea to clear up any possible confusion with
the code’s license.  
:-)

Jerome



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

Re: [Freedos-devel] Question about USBDOS license

[Jerome Shidel via Freedos-devel]

Hi Bret,

> [..]
>> I see the point with item 5. However, the mention of a "..directly
>> from a web site that charges a 'registration fee'.." seems (to me) to
>> be specific to sites that charge a mandatory fee to access files.
> 
> That is correct.  Voluntary donations to a website owner are fine, as long as 
> they really are voluntary.  E.g., a site that gives special privileges to 
> Patreon donors would be a violation, even if the USBDOS files were not 
> "behind" the Patreon firewall since that would be an indirect charge for 
> maintaining the website.

> [..]
>> So, looking closely at item "5" in the license, I think it's okay to
>> keep hosting this on the FreeDOS Files Archive at Ibiblio, and keep a
>> copy on GitLab.
> 
> That's fine.

Ok, now I’m confused.

You say that keeping a copy on ibiblio and GitLab is fine. That is great. :-)

But earlier in your reply… You mention that if a site provides some features 
only to paying members, that site cannot provide USBDOS. Even when that site 
provides USBDOS to non-paying members and not even membership is required to 
download USBDOS.

I fail to see how GitLab can qualify to provide a copy for download. GitLab has 
many features that are only available to paying members. 

Please explain how this is okay, but a feature provided to a Patreon donator is 
not. To me, it seems to be a contradiction.

Thanks

:-)

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

[Freedos-devel] Monthly Get-together

[Jerome Shidel via Freedos-devel]

Hi all,

Is there a FreeDOS online get-together today (Sunday 11/26/2023)? 

Jerome


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

Re: [Freedos-devel] special old DOS software looking for a place online

[Jerome Shidel via Freedos-devel]

Hi Eric, 

> On Nov 22, 2023, at 6:30 PM, Eric Auer via Freedos-devel 
>  wrote:
> 
> 
> Hi developers!
> 
> As you may remember, I wrote a rather specialized eyetracking software
> called NEWTRACK *long* ago. It is open source, written in DJGPP GNU C
> and works with dual PCI VGA/VESA graphics. Given that I have no working
> web domain at the moment, would anybody be interested in mirroring it?
> 
> The whole directory with docs (PDF and PS.GZ), CWSDMPI and index.html
> is less than one megabyte in size. This software is for eye-tracking
> with eyetrackers with analog output and two simple bit-banged LTC1286
> A/D on the printer port, which also has reaction buttons wired to it.
> Example adapter schematics are included as eps and fig graphics files.
> 
> You can imagine that this feels rather "retro" today. Everybody uses
> cameras and image processing instead for tracking eye movements today.
> 
> Still the software is interesting, among other things, as example
> for dual PCI (or PCIe) VGA access with VESA on one screen for PCX.
> It has precision timestamping with RDTSC, too :-)
> 
> Thank you! Regards, Eric
> 
> 

Sure, I can put put it on my server.

Most likely somewhere under https://fd.lod.bz/redist/

That path contains stuff not in the FreeDOS repos for various reasons. Like 
MBRTOOL, that can be freely redistributed. But for license reasons, cannot be 
made into a package or provided with the OS. 

Just email me a zip with everything in it and I’ll put it up there.  

If there is anything else you’d like up there, just let me know.

:-)

Jerome

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

[Freedos-devel] FreeDOS Interim Build T2311

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2311 for November is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


:-)

Jerome

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

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

[Jerome Shidel via Freedos-devel]

Hi, 

> On Oct 3, 2023, at 9:20 PM, Danilo Pecher via Freedos-devel 
>  wrote:
> 
> I think the developer tools should go to the bonus CD. As was
> mentioned, most FreeDOS users will probably use it to run legacy apps
> and games. People who still have the knowledge to do some
> honest-to-god proper DOS programming will probably be quite able to
> switch the CD and install the stuff from the Bonus-CD or perhaps even
> a dedicated developer CD, which then could include some libraries
> (like pdcurses) and - a real must really - a version of Ralph Brown's
> Interrupt list.
> 
> I would also move VIM to the bonus disk as most 'normal' users won't
> have a scooby-doo what to do with it.
> 
> VIM, Watcom, GCC IA16 and FPC are large packages and would free up a
> lot of space on the Live-CD for other stuff more suitable to the
> casual user.
> 
> Speaking of installing packages. I'm really reaching the end of my
> tether with FDIMPLES. Has that ever been tested on real metal?

Yes, on multiple real machines.

> It runs
> fine in VMWare, but lob it on a 33Mhz 386 and you're in for a very
> sluggish experience.

Although FDIMPLES will run on nearly all hardware 8086 and up), it gets very 
sluggish on sub-486 hardware. 

There are several reasons for this. First, you are not viewing a simple list of 
programs. For each item, the program pulls in data from multiple files, 
directories and locations. Plus even more when viewing in language other than 
English. There can be upwards of 12 (or more) files/data points per item that 
are loaded, analyzed, parsed, combined and formatted for display.  There is a 
good deal of processing going on behind the scenes.

All of that data is handled through a caching system built into the program for 
the megabytes of processed data. When program memory is low, the cache discards 
the least needed information first. 

Do to the memory requirements of the external utilities used by FDIMPLES, the 
version provided with FreeDOS 1.3 was limited to a very small cache. This meant 
only a few things could be stored it memory at a time. 

More recent versions (on recent interim builds) use a few tricks to get around 
that problem and can use all of lower memory. This provided a great performance 
boost on slower machines. But, you might be surprised on how much data is 
processed and stored by the program. It can eat up all of lower memory rather 
quickly.  Support for XMS memory will probably be added at some point to help 
alleviate the need of reloading/reprocessing cached data.

FDIMPLES also permits navigation while still loading/processing an item. Doing 
so causes the program to abort processing of the item it is working on, 
discarding that data and moving to the requested item. 

The checking for a navigation request is only performed a specific points 
during the processing of an item. This is primary reason for perceived lag in 
the user interface during navigation on sub-486 hardware. 

Adding more places that per item processing would improve the perceived lag a 
lot. But, there is a lot of memory in use, open files, etc that need cleaned up 
when that occurs. I would not say it would be difficult to add. Just that there 
is some complexity involved and such “break” points are non-trivial.

There a numerous ways that FDIMPLES can be improved. Things like improved 
responsiveness, reduced processing, improved memory and cache management, 
network and multiple repository support, searching and mouse support are just a 
few. Most of which will probably not happen until the next major version. 

Unfortunately, I am very time constrained now and for the foreseeable future. 
The next major version will be a long time coming. 


> I've switched to just pumping the packages
> manually with unzip.

Although this will work well enough for many of the zips, I highly recommend 
NOT extracting the packages with unzip. 

Most of the directories in the packages are pseudo-paths and not 
subdirectories. Those pseudo-paths get remapped by the package manager to file 
system paths during installation.

For many packages, this won’t matter. But for some, they are configured for 
specific locations. A simple unzip, will result in files not being where they 
are expected. 

Using command line package managers like FDNPKG and FDINST instead of unzip 
will help prevent such configuration issues. They perform the pseudo-path 
remapping that may be required.

> 
> cheers, Danilo
> 

Jerome


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


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

Re: [Freedos-devel] FreeDOS Interim Build T2310

[Jerome Shidel via Freedos-devel]

Hi Jim,On Oct 1, 2023, at 5:06 PM, Jim Hall via Freedos-devel  wrote:I want to compile some things using IA-16 GCC in the new Interim BuildT2310, but neither the LiveCD or BonusCD have the DJGPP Environmentpackage on it. We had this on previous FreeDOS installs; to compilewith IA-16 GCC, you need to set the DJGPP environment variable to aDJGPP.ENV file.Or is the DJGPP Environment package on one of the ISOs, and I'vemissed it somehow?This is the package from FD13:http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/djgpp.htmlThe DJGPP are massive. There is not enough room on the CDs for everything else when DJGPP is included. Off-hand I think those packages require something like 350Mb.Plus… there have been “complaints” that the DJGPP needed updating and some other tools/packages should also get included.I’m not a DJGPP user and don’t want to break those packages. So, I’m not updating them. However, Paul Dufresne was working on the packages in the FreeDOS archive. Unfortunately, I think that work has stagnated. Also, since DJGPP uses some much space. The community still needs to decide how we are going to handle the problem. Some discussion was done here about a year ago. But, that also remains unresolved.I don’t know what the minimum required packages would be. Or, how much space they would require.  It might be possible to just include a few of them on either the install or bonus media.Possibly leave out some other packages to make room for some of the DJGPP packages. But in general, users tend to become very unhappy when something the use gets removed.Maybe it would be best to move nearly all Development packages to a DevelCD. Leaving only a couple very common tools (like NASM, UPX and a C compiler) on the main install/bonus media. With large packages (like Perl, FPC, DJGPP, etc) only on a DevelCD.The community needs to decide how we are going to handle the lack of sufficient storage capacity on the release media. In the meantime, the DJGPP packages have been sitting in limbo. Jerome___Freedos-devel mailing listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2310

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2310 for October is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/

Summary of changes since T2308.

2023-09-29 05:10:13 wcd (shidel): updated to v6.0.5
2023-09-28 16:03:00 project_FDI-x86 [unstable] (shidel): Merge branch 
'unstable' of github.com:shidel/FDI-x86 into unstable
2023-09-28 16:02:49 project_FDI-x86 [unstable] (shidel): added FDISK NLS to x86 
floppy exculsion
2023-09-28 14:55:46 project_RBE (shidel): improved floppy file cleanup
2023-09-28 07:55:16 project_FDI [unstable] (shidel): Adjust file cleanup list
2023-09-26 06:00:59 project_FD-NLS (shidel): Merge pull request #174 from 
cardpuncher/master
2023-09-12 17:35:47 project_FD-NLS (cardpuncher): Add files via upload
2023-09-01 09:00:33 project_FDI [unstable] (shidel): remove FDISK.LNG from 
install media
2023-09-01 06:06:15 doslfn (shidel): updated FR Help
2023-09-01 06:03:32 project_FD-NLS (shidel): Merge pull request #173 from 
cardpuncher/master
2023-09-01 05:54:12 project_FDI [unstable] (shidel): exclude FDISK.LNG from 
setup disks, not enough space on 720k floppy
2023-08-31 23:45:14 project_FD-NLS (cardpuncher): Add files via upload
2023-08-27 14:27:59 fdisk [unstable] (Bernd Boeckmann): version 1.3.9
2023-08-12 14:40:00 upx (shidel): updated to v4.1.0
2023-08-12 14:02:46 spool (shidel): added compiled version of BUFFERP.COM

:-)

Jerome



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

Re: [Freedos-devel] Interim Build Delayed

[Jerome Shidel via Freedos-devel]

Hi All,

I finally had a little time today to dig into: 

"Why T2309 build was ignoring the directive to exclude the external FDISK 
Language file and was running out of space on the 720k boot floppy diskette."

After spending an hour or so trying to debug the RBE to locate the problem, the 
problem finally dawned on me….

The exclusion file list for the Floppy Edition is stored in the FDI-x86 
installer project. Along with lists that determine what packages are on the 
boot media and which packages get installed. I had only added the exclusion 
directive to just the “master” branch of that project and not the “unstable” 
branch. 

So, I just rolled back all the changes I made to the RBE. Then, once I updated 
the list in the “unstable" project branch for FDI-x86 to exclude the file, the 
RBE successfully created an Interim Release Build. 

Since this month is almost over, there is little reason to provide a T2309 
build now. So, I’m just going to skip it. 

We should be good for providing the T2310 Interim Build at the start of October 
in a few days. 

Jerome

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

Re: [Freedos-devel] Ré : unstable should be build from unstable branch

[Jerome Shidel via Freedos-devel]

Hi,

> On Sep 17, 2023, at 10:56 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> 
> Rereading dates on:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/devel/
> most packages are not very recent... ldegug is... upx from this year, but 
> other relatively old.
> 
> I have:
> Title:DJGPP.GCC
> Version:  12.2.0
> Entered-date: 2022-08-31
> 
> The date in the repository is 2022-09-02
> so it should have been built with version 12.2 ... I think.
> 
> But my idea that all packages are rebuilt automatically each month is clearly 
> wrong.
> 

When the FreeDOS update monthly/interim build is created, packages are pulled 
directly from the FreeDOS project packages on GitLab. That build will pull the 
“unstable” branch of those projects when that branch of it exists. Otherwise 
the “master” branch is used. It then compress them into packages and builds the 
release.

A “final” release will only pull from the master branches.

This has nothing to do with the packages stored at ibiblio. Updates to those 
packages are done manually. Not all repositories there receive all updates. 
Some updates are also postponed for other reasons as well. 

“Latest” does not mean latest version. It simple means latest version in those 
repositories.



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

Re: [Freedos-devel] Interim Build Delayed

[Jerome Shidel via Freedos-devel]

Hi Bernd,

> On Sep 1, 2023, at 1:04 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Well, I think it's me to blame ;-)
> 
> I will try to build some compression mechanism into AMB, so that the help 
> files get smaller. The main FreeDOS help file would also benefit from that, I 
> think.
> 
> Bernd

If you look at the 720k boot floppy from T2308, I think there is about 29k free 
on the diskette. 

FDISK.EXE went from 69k (I think) to 39k EXE + a 89k FDISK.LNG. Increasing by 
about 40k. 

It seems to work fine without the LNG file. So once I can get to figuring out 
why the RBE is not excluding the LNG file like it is told (probably file name 
case, dir or something simple), it will fit in the small floppy.

But… Compression help files would probably be a good thing as well.

Jerome


> 
>> On 01.09.2023 16:49, Jerome Shidel via Freedos-devel wrote:
>> Hi All,
>> 
>> The FreeDOS Monthly Interim Build for September will be delayed.
>> 
>> The latest version of FDISK includes a large language translation file. That 
>> file is preventing the 720k Floppy version from building. Normally, I would 
>> just tell the RBE to exclude that file. There are a number of such 
>> exclusions already for files that are not required on the install media. 
>> However for some reason, the file is not being excluded when told and the 
>> build runs out of space and fails.
>> 
>> Unfortunately, I am extremely busy with other things unrelated to FreeDOS at 
>> present. So, I do not know how long it will be until I find time to resolve 
>> this issue. It has been quite a while since I’ve done any work on the RBE. 
>> So, it may take a little while to figure out why the file is not being 
>> removed.
>> 
>> I could just have the RBE forgo building the 720k media. But, I feel it 
>> would be better to correct the problem.
>> 
>> I will get to it as soon as I can. But, probably not for several days.
>> 
>> Jerome
>> 
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

[Freedos-devel] Interim Build Delayed

[Jerome Shidel via Freedos-devel]

Hi All,

The FreeDOS Monthly Interim Build for September will be delayed.

The latest version of FDISK includes a large language translation file. That 
file is preventing the 720k Floppy version from building. Normally, I would 
just tell the RBE to exclude that file. There are a number of such exclusions 
already for files that are not required on the install media. However for some 
reason, the file is not being excluded when told and the build runs out of 
space and fails. 

Unfortunately, I am extremely busy with other things unrelated to FreeDOS at 
present. So, I do not know how long it will be until I find time to resolve 
this issue. It has been quite a while since I’ve done any work on the RBE. So, 
it may take a little while to figure out why the file is not being removed. 

I could just have the RBE forgo building the 720k media. But, I feel it would 
be better to correct the problem.

I will get to it as soon as I can. But, probably not for several days.

Jerome

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

Re: [Freedos-devel] Updating/moving the wiki

[Jerome Shidel via Freedos-devel]

> On Aug 26, 2023, at 4:40 PM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> On 26.08.2023 17:48, Jerome Shidel via Freedos-devel wrote:
>> Would require manually glueing an index together of the projects with Wikis 
>> under a main “landing page” which could be a project like issue-reporting. 
>> Then point wiki.Freedos.org to that page. 
> 
> I would not recommend that. First, the wiki would be scattered around the 
> different Gitlab projects (some are Github based!).

I do not disagree. Only want to point out it is an option. Not saying we would 
do it. Only that it should be considered and possible discarded as a solution.

If some standard was used during the creation of the individual project wikis, 
It would not be difficult to cross-link them to provide a (more or less) 
seamless site.

> Who would be responsible for keeping this all up-to-date? Second, it would 
> not integrate nice with the FreeDOS website.

I don’t understand the point you are trying to make about integrating with the 
FreeDOS website. 

Unless everything is running on the same CMS, issues (like dead links) will 
crop up. But for the most part, perma-links and standardizing page names would 
take care of most of that.

> Third, I do not think that it is a good idea to be too dependent on Gitlab. 
> Even if it is self-hostable, you have to pay for some advanced features.

You don’t pay for advanced features when self-hosted. 

But it is something that would require actively maintaining. Keeping up with 
updates and security patches. And it is possibly that required features could 
go away in future updates. Which of course could require migrating to a better 
solution.

But regardless of the solution that is chosen, any 3rd party project may change 
and force another migration. 

> I would rather go the other direction: Shifting more towards self-hosted 
> services. There is plenty of good OSS wiki software out there which can be 
> self hosted with reasonable effort.
> 
> I would also integrate at least a read-only git mirror of the important 
> software packages on the FreeDOS website. Probably Gitea based, because it is 
> a good compromise between functionality and maintainability. This would also 
> add an option for people not wanting to use Github and/or Gitlab to host 
> their DOS related projects at the FreeDOS site.

I haven’t looked at Gitea. I’ll have to check it out. 

> 
> If the project is in need of web space or something else, I think I could 
> help out. So let me know...
> 
> Bernd
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] Updating/moving the wiki

[Jerome Shidel via Freedos-devel]

> On Aug 26, 2023, at 12:38 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> Jim wrote:
>>> (This is a long email. Feel free to skip ahead to the "MY PROPOSAL"
>>> section at the end.)
>>> 
> [..]
>>> MY PROPOSAL:
>>> 
>>> I did some analysis, and the FreeDOS Wiki has 290 pages in it. That's
>>> more than a few, but it's not a ton.
>>> 
>>> My current thinking is to set up a new wiki.freedos.org website
>>> (re-point the "wiki.freedos.org" name to the new website) and do a
>>> manual copy/paste of all 290 pages. It would be a pain to do all that
>>> by hand, but I would like to use that opportunity to do some wiki
>>> cleanup at the same time.
>>> 
>>> When the new wiki.freedos.org is ready, I would change the "wiki"
>>> links on www.freedos.org to point to the new wiki.freedos.org website.
>>> I can add new wiki editors at that time, and probably set up a "self
>>> service" feature so folks can create their own wiki accounts (would
>>> need to look at how to prevent spamming).
> [..]
> 
> Jerome wrote:
>> Hi Jim,
>> 
>> Just a thought…
>> 
>> GitLab has Wiki support for the projects.
>> 
>> Would require manually glueing an index together of the projects with
>> Wikis under a main “landing page” which could be a project like
>> issue-reporting. Then point wiki.Freedos.org to that page.
> 
> 
> Sounds interesting, and probably less work - and that's always good.
> :-) But I'm concerned about walking into another situation down the
> road where we need to relocate the wiki once again. When we used the
> shared wiki at SF, that was a good idea at the time .. until they
> stopped offering it. Could the same happen with a GitLab-hosted wiki?
> 
> If the wiki is hosted on a website we control, I think we'll be less
> likely to run into these problems down the road. And we'll have better
> control over branding, for example.

That’s a valid concern. It also applies the projects themselves. 

But, that is one of reasons I used GitLab to setup the “FreeDOS Archive” for 
the projects over other version control systems like SourceForge or even GitHub.

The community edition of GitLab itself is open source. It can be downloaded and 
run on your own server and provides the same functionality as a top-tier paid 
GitLab account. You just need to pay for your own hosting/server somewhere.

Plus, exporting/migrating from GitLab to a private server should be fairly 
easy. They provided numerous utilities to do such things for projects. That 
should apply to a wiki and other related items attached to any specific 
projects.

I have run my own instance of GitLab in the past. But, I went back to just 
using GitLab for free. It’s hard to beat free.

 However, switching to self hosted instance of GitLab for the FreeDOS projects 
is always an option in the future. 

If it was on its own server, you could even install JITSI to host your own 
video conferencing solution. 

;-)

Jerome


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


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

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

[Jerome Shidel via Freedos-devel]

> On Aug 3, 2023, at 3:57 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 8/3/2023 11:54 AM, Jerome Shidel via Freedos-devel wrote:
>> 
>>> On Aug 3, 2023, at 12:37 PM, Bret Johnson via Freedos-devel 
>>>  wrote:
>>> 
>>> 
>>>> Yeah, USB and CD/DVD makes only sense for a 386+ ...
>>> USB, yes.  CD/DVD, no.  USB requires PCI which in turn requires 386+.  
>>> Actually, there were supposedly USB host controllers manufactured for the 
>>> ISA bus instead of PCI, but I've never actually seen one.  But USB 
>>> protocols assume you're using a 32-bit (and in some cases 64-bit) CPU so 
>>> USB really only makes sense on 386+, though you could probably make things 
>>> work on a lesser CPU if you absolutely had to.
>>> 
>>> But CD drivers existed back in the early days and they never required 
>>> anything special of the CPU.  They would sometimes take advantage of 
>>> special features if they were available, but it wasn't required.  AFAIK, 
>>> there are no DOS DVD drivers anyway since I don't think anything has ever 
>>> supported UDF.
>> I don’t recall any sub-386 ever shipping with a CD-ROM drive. But, there may 
>> have been a couple very high end machines.
> The main problem why I consider a CD/DVD drive is that on pre-386 computers, 
> you rarely have an IDE/ATAPI controller to connect a common CD-ROM drive. 
> Yeah, theoretically, you could use a SCSI one, but that's a completely 
> different kettle of fish...
> 
> The first time I used CD-ROM drives was at least on a 486 machine. You could 
> try to use and ATAPI controller on an AT class computer (80286, or lower), 
> but then you are getting down into a deep dark rabbit hole where you need to 
> know what you're doing anyway, so trying to adapt FreeDOS would be a manual 
> option.
> 
> Hence, from a general, default installation option POV, I stick with my 
> assessment that it makes only sense for a 386+ machine...
> 
> 
> Ralf
> 

Yep. Same here. 

For some reason, I’m thinking that first CD drive came with a controller card 
because it was a SCSI drive. 

However, I already had a SCSI scanner with a better card and just used that 
card. 

But that was 30 years ago, I could be miss-remembering it as SCSI. 

Ah, SCSI terminators…. :-)

Jerome


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

Re: [Freedos-devel] ANSI for DOS

[Jerome Shidel via Freedos-devel]

> On Aug 3, 2023, at 12:37 PM, Bret Johnson via Freedos-devel 
>  wrote:
> 
> 
>> 
>> Yeah, USB and CD/DVD makes only sense for a 386+ ...
> 
> USB, yes.  CD/DVD, no.  USB requires PCI which in turn requires 386+.  
> Actually, there were supposedly USB host controllers manufactured for the ISA 
> bus instead of PCI, but I've never actually seen one.  But USB protocols 
> assume you're using a 32-bit (and in some cases 64-bit) CPU so USB really 
> only makes sense on 386+, though you could probably make things work on a 
> lesser CPU if you absolutely had to.
> 
> But CD drivers existed back in the early days and they never required 
> anything special of the CPU.  They would sometimes take advantage of special 
> features if they were available, but it wasn't required.  AFAIK, there are no 
> DOS DVD drivers anyway since I don't think anything has ever supported UDF.

I don’t recall any sub-386 ever shipping with a CD-ROM drive. But, there may 
have been a couple very high end machines. 

I do recall waiting a while for the prices to drop to something 
semi-affordable. Which I added to my 486DX2/66 notebooks VLB docking station. 

So, there were definitely a bunch of 286/386 still in general use at the time. 
But they were still very expensive and not very popular.

If I recall correctly, it was a Creative Labs drive that came with a controller 
card and cost about $700 USD. I don’t recall if it was a writer or not. (Circa 
93/94). 

I may have held off waiting on a writer. Don’t recall. After all, we are 
talking about ancient history from back in the days when a CD had a much larger 
storage capacity than a typical PCs total hard drive storage. 

It wasn’t long after that CD drive prices dropped dramatically and most 
computers started including disc drives. Which of course made the Windows 95 CD 
media practical.

As for DVD support, on of the primary drivers we include is UDVD2. Which will 
probably work fine with with DVDs using iso-9660. 

As for Rockridge or UDF, IDK never tried. I burn very few discs nowadays. 
Mostly use USB HDDs and Flash. Probably only about 1/3 the way through a stack 
of blank DVD-Rs I bought a decade ago. 

None of this really matters. We do not have open source drivers available to 
FreeDOS that we will provide CD support on sub-386 machines.

:-)

Jerome

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


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

Re: [Freedos-devel] ANSI for DOS

[Jerome Shidel via Freedos-devel]

> On Aug 2, 2023, at 3:05 PM, Rugxulo via Freedos-devel 
>  wrote:
> 
> Hi,
> 
>> On Wed, Aug 2, 2023 at 2:29 AM Paul Edwards via Freedos-devel
>>  wrote:
>> 
>>> FreeDOS should run on 8086, both kernel and shell. If it doesn't,
>>> that's a bug or omission.
>> 
>> Are you sure? I thought I was told that the standard
>> distribution relied on an 80386.
> 
> Jerome's work on the distribution overall (and a lot of software
> packages) requires 386. But the basics should still run on 8086.

 My stuff for FreeDOS requires only an 8086. The exception being LOGGER which 
can run on an 8086. But, I have that functionality turned off at present. 

The CD and USB install media need a 386 do to the reliance on grep during 
installation. Which I feel is fine. Because USB is not present on 386 or less. 
Also, the CD drivers available to us require a 386+.

Eventually, I will add the functionality that is provided by grep into V8Power 
tools. However, because the drivers still need a 386+, those media will still 
need one to use them directly.

This is not the case for the Floppy Edition. It boots the 8086 kernel and only 
needs a 8086 to install. However, do to the compatibility issue in CPU 
detection which I have mentioned previously, installs the full package set 
(including 386 software).

There are other base components in FreeDOS, such as CuteMouse that do not 
support an 8086.


> 
>>> ke20xx_32.zip : binaries for 8086, FAT16, FAT32
>> 
>> I got this, and then renamed my kernel.sys to kernel.old,
>> 
>> Regardless, I then burned the image onto the CF and
>> booted on the Book 8088 and I got the same problem.
>> "loading freedos" followed by incessant beeping.
> 
> It's probably something else, but I don't know what.
> 
>>> The very bare minimum (besides boot sector) is kernel and shell. What
>>> other pieces of DOS software did you need or want?
>> 
>> Oh I see - thanks. I need fdisk and format and more
>> and doslfn and possibly xcopy, but it doesn't support
>> lfn, and zip and unzip.
> 
> DOSLFN is 386. (You could maybe reassemble StarLFN for 8086 and use
> LONGNAME.DAT files to store the LFNs, but it'd be slow.)
> 
> Zip and Unzip do have 16-bit versions, but I think FreeDOS normally
> ships the 32-bit versions.
> 
> Check here for 16-bit versions (if needed):
> 
> * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/info-zip/
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

Re: [Freedos-devel] tree 3.7.2/3.7.1

[Jerome Shidel via Freedos-devel]

Hi, 

When I did a quick test of the v.3.7.1, this is what I noticed and mentioned to 
Willi:

There are a couple problems with v3.7.1 that should be addressed before it 
should replace v3.7.0. 

Quickly looking at the binaries, you are correct that v3.7.2 is just v3.7.0. 
However, v3.7.1 is different. The large difference in size was just from v3.7.0 
being UPX compressed. When v3.7.0 is decompressed, it is only 186 bytes smaller 
than v3.7.1.

When I extracted the archive, the binaries were under C:\TREE373\BIN 
under/inside DOSBox, using the DOSBox Kernel and FreeCOM shell (my normal DOS 
development and primary DOS testing platform).

v3.7.1 does not display a tree for any directory other than the current one. 
(tree371 \ - printed no subdirectories exist)
v3.7.1 does not display the files (/F) for any directory if a different 
directory is requested. 

Basically it looks like when any directory is requested, it is ignored along 
with any option switches that may have been provided.

On a side note, there is another bug that exists in both v3.7.0 and v3.7.1 
which I noticed under the DOSBox kernel. It would probably go unnoticed in a 
normal Virtual Machine or on real hardware. Both versions reported a serial 
number of :1234. There is no serial number present for drives under DOSBox. 
Fortunately, the DOSBox kernel does report this and for example FreeCOM’s dir 
command does not print an erroneous serial number for disk volumes. The bug is 
most likely a result of not testing if the call was completed successful. See 
https://fd.lod.bz/rbil/interrup/dos_kernel/2169.html#3212 
<https://fd.lod.bz/rbil/interrup/dos_kernel/2169.html#3212> 
 
:-)

Jerome


> On Aug 2, 2023, at 12:09 PM, perditionc--- via Freedos-devel 
>  wrote:
> 
> I will look into it.
> 
> Jeremy
> 
> On Wed, Aug 2, 2023, 12:07 PM Wilhelm Spiegl via Freedos-devel 
>  <mailto:freedos-devel@lists.sourceforge.net>> wrote:
> Hi all,
>  
> I just worked on checking tree 3.7.2 - it is a little bit tricky. The source 
> code of 3.7.2 seems to be identical with 3.7.1, but the .exe is identical
> with 3.7.0.
> I found information about 3.7.1 at archive.org <http://archive.org/>, see:
> https://web.archive.org/web/20011212151852/http://www.darklogic.org/fdos/projects/tree/
>  
> <https://web.archive.org/web/20011212151852/http://www.darklogic.org/fdos/projects/tree/>This
>  text that says that the options /s, /d and (according to nls: /v, version, 
> works) are added at 3.7.1. They work with 3.7.1, from root,
> but they do not work correct at subdirectories, and, as Jerome Shidel 
> reported, there are problems with HD serial number in dosbox.
>  
> Is there anybody out there who can check / fix this as I am no programmer.
>  
> Thanks
>  
> Willi
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net 
> <mailto:Freedos-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-devel 
> <https://lists.sourceforge.net/lists/listinfo/freedos-devel>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

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

[Freedos-devel] FreeDOS Interim Build T2308

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2308 for August is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Summary of changes since T2307:

2023-07-25 16:57:18 fdisk [unstable] (Bernd Boeckmann): update INDEX.md
2023-07-25 16:55:06 fdisk [unstable] (Bernd Boeckmann): add translation file 
FDISK.LNG
2023-07-25 16:34:02 fdisk [unstable] (Bernd Boeckmann): import v1.3.8 from 
upstream
2023-07-24 18:15:12 blocek (shidel): updated to v1.74b
2023-07-17 19:07:56 project_FD-NLS (shidel): Merge pull request #171 from 
cardpuncher/master
2023-07-17 18:20:49 project_FD-NLS (cardpuncher): Add files via upload
2023-07-17 06:25:10 fdimples (shidel): updated to v0.11.6
2023-07-16 13:06:28 blocek (shidel): updated to v1.74
2023-07-16 12:33:11 fasm (shidel): updated to v1.73.31
2023-07-16 05:24:27 project_FD-NLS (shidel): Update EN/SETLANG from Bernd 
Böckmann
2023-07-01 14:11:02 v8power (shidel): update
2023-07-01 07:06:47 project_FDI-x86 [unstable] (shidel): Merge pull request #5 
from shidel/master
2023-07-01 07:05:28 project_FDI [unstable] (shidel): Merge pull request #18 
from shidel/master


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

[Freedos-devel] FreeDOS Interim Build T2307

[Jerome Shidel via Freedos-devel]

Hi All, 

The FreeDOS Interim Test Build T2307 for July is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


:-)

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

Re: [Freedos-devel] Free FDISK interim builds

[Jerome Shidel]

Hi Bernd,

Since you are working on fixing and improving FDISK, there are two features 
that would be great to add for end users.

During the installation of FreeDOS, when no partitions are present, the 
installer will try to use FDISK to automatically partition the drive.

Unfortunately, the current FDISK performs this task be creating a bunch of 2GB 
partitions. This tends to annoy users installing on real hardware with very 
large disks.

I propose two additional options that could be added to modify what occurs when 
partitions are automatically created.

First, the ability to only create a single partition automatically. Leaving the 
the remainder of the disk unallocated. 

Second, an option to tell it to use FAT32 and create the partitions as large as 
possible.

The options could be used together or separately along with the auto-partition 
option.

I think the first option would be enough for most users most of the time. A 2gb 
DOS partition is huge. However if need be, the user could create an additional 
single large partition at a later time.

However when installing to a virtual machine, the installer could then just 
partition the entire virtual disk as a single partition.

:-)

Jerome

> On Feb 26, 2023, at 2:06 PM, Bernd Boeckmann via Freedos-devel 
>  wrote:
> 
> Hello,
> 
> in the last two weeks I ported Free FDISK to Watcom C and started fixing the 
> bugs people mentioned at the bttr forum and in the issue trackers.
> 
> For people wanting to track the progress, I am doing the development at the 
> following repository: https://github.com/boeckmann/fdisk.
> 
> I will make merge requests to upstream https://github.com/fdos/fdisk in 
> regular intervals and uploaded an interim build (compiled with Open Watcom) 
> at https://nextcloud.iww.rwth-aachen.de/index.php/s/egSe4Jyj9zx72ag
> 
> I touched the source at many places, so I can not rule out that I have 
> introduced new bugs but plan to continue working on it. For the moment, 
> please consider it beta and dangerous.
> 
> If you want something to be changed please send me an e-mail. I will try to 
> implement it if time permits it.
> 
> User visible changes so far:
> 
> Version 1.3.5 (unreleased)
> --
> - CRITICAL: Fix FDISK loading wrong head and sector values from MBR if
>operating in LBA mode. The previous incorrect behaviuor was hardcoding
>them to cylinder boundaries instead of calculating them from LBA address,
>resulting in corrupt partition tables especially if used in combination
>with other disk utilities.
> - CRITICAL: Fix different calculation errors leading to overlapping
>partitions, unnessessary free space between them, or partitions exceeding
>the end of the disk.
> - CRITICAL: Fix a bug resulting in detecting non-existant extra cylinders
>if detection of extra cylinders is enabled.
> - ENHANCEMENT: Warn if user tries to use FDISK with a disk size of >2TB,
>because it can not handle it properly. If the user decides to continue
>the disk size is truncated to 2TB, making sure nothing bad happens by
>some overflowing values.
> - ENHANCEMENT: Free FDISK now compiles with Open Watcom C.
> 
> Greetings, Bernd
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


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

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

[Jerome Shidel]

> On Jan 31, 2023, at 8:55 AM, tom ehlert  wrote:
> 
> 
>> The main difference between using VBADOS and EtherDFS would come
>> down to the DOS machine. If running DOS inside VirtualBox, VBADOS
>> would most likely be the easiest to setup and use. However, using
>> EtherDFS works under other Virtual Machines and with real hardware. 
> 
> EtherDFS should work for any (at least most) Virtual machines which s
> good.
> 
> However it requires a linux machine to connect to which is bad.
> 
> VBADOS should work with any VirtualBox on whatever OS which is good.
> 
> Tom

Yep.

It would be great if EtherDFS had some easy to run server-side software for 
other major OS/platforms like Mac, Linux, Android, etc. 

That and lack of LFN support  are the two main issues with using EtherDFS. 

And like you say… if you’re just using VirtualBox, VBADOS is a lot easier.

:-)


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


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

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

[Jerome Shidel]

Hi Bret,

Yep! You said it all much better and in far greater detail than I went into. 

Thanks. :-)


Jerome


> On Jan 23, 2023, at 1:54 PM, Bret Johnson  wrote:
> 
> 
>> 
>> by the way, the 2 programs are the setup stuff and edlin. hardly
>> rocket science.
> 
> Even those two "simple" programs would probably be considered "rocket 
> science", or at least akin to "learning a foreign language", by most students 
> who are only used to modern technology and web apps.  Low-level stuff like 
> I/O and IRQ and BIOS emulation isn't flamboyant enough for most younger 
> people to get involved with these days.
> 
> 
> 
>> Perhaps it could be used to solve one of the most frequent problems
>> I hear. Running FreeDOS on modern UEFI hardware.
> 
> I think that is the main point of it all.
> 
>> As we are all well aware, this cannot be directly accomplished and
>> would require an abstraction layer between the OS and the actual
>> hardware.
> 
> It actually can, at least in certain situations.  The fundamental problem, at 
> least as I see it, is I/O.  I know a lot of the talk seems to be around sound 
> cards, but let's discuss it in terms of something a little simpler: joysticks.
> 
> A regular, old-fashioned joystick uses an I/O port, specifically port 201h.  
> There is also a BIOS function that lets you access the joystick, INT 15.84.  
> Over the years as computers got faster and joysticks got more complicated 
> (more buttons and axes), the INT 15.84 BIOS interface effectively became 
> useless.  Modern programs that want to use a joystick almost never use INT 
> 15.84 and instead try to talk to I/O port 201h directly.  That has caused all 
> kinds of problems.
> 
> Sound cards have a similar, yet slightly different, problem.  There was NEVER 
> a widely support BIOS-level interface for sound cards.  The de facto 
> "standards" that everyone seemed to base their sound card designs on were Ad 
> Lib and Sound Blaster which were fundamentally hardware (I/O) based and 
> proprietary (they also used things like DMA's and IRQ's).
> 
> Now, we're in a world where USB is pretty much the standard port for 
> everything plugged into the computer (certainly for joysticks and to a large 
> extent for sound devices).  From a hardware perspective, the USB host 
> controllers are the only things that actually talk to the "real" I/O ports 
> (sometimes PIO but usually MMIO).  DOS programs still expect to see the 
> joysticks on I/O port 201h and the sound cards at various I/O ports, but 
> those ports don't exist on the real hardware any more and must somehow be 
> virtualized.
> 
> The problem is even worse when you're using something like DPMI.  DPMI does 
> allow thunking down to the lower level (the DOS/16-bit "layer") for 
> interrupts but doesn't provide a standard way to thunk for I/O ports.  Since 
> a way to thunk I/O isn't provided, every single DPMI-based program needs to 
> understand things like USB and all the different kinds of devices that can be 
> USB-attached.  Of course, none of them understand USB and none of them thunk 
> the I/O, either.
> 
> It is possible to virtualize I/O in DOS with MS EMM386 and with Quailitas' 
> 386MAX.  JEMM also has a proprietary way to virtualize I/O with JLOAD, and I 
> am currently trying to add the MS/Qualitas-style capability to JEMM.  But 
> those methods will only work with programs that don't use DPMI or that thunk 
> the I/O from DPMI.  IOW, many old programs would need to be rewritten change 
> the way they do things to work properly on modern hardware without a VM.  
> That ain't gonna happen.
> 
> What a Virtual Machine does is provide another level of abstraction between 
> the real hardware (e.g., the I/O ports associated with the USB hardware) and 
> the virtualized hardware (e.g., I/O port 201h that a DPMI program is 
> expecting to see a joystick attached to).  With this extra layer of 
> abstraction, the DPMI program doesn't need to do the "thunking" -- it is 
> handled "automatically" by the abstraction layer that sits between the real 
> hardware (real I/O ports) and the virtualized hardware (virtualized I/O 
> ports).
> 
> That hardware abstraction layer is one of the main things that Virtual 
> Machines provide.  Of course, different VMs virtualize different hardware 
> devices.  I think they all do mice and keyboards and disks, a lot of them do 
> Ethernet cards and printers, but only some of them will do things like PC 
> Speakers and joysticks and sound devices.
> 
> One of the main things that Windows has done is to move the BIOS _function_ 
> (an abstraction layer between the hardware and the software) up into the OS 
> itself.  In fact, Microsoft at least used to call it the "Hardware 
> Abstraction Layer" or HAL, but I don't know if they still call it that or 
> not.  *nix does something similar -- they have hardware-specific drivers 
> (that talk to devices at the I/O level) and then have a "layer" that a 
> program "talks to" when it 

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

[Jerome Shidel]

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

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

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

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

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

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

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

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

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

:-)

Jerome

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

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

[Jerome Shidel]

Hi,

> On Jan 10, 2023, at 4:14 AM, Knedlik  wrote:
> 
> Hello all again,
> thanks for all the responses. Definitely useful stuff. I’d just like to 
> respond to the concerns regarding the VM - I’m afraid I don’t have any 
> silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 
> 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy 
> BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even 
> if I had bootcamp, that option wouldn’t be possible.
> -Knedlik
> 

Don’t worry about the VM issues too much. I just wanted to point out they 
exist. Depending on what you may write, you could make something that is done 
100% perfect that doesn’t work in a VM. 

I generally use on older Intel based Mac. I have several workflows for creating 
stuff for DOS. When making stuff in assembly, I do my writing in BBEdit. Then 
compile in a terminal on the Mac. Then switch over to one of a couple VMs or 
Real Hardware and test. The testing part can vary based on the know limitations 
for the VMs. 

Generally, that testing happens under DOSBox. Here I run FreeCOM on top of the 
DOSBox kernel. It is a sort-of hybrid install that the FreeDOS installer can 
perform. This permits the DOS VM easy access to the host file system. However, 
there are some issues. Most have to do with the disk and file system. For 
example, updating a files time stamp in DOS gets completely ignored.  There are 
other issues as well. But, I usually find this the easiest workflow.

Sometimes the DOS part of my workflow includes a VirtualBox instance. In the 
early days, getting files to and from the VM was more work. I would copy them 
onto a diskette image file (which is easy on a Mac). Dismount the image file. 
Then mount the image in VirtualBox. Test and Dismount it in the VM. And repeat. 
Needing to make sure I did not mount the image in both places at the same time 
or the image file would be trashed.

Nowadays. I have a Linux server with a Samba share mounted by the Mac. The 
server also shares the directory over EtherDFS to the VirtualBox DOS instance 
running an EtherDFS client. It works well except EtherDFS does not support long 
file names. Which is fine because you should avoid those in DOS development. 

As for VirtualBox itself, first there is no PC Speaker support. The VGA 
limitations mostly crop up with more advanced things like using features that 
require talking to the card. The basic BIOS calls work fine. 

Then there is real hardware. It’s the ultimate test and nothing is better. I 
use both real floppies and EtherDFS to get files onto that machine. 

While the different limitations of the various VMs do exist, they are issues to 
just avoid. You just need to be aware and able to spot them when/if they crop 
up. Then figure out how to avoid the problem when possible in your code. 

After all, a large number of users will not have real hardware either. Like 
you, they will be limited to running the program in a VM. It wouldn’t make much 
sense to create something that neither the users or yourself can actually run. 
Even if it would work fine on real hardware. :-)

When it comes down to avoiding the VM issues, sometimes you can and sometimes 
you can not. 

For example, let’s say you want to make a better file copy program. One that 
copies file time stamps and verifies everything. You test it on real hardware 
and it works great. Try it under VirtualBox and it is incredibly cool. You jump 
into your DOSBox hybrid install and… Error: Copied file failed verification. 
What? Why? It worked fine on my test machine under VirtualBox! So after some 
debugging and head banging and more debugging, you realize the program was fine 
and DOSBox just ignores the timestamps. 

Not much you can do about that. Maybe you test to see if you’re running under 
DOSBox and warn the user that this occur. Maybe some other or even no solution. 
It’s up to you. :-)



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


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

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

[Jerome Shidel]

Hi,

> On Jan 9, 2023, at 2:46 PM, Knedlik  wrote:
> 
> That’s actually a good question.
> I would say the second option, as I’m in for the trip to DOS world for 
> learning how it worked in „the old days“. I do have FreeDOS running on a VM 
> on my Mac, so that I can access it at pretty much any time when I have *a* 
> computer with me. I will definitely explore the link you sent.
> -Knedlik

Just a minor warning for when you start working on DOS stuff through a VM.

Different Virtual Machine platforms have different limitations when it comes to 
supporting DOS hardware. For example, Virtual box does not support the PC 
Speaker or some common VGA functions. Generally, the lack of good VGA support 
does not affect most programs. While others may not work at all.

DOSBox tends to do alright. But, there are limitations while using it as well. 




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

Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?

[Jerome Shidel]

> On Dec 6, 2022, at 5:46 PM, Harald Arnesen  wrote:
> 
> Jerome Shidel [06/12/2022 23.38]:
> 
>>>> But I completely agree it would be nice to include some sort of text 
>>>> editor. Like MEM and MORE, it can be difficult to get along without having 
>>>> them on a boot diskette. But, at 65.9kb for EDIT.EXE + 29.4kb for 
>>>> EDIT.HLP, there is not enough room on the 720kb diskette set to include 
>>>> edit. Perhaps the 16-bit version of E3 at only 4kb could be included. Or 
>>>> possible, a different very light-weight editor.
> 
> If we want to be compatible with MS-DOS, EDLIN is the only alternative. As is 
> ed the only standard Unix editor.

By comparison, EDLIN is rather big at 30kb. It would only leave about 30kb free 
on the 720kb disk. That is 26kb less space than using E3. Also, E3 is a screen 
editor not a line editor. But that being said, EDLIN is part of FreeDOS BASE 
and E3 is not. Also, a user looking for and editor on the diskette would 
probably know what EDLIN does by it’s name. On the other hand, they may not 
even notice E3 or realize what it does. 

So, EDLIN may be a better choice. IDK. 

Jerome

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

Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?

[Jerome Shidel]

Hi Ralph,

> On Dec 6, 2022, at 2:43 PM, Ralf Quint  wrote:
> 
> On 12/6/2022 1:39 AM, Jerome Shidel wrote:
>> But I completely agree it would be nice to include some sort of text editor. 
>> Like MEM and MORE, it can be difficult to get along without having them on a 
>> boot diskette. But, at 65.9kb for EDIT.EXE + 29.4kb for EDIT.HLP, there is 
>> not enough room on the 720kb diskette set to include edit. Perhaps the 
>> 16-bit version of E3 at only 4kb could be included. Or possible, a different 
>> very light-weight editor.
> 
> So how much space DO you have?

As I said in the previous message, there is 63kb free on the 720kb.

> I don't think that EDIT (specially including the help) is necessary, but 
> there are (should be) full screen editors that would be suffice for editing 
> basic configuration files when setting up a system. There is no need for 
> graphic UI, multi file, multi-MB-sized files and such fluff. But quickly AND 
> EASILY edit those rather small (less than a dozen KB) text files. And that 
> should be possible to accomplish with an editor of 20KB or less...
> 
> 
> Ralf

I’m really thinking about sticking the 16-bit version of E3 ( 
https://gitlab.com/FreeDOS/editor/e3 <https://gitlab.com/FreeDOS/editor/e3> ) 
on the Floppy Edition boot media. Unless there “better” similarly sized editor. 
E3 is only 4kb, GPLv2 and we already have a package for it. When it starts up, 
it displays all the keyboard commands.  

After having a quick look at the Editor packages we already have at 
https://gitlab.com/FreeDOS/editor <https://gitlab.com/FreeDOS/editor> , all 
except E3 are larger than FreeDOS Edit. So, unless there is overwhelming 
support for a different one and we make up a package for it, I’ll probably just 
stick E3 on there.

Jerome


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

Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?

[Jerome Shidel]

Hi, 

> On Dec 2, 2022, at 4:38 PM, Bernd Boeckmann via Freedos-devel 
>  wrote:
> 
> Hi all,
> 
> last time I installed FreeDOS from floppy disk set I was in need for an 
> editor to edit some system filed but did not find one on the boot disk. Is 
> that an oversight of mine or is this by intention? I found that very 
> inconvenient. Perhaps there is a way to include at least minimal editing 
> capabilities for updating  system config files etc.
> 
> Greetings,
> Bernd

Edit was only included on the boot diskette of earlier versions of the Floppy 
Edition during the initial development of that version of the release. It was 
there for me to make minor changes and bug fixes to the diskette and installer 
without the need to rebuild the release. 

All three diskette (720kb, 1.2mb & 1.44mb formats) sets contain the same set of 
files on the boot diskette. With very few exceptions (Like MEM and MORE), only 
the absolute minimum number of programs needed to boot and install the OS are 
provided on the diskette. As such, there is only about 63kb of free space on 
the 720kb diskette image. 

If a user is installing from a 720kb diskette, they are probably using a very 
old system. In such a case, they may need to include a special driver to 
perform the install. Excluding everything that is not absolutely required 
prevents any confusion on what can be removed from the diskette without causing 
installation problems. For the most part, I feel that is better to leave that 
space free and let the user decide what utilities or drivers they need or want 
to add. 

This is also the reason that no archive files are included on the boot 
diskette. It is possible that the some the sets (720, 1.2, 1.44) could be 
reduced by a diskette if some of the archive files were included on that 
diskette image. 

But I completely agree it would be nice to include some sort of text editor. 
Like MEM and MORE, it can be difficult to get along without having them on a 
boot diskette. But, at 65.9kb for EDIT.EXE + 29.4kb for EDIT.HLP, there is not 
enough room on the 720kb diskette set to include edit. Perhaps the 16-bit 
version of E3 at only 4kb could be included. Or possible, a different very 
light-weight editor. 

On a side note… Looking at the latest Interim build, I see that 2 new files 
have crept onto the diskette. Those are FASTHELP.BAT and SETVER.SYS. They are 
using about 1kb of diskette space and should be excluded. 

Jerome

 





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

Re: [Freedos-devel] clamav - remove or not remove?

[Jerome Shidel]

> On Dec 5, 2022, at 12:18 PM, Fritz Mueller  wrote:
> 
> Hi,
> as the actual FDT2212 once again has the older virus definition database 
> (version 51, latest usable version for FD is version 54 without daily.csv) 
> and only clamscan files on board I wonder if it makes sense to keep this "as 
> is" , to update it or to remove it completely.

I updated the CLAMDB package on last month from the link you sent me. 
However, somehow, I managed not to update the MAIN.CVD file.

So, I just updated the package again from the files you sent and the newer 
database will be on the next Interim Build. 

If you want to look at DB package before the next Interim build to verify 
things look correct, you can fetch a version of the FreeDOS package from 
https://gitlab.com/FreeDOS/util/clamdb/-/releases 
<https://gitlab.com/FreeDOS/util/clamdb/-/releases>

Please note, the package generated by the CI/CD pipeline is not identical to 
the package that will be on a Release or Interim Build at present. There are 
some slight differences in the metadata and with some other minor aspects. 
Eventually when the CI/CD pipeline is finished and implemented across all 
packages, I will probably update the RBE to just use the versions created by 
the CI/CD. Not having the RBE need to clone, verify and build each package 
itself will decrease release build time a lot. 

> I have reported about this theme already two times, but for not reproducable 
> reasons there is no change till now.
>  
> At: 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/clamav/ 
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/clamav/>
>  there are three different files:
> a) clamav (command line virus scanner) ca. 3 MB
> b) clamdbx (database) ca. 23 MB
> c) fdav ca. 700 kB
> I created a newer version:
> d) clamdbx 54 (database) ca. 30 MB
> To make the virus checker work FD needs ca. 128 MB RAM.
>  
> As FDT2212 Bonus CD contains a) and b) with a size of 26 MB, it would not use 
> much more space to add fdav 0.2.2 in the same folder, a GUI for virus 
> checking.
> This tool was created by Blair Dude, his website is 
> https://sites.google.com/site/blairdude/home, there was no more activity 
> since in about 2010.
> I created an update of the ver 54 database for Jerome Shidel / FD. He told me 
> that it has to be discussed by the FD developer group if he can
> add it or not. OK. No problem, but as long as clamav with database is on the 
> Bonus CD it makes no sense in my eyes to leave 700 kB GUI away whereas the
> older database and the command line file is inside. You can discuss about the 
> question if it makes sense to update the database for "this old OS". No 
> problem too. But could you at least add a copy of v54 database at ibiblio so 
> that users can decide themselve which version they want to use?
> Thanks.

Just to clarify a little. 

FDAV has not been included with FreeDOS for a very long time. At present, there 
is not even a package for it in the GItLab Archive or on the Update 
Repositories for 1.1, 1.2 or 1.3. Whether or not FDAV is included, replaces 
CLAMAV or both are excluded from future releases, the topic should to be 
discussed with the group.

> Fritz / Willi

Jerome



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

[Freedos-devel] FreeDOS Interim Build T2212

[Jerome Shidel]

Hi all, 

FreeDOS Interim Build T2212 is now available at 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Mostly, this update consists of improvements to KEYB and 5 other package 
updates and me tinkering with the GitLab CI/CD to deploy ZIP archive packages 
that are directly compatible with installation by FreeDOS package managers like 
FDNPKG. 

Changes since T2211:

2022-11-28 00:11:43 label (shidel): add CI/CD pipeline
2022-11-25 13:14:55 sqlite (shidel): included basic CI/CD pipleline
2022-11-22 11:35:23 v8power (Shidel): Unstable devel merge to master
2022-11-22 11:35:23 v8power (Shidel): Merge branch 'unstable' into 'master'
2022-11-22 08:06:59 v8power (shidel): CI/CD pipeline update
2022-11-22 07:56:31 v8power (shidel): update v22.11.22
2022-11-21 11:35:56 fdbanner (shidel): added CI/CD to validate project and 
generate FreeDOS package
2022-11-21 06:39:59 links (shidel): added CI/CD to validate project and 
generate FreeDOS package
2022-11-21 06:27:32 gopherus (shidel): added CI/CD to validate project and 
generate FreeDOS package
2022-11-21 06:19:36 fdhelper (shidel): added CI/CD to validate project and 
generate FreeDOS package
2022-11-21 06:13:41 upx (shidel): added CI/CD to validate project and generate 
FreeDOS package
2022-11-20 23:56:39 keyb (Aitor Santamaría Merino): Update KEYB.LSM
2022-11-20 12:47:28 keyb (shidel): added LFN and Timestamp support to release 
pipeline
2022-11-19 13:46:53 keyb (shidel): improved CI/CD messages and pre-compressed 
package SOURCES
2022-11-18 22:45:55 keyb (shidel): added prototype CI/CD verification with 
automatic release tagging and FreeDOS package creation
2022-11-16 22:20:29 keyb (Aitor Santamaría Merino): Message catalog translation 
for German.
2022-11-16 13:48:07 project_FD-NLS (shidel): report update
2022-11-16 13:45:06 clamdb (shidel): updated to latest virus definitions v54 
(2011-10-10)
2022-11-16 13:25:24 wde (shidel): updated v1.0
2022-11-16 13:24:38 project_FD-NLS (shidel): updated BLOCEK NLS from v1.71 
sources
2022-11-16 13:07:28 blocek (shidel): updated v1.71
2022-11-16 12:55:01 project_FD-NLS (shidel): report update
2022-11-16 12:42:46 gopherus (shidel): updated v1.2.2
2022-11-16 12:33:18 project_FD-NLS (shidel): KEYB: DE from W.Spiegl
2022-11-16 12:08:41 project_FD-NLS (shidel): KEYB: English NLS correction from 
Aitor
2022-11-14 22:52:42 keyb (Aitor Santamaría Merino): Turkish message file
2022-11-14 22:51:51 keyb (Aitor Santamaría Merino): French messages file
2022-11-14 22:19:45 keyb (Aitor Santamaría Merino): Update KEYBMSG.NLS
2022-11-11 11:17:09 project_FD-NLS (cardpuncher): Add files via upload
2022-11-11 06:03:16 project_FD-NLS (shidel): report update
2022-11-11 05:32:35 project_FD-NLS (shidel): Merge pull request #147 from 
cardpuncher/master
2022-11-09 18:31:47 keyb (Aitor Santamaría): Move the NLS file to the right 
folder
2022-11-09 18:16:59 keyb (Aitor Santamaría): Last copmiled version
2022-11-09 18:10:48 keyb (Aitor Santamaría): Change version name, update 
documentation, add ES translations
2022-11-09 14:27:32 project_FD-NLS (shidel): report update
2022-11-09 14:10:58 project_FD-NLS (shidel): added KEYB ES translation
2022-11-09 14:04:09 keyb (shidel): moved ES translation file to sources 
directory
2022-11-09 13:59:48 keyb (shidel): timestamp and index file update
2022-11-09 11:30:27 project_FD-NLS (shidel): added english NLS for keyb
2022-11-09 10:30:02 project_FD-NLS (shidel): FreeCOM: removed mention of 
unsupported DIR /V switch from docs
2022-11-09 09:46:37 project_FD-NLS (shidel): Merge pull request #146 from 
andrewbird/dir
2022-11-08 21:23:09 keyb (Aitor Santamaría): Minor changes to syntax
2022-11-07 10:23:31 project_FD-NLS (Andrew Bird): FreeCOM: DIR command has no 
/V switch
2022-11-06 00:50:14 keyb (Aitor Santamaría): Minor changes to improve 
compatibility and syntax errors

On a side note…

For the longest time, the RBE (Release Build Environment) throws an error when 
validating one of the packages. This is the only “true” error remaining during 
the build of a release. The error is spread across the these two lines in the 
error log. 

2022-12-01 01:59:47-05:00 package 'opengem', error extracting 
'/SOURCE/OPENGEM/SOURCES.ZIP/PROGRAMMING TOOLKITS AND UTILITIES AND BUILD 
TOOLS/atari gem programming library hexaid manual for games.zip'
2022-12-01 01:59:47-05:00 dfab68a6 crc, package error.

It would be really nice to get this issue resolved. I don’t know if the package 
is corrupt, using an incompatible compression or some other issue. I just know 
it does not extract without having an error. It would be great if someone would 
look into the problem and possible submit a merge request to fix it in the 
GitLab archive at https://gitlab.com/FreeDOS/gui/opengem 
 . Also, I think OpenGem has some 
configuration issues resulting in low display quality. 

Once 

[Freedos-devel] FreeDOS Archive CI/CD

[Jerome Shidel]

Hi All,

First, I want to apologize to everyone using the FreeDOS Archive on GitLab ( 
https://gitlab.com/FreeDOS  ) that may have 
received a bunch of messages regarding failed and successful CI/CD pipelines 
over the last few days. This was the result of some work I was doing, your 
permission level for those projects and of course your notification settings. 

A few days back, there was a small issue with one of the projects. Whenever 
that project was updated and a new release was created, the developer wanted to 
have a FreeDOS compatible and directly installable package. Unfortunately, 
there was some problems with doing that. 

When GitLab creates a release, it takes everything in the project and zips it 
up. That part of the process is fine. Projects there are kept in a fully ready 
to “Zip and Ship” directory structure with all necessary files included. But, 
it would also include the project informational files stored in the root 
directory which would collide with other projects. But the major problem was, 
when performing this function, it would put everything in the zip archive under 
a “(project)-(comit-hash)” directory.  Both problems making the zip archive 
completely incompatible with all package managers under FreeDOS. 

But, I knew this should be a solvable problem. I have seen many projects on 
GitLab/GitHub that included additional files with their releases. Often, those 
files are releases for other platforms, binaries only and other such related 
items. So, I started digging into the CI/CD (continuous integration and 
deployment) support for GitLab. 

I’ve never used the CI/CD tools for Git before. Ugh, you think it would be 
simple. But, no. However, after spending a few days reading numerous pages of 
inaccurate, incomplete and obsolete information, I got a prototype CI/CD 
pipeline up and running. 

The CI/CD pipeline is not perfect. But, it does some cool stuff. There are a 
couple things left to do on it. But, I have not figured those out yet. 
Possibly, there may be someone on the mailing list who is an expert with Git 
CI/CD runners and pipelines who can advise or help with the remaining stuff. 

At present, the CI/CD pipeline does a bunch of stuff whenever a commit is 
pushed or merged into the main/master branch. This is not an all inclusive 
list. Just some of the major features already present.

Validates directory structure and standard package format. 
Validates included required LSM metadata and prevent extra package LSM files.
Validates files do not exist in places that will cause installation collisions.
Checks that sources are present.
Prevents erroneous files in system directory locations like HELP and NLS.
Determines if a new release is warranted by checking the version in the 
projects LSM file.

When a new release is desired, the CI/CD will also do these.

Adjust timestamps to the correct date/time (assuming commit tools, like 
fdvcs.sh, are used to keep the timestamp database up to date).
If a LSM-Support field is not present in the LSM file, it will scan the project 
and determine if LFN files are present. 
Depending on the location of those files (excluding SOURCES), LFN support will 
be determined as not needed, optional or required. 
No LFNs - not needed
LFNs found in standard system directories (like BIN, HELP, etc). - required
LFNs found in other program directories - optional
If the LFN scan was positive, an LFN-Support field will be added to the 
released package LSM metadata. The created field will either be “required” or 
“compressed”
If an LFN-Support field is “compressed”, it will compress LFNs under the 
directories into one or more LFNFILES.ZIP archives. To prevent this, a project 
can just preset the LFN-Support field in the LSM file as “required”.
It will pre-compress the project SOURCES to save a few bytes, increase instal 
speed (when sources are installed) and for a couple other reasons discussed on 
this list earlier. (this optional and can be disabled).
Update the LSM field “Modified-date” to “${today}.0” 
Add the LSM field “Packager” with the pipeline script and it’s version.
Add the LSM field “Git-Site” with a URL to the project on GitLab.
Add the LSM field “Git-Commit” with the short hash that triggered the creation 
of the release.
Possibly add the LSM field “LFN-Support” when not present and the LFN scan 
finds them.
Possibly add the LSM field “Timestamps” when the timestamp update detects that 
the database is has not up-to-date and one or more files were not stamped.
Compress the whole thing up into a FreeDOS package manager compatible zip 
archive.

Once that is all done successfully, the CI/CD pipeline finishes up the process 
by:

Generating a new repository tag based on the LSM version. 
Creates a Release for that Tag.
Includes a link in the Release to download the FreeDOS package.

In addition to all of that, the pipeline supports the ability to compile the 
project. This was something I added and was 

Re: [Freedos-devel] Toggling directories

[Jerome Shidel]

Hi Ralph, 

> On Nov 15, 2022, at 1:26 PM, Ralf Quint  wrote:
> 
> On 11/9/2022 7:26 AM, Jerome Shidel wrote:
>> Hi all,
>> 
>> There is a minor compatibility difference with the FreeCOM DIR command.
>> 
>> Most of the option switches work like toggles. For example:
>> 
>> dir /w   - shows a wide listing
>> dir /w /w- shows a normal listing
>> dir /w /w /w - shows a wide listing
>> 
>> This deviates from MS-DOS
>> 
>> dir /w   - shows a wide listing
>> dir /w /w- shows a wide listing
>> 
>> To toggle it back off MS-DOS requires the /-w switch and works fine with the 
>> FreeCOM DIR.
>> 
>> When used through an alias like “set alias ls=dir /w” then executing “ls /w” 
>> it produce results different from what is expected.
>> 
>> Not all options perform toggling. For example:
>> 
>> dir /p   - pauses per page
>> dir /p /p- pauses per page
>> 
>> I don’t think the toggling is very important. But, it does deviant from 
>> MS-DOS.  
>> I do think that consistency across the options is important.
>> 
>> Any thoughts?
> My thought? You got to be kidding! ;-) 
> Sorry, just can't see how one could possibly abuse that bug in MS-DOS, and 
> that is certainly nothing that I would suggest we strive to emulate, 
> consistency or not...
> 
> 
> Ralf
> 
Sorry. But, I’m confused by your response.

In MS-DOS, DIR does not toggle at all when using simple switches without a +/-. 
In FreeDOS, most DIR options toggle without using a +/-. 

Both support turning off/on options when a +/- is used. However, I have not 
tested all options under both. So, it is possible some may only turn on an 
option under one or the other OS. 

Are you saying… You don’t care and we should not worry about it? Or, something 
else?

Although MS-DOS does not do the toggling, it could cause user confusion. So, 
I’m not sure if FreeDOS should. However, I think DIR should at least be 
consistent and either all or none of it’s options should support toggling.

:-)

Jerome


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

[Freedos-devel] Toggling directories

[Jerome Shidel]

Hi all,

There is a minor compatibility difference with the FreeCOM DIR command.

Most of the option switches work like toggles. For example:

dir /w  - shows a wide listing
dir /w /w   - shows a normal listing
dir /w /w /w- shows a wide listing

This deviates from MS-DOS

dir /w  - shows a wide listing
dir /w /w   - shows a wide listing

To toggle it back off MS-DOS requires the /-w switch and works fine with the 
FreeCOM DIR.

When used through an alias like “set alias ls=dir /w” then executing “ls /w” it 
produce results different from what is expected.

Not all options perform toggling. For example:

dir /p  - pauses per page
dir /p /p   - pauses per page

I don’t think the toggling is very important. But, it does deviant from MS-DOS. 
 
I do think that consistency across the options is important.

Any thoughts?

:-)

Jerome

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

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

[Jerome Shidel]

Hi Rugxulo,

> On Nov 7, 2022, at 4:11 AM, Rugxulo  wrote:
> 
> Hi,
> 
>> On Sun, Nov 6, 2022 at 9:08 PM Jerome Shidel  wrote:
>> 
>> Make sure your compiling to the correct memory model. (I think huge, but 
>> you’ll need to double check that)
> 
> Default is Small, e.g. "-WmSmall". I assume "-WmCompact" would work
> better for you?
> 
>> You may need to ensure the actual procedure is declared with far.
>> 
>> Procedure Test; far;
>> Begin
>> End;
> 
> In old freeware TP 5.5, that would be {$F+} at the top and {$F-} at
> the bottom of the procedure. (I believe all procedures within the same
> unit / file are near while external procedures are far by default.)

Yes. In TP 5.5/7.0, {$F-} is the default. The default for any 
function/procedure uses near call/return model. Func/Procs in units that are 
declared in the interface section use far call/ret process. 

> 
>> Also, you may need assign the address to a plain pointer and typecast the 
>> call.
> 
> Is that needed??

Most likely not needed. But, if all else fails, it may be something to try. 

>> Also, there are also compiler directives for FPC regarding compatibility.
> 
> Default dialect is "fpc", which is less strict than {$mode tp}, e.g.
> it does change function pointer syntax a bit, but it also gives you
> structured return types and function overloading.
> 
> {$asmmode intel} is only default for {$mode tp} as well (but you can
> manually enable it, too).
> 
> Don't forget you can also declare inline functions! (Like real
> inlining, not just inline machine code.)
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



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

Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal

[Jerome Shidel]

I’m not at my computer right now. So, this will just be rather vague….

Although I’ve used FPC/Lazarus for some things, I haven’t used it to create 
stuff to run under DOS. But, I have seen some weirdness regarding this sort of 
thing when targeting current GUIs. I forget  the exact details. However, there 
a few things you might try if you have not already.

Make sure your compiling to the correct memory model. (I think huge, but you’ll 
need to double check that)

You may need to ensure the actual procedure is declared with far.

Procedure Test; far;
Begin
End;

Also, you may need assign the address to a plain pointer and typecast the call.

Type 
  MyProc = procedure;

Var
  P : pointer;

Begin
P := @Test;
MyProc(P^);
End.

Also, there are also compiler directives for FPC regarding compatibility. 

Jerome




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

Re: [Freedos-devel] Interim Build T2211

[Jerome Shidel]

> On Nov 1, 2022, at 1:23 PM, Wilhelm Spiegl  wrote:
> 
> did you remove or fix antivirus as i reported in this version, maybe also 
> newer virus definition?
> I found nothing about this in changelog.
> 
> Willi

No changes were made to the antivirus yet. 

Not sure who wants to work on fixing it. Or, if it will be left as is or 
removed. 

Jerome



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

[Freedos-devel] Interim Build T2211

[Jerome Shidel]

Interim Build T2211 is now available.

(Please remember: You may need to refresh or purge your browser cache.)

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Summary of changes since T2210:

2022-10-31 12:31:41 upx (shidel): renamed file
2022-10-31 12:28:07 upx (shidel): updated to v4.0.0
2022-10-21 00:51:16 keyb (Aitor Santamaría): Minor changes for improved 
handling of commandline
2022-10-19 22:35:51 keyb (Aitor Santamaría): Minor changes in documentation
2022-10-19 21:54:25 keyb (Aitor Santamaría): Minor version update
2022-10-19 21:49:50 keyb (Aitor Santamaría): Merge branch 'master' of 
https://gitlab.com/FreeDOS/base/keyb
2022-10-19 21:48:28 keyb (Aitor Santamaría): New modifiers for (de)activating 
the lock keys
2022-10-17 17:23:45 htmlhelp [unstable] (Shidel): Merge branch 'crash-fixes' 
into 'master'
2022-10-17 09:00:45 mistral (Daniel Monteiro): feat: update code to the 2.0 
release
2022-10-16 12:47:32 project_FDI (shidel): removed dgjpp from master bonus 
package list update
2022-10-16 11:58:41 project_FDI (shidel): master package list update
2022-10-08 09:10:33 links (shidel): updated to v2.28
2022-10-03 22:24:40 htmlhelp [unstable] (Andy Stamp): Fix crash bug in 
headerTagSubstitution with &-entities
2022-10-03 22:22:01 htmlhelp [unstable] (Andy Stamp): Cleanup ampSubsInternal 
to be more readable

Please note: Items in the log marked with ‘[unstable]’ denotes that package is 
pulled/created from the “unstable” branch on the GitLab Archive. It should be 
tested. Once that has happened, it can be merged in to the “master” branch to 
be included with the next OS release. For example in the previous monthly 
interim build, there were entries for V8POWER.
2022-09-28 09:04:39 v8power [unstable] (shidel): v22.09.28
At present, there has been no feedback on that package and it has not yet been 
merged into it’s master branch for inclusion in the next OS release.

Interim Builds are not the same as OS release builds. Interim Builds will 
prefer using an “unstable” branch over a “master” branch when available. OS 
release only use “master” branches to create the release media.

:-)

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

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

[Jerome Shidel]

Hi, 

> On Oct 28, 2022, at 7:13 AM, Eric Auer  wrote:
> 
> [..]
> 
> PS: I noticed that Jim's TRCH only translates one char at a time,
> do we already have a variant which is as powerful as Linux "TR",
> supporting for example TR 'a-z' 'A-Z' or TR -d '\n' and so on?
> Non-DOS Notepad++ text editor also juggles with upper/lower case.

While not a clone of TR, VSTR (part of V8Power Tools) will convert case along 
with several other things. Mostly some of text related functionality similar to 
several Unix/Linux tools that are needed by the OS installer. Things like 
search and replace, stripping indentation and blank lines, return fields for 
lines, etc.

Being part of V8PT, it is installed with BASE and FULL. It is also available 
when booting the LiveCD.

:-)

Jerome





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

Re: [Freedos-devel] Detecting VMs

[Jerome Shidel]

Hi,

> On Oct 26, 2022, at 3:11 PM, Robert Riebisch  wrote:
> 
> Hi Jerome,
> 
>> Without going into great details, I have made a couple programs that
>> can do some (i think) neat visual tricks that require VGA support. One
>> such visual trick works on nearly all REAL hardware and in DOSBox.
>> However, it does not work in any other tested VM. Therefore testing for
>> any VM (that is not DOSBox) and disabling the feature when appropriate
>> is very useful to that program.
> 
> Are those tricks really worth making your program more complicated?
> You don't have to include any feature you can think of.

For some things, I think so. 

However, testing for specific VM’s isn’t always related to a trick to pull off 
a fancy visual effect. Sometimes, it is necessary for other reasons. 

A good example waiting for vertical retrace to prevent video shear in a game. 
In a very simple program, you could use it for timing (yes, there are much 
better and reliable methods). However, some virtual machines don’t emulate that 
function properly. With the end result in that VM as always ready to write. I 
think VirtualBox is one. So, a program that relies on it actually taking some 
time between refreshes will not function as intended.

It’s just a simple example. Like I said, there are better methods for timing. 
Also when they are known, many limitations of specific VMs can be worked 
around. Features turned off by default. etc.

Not really much different from turning off/on Anti-aliased fonts on early 
versions of windows. 

> Cheers,
> Robert

:-)

Jerome



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

Re: [Freedos-devel] Detecting VMs (was: Bonus/Devel CD)

[Jerome Shidel]

> On Oct 25, 2022, at 11:24 PM, Bret Johnson  wrote:
> 
>> Jerome's V8Power Tools will detect some VMs, IIRC:
> 
> Yes, I checked that out.  In the version I looked at, it detects 3 different 
> VMs all using the same method (looking for a specific identification string 
> in BIOS memory).  That method works with some VMs, but not all.
> 

Correct. It mostly does string searches. 

It also has a general Emulation detection. But, that rarely detects a “generic” 
VM. 

Personally, I think detecting the main VM platforms is “good enough” for most 
purposes. I don’t worry about the more obscure virtual platforms. 




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

Re: [Freedos-devel] Detecting VMs (was: Bonus/Devel CD)

[Jerome Shidel]

> On Oct 26, 2022, at 3:40 AM, Ralf Quint  wrote:
> 
> On 10/24/2022 6:38 PM, Bret Johnson wrote:
>> Anyway, I'm wondering how "involved" FreeDOS should be in the VM world (I 
>> think in today's world the vast majority of users install DOS under a VM 
>> rather than on real hardware, though I personally do both). How involved in 
>> testing/recommending applications (including games) for compatibility should 
>> FreeDOS actually be, particularly when a VM is involved?
> To be honest, we should not get involved with ANY VM at all. This will just 
> lead us potentially into a deep dark rabbit hole that leads us far away from 
> Kansas^H^H^H^H^H^Hthe DOS world.
> The goal of FreeDOS is to be MS-DOS 6.0 compatible, so any VM should be able 
> to run MS-DOS 6.0, and so should FreeDOS run as well.
> 
> Going by the messages either here in the mailing list or the occasional post 
> on the Facebok page, it seems the vast majority of compatibilty issues are 
> related to support of specific hardware, mainly sound cards and network 
> cards. That is absolutely something that is only to be solved on side of that 
> VM.
> 
> Another possible issue is that of incompatibilities with some memory managers 
> included in FreeDOS. And this is a really tricky part, as there is very 
> little active participation of the authors in order to properly diagnose and 
> fix any such issues that would arise..
> 
> All in all, I think venturing too far into the support of VMs is a very 
> slippery slope for us, with only a few people actually participating
> 
> 
> Ralf
> 


For VM detection, it is mostly useful for current DOS application development.

Without going into great details, I have made a couple programs that can do 
some (i think) neat visual tricks that require VGA support. One such visual 
trick works on nearly all REAL hardware and in DOSBox. However, it does not 
work in any other tested VM. Therefore testing for any VM (that is not DOSBox) 
and disabling the feature when appropriate is very useful to that program.

Also, I have seen where a VM says it supports something, yet it does not. Under 
those, sometimes a workaround is needed. 

But like I previously mentioned, I really only worry about the VM platforms 
(DosBox, QEMU, VirtualBox and VMware) I think are most common.

 

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

Re: [Freedos-devel] Bonus/Devel CD

[Jerome Shidel]

Although there has not been a lot of feed back on what to do with the 
excessively (nearly 1GB) BonusCD in T2210, I think the majority of feedback has 
been in favor of splitting off the development packages from the BonusCD on to 
their own DevelCD. 

And, we should do this instead of dropping packages for several reasons. The 
main reason is for the convenience of users who may be on older hardware or 
without network support. Those users might experience some difficulty getting 
all of the programs they need into their “DOS” machine. 

It has also been suggested to provide a “Developer Oriented” release of 
FreeDOS. One that is specifically geared towards DOS development. 

Another suggestion has been to just slim down FreeDOS to basic DOS.  Leaving it 
up to the user to find, download and install what they want after the OS has 
been installed.

Personally, I don’t think dropping everything except basic DOS is the way to 
go. I think doing so would be off-putting to most “New” users. Although they 
would have a fully functioning DOS, it really would not do much on it’s own. It 
would require them to go get other software or games and create a usage barrier 
that most would just uninstall the OS an move on to something else.

Most “modern” operating systems either provide numerous bonus software. They do 
this by either providing it on their release media or through an easy method of 
downloading and installing software. There are many examples of this in the 
Linux world. For example, openSUSE does both. It provides thousands of extra 
packages on it’s release DVD and also connects to a download center to provide 
them. 

Although the next major version of FDIMPLES will most likely support online 
repositories, it is being written %100 in assembly and not coming soon. Even 
once the new version of FDIMPLES is ready, general networking support under 
FreeDOS is very limited. This leaves us with providing additional packages on 
the release media for the near future. 

I’m unsure of the best solution to the problem. 

I don’t think providing a Developer Oriented skew of the OS is a good idea. 
With the LegacyCD, LiveCD, LiteUSB, FullUSB and Floppy Edition, I think we 
provide to many OS skews already. Since we want to support a wide range of DOS 
hardware, we really need to keep the Floppy and CD version around.  

We could probably drop the LiteUSB for several reasons. I think it’s direct 
usage is very limited and most users probably opt for the FullUSB version. 
Also, every “how-to” and video I’ve seen online that shows how to create a 
bootable USB stick for FreeDOS uses the LiveCD to create it. However, 
occasionally, I do see questions on how to write one of the USB media to a 
flash drive. 

We could also probably drop the LegacyCD as well. There is only a very limited 
range of early hardware that cannot boot the LiveCD. But, it can boot the 
LegacyCD. That hardware will most likely also have a floppy drive. If their CD 
drive is supported by the drivers, they could boot using the “Floppy Boot 
Image” included in the download zip. Once that is done, they can install from 
CD. 

So where does that leave us? I think there are at least two practical solutions 
at present. 

First, split off all development related packages that are on the BonusCD onto 
a new DevelCD. This would require very little work. The Release Build 
Environment (RBE) is already capable of creating multiple extra package discs 
images. However, I will probably want to add some functionality to use specific 
labels for them. At present, it would generate BonusCD0 and BonusCD1. It will 
not be hard to update the RBE to use custom labels for the discs. This first 
solution implies we may eventually have a GamesCD, UtilsCD and others as well. 
If we go down this path, perhaps we should start separating some other packages 
on to their own media as well. 

The second option is to go big. On this path, we could do away with the 
BonusCD. We could keep the LiveCD as-is. But, we could also provide a LiveDVD. 
I do kind of like the idea of providing as much quality software as we can on a 
single disc. On this path we may not need the USB versions. Most users tend to 
use programs like Rufus to create bootable USB drives from the LiveCD.

I don’t know if there is a good solution to this issue. But, I am certain we 
can not provide a "950Mb BonusCD.”

If you have any comments or other suggestions on the problem, please speak up. 

:-)

Jerome







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

Re: [Freedos-devel] FreeDOS Interim Build T2210

[Jerome Shidel]

Hi, 

> On Oct 2, 2022, at 5:08 AM, tom ehlert  wrote:
> [..]
> btw dowloading 900  MB .zip over a 4MB/s download link is a PITA; this
> alone should recommend a split.
> 
> Tom

Imagine downloading it back when DOS was the main home user OS — over a fast 
56k modem. If you somehow managed to download load it without it erring or 
timing out, the next OS release would probably be available when you finished. 

:-)

Jerome

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

[Freedos-devel] MKEYB layout suggestion

[Jerome Shidel]

Hi Tom,

I do not know if you have either the time or interest in this. 

I just wanted to point it out in case you were not aware.

A request for an additional MKEYB layout on the GitLab archive. 

https://gitlab.com/FreeDOS/base/mkeyb/-/issues/1 


The request was for "Implement AI low finger displacement layout”. 

:-)


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

Re: [Freedos-devel] VERIFY reimplementation

[Jerome Shidel]

Hi,

> On Sep 14, 2022, at 3:11 AM, Javier Gutiérrez Chamorro 
>  wrote:
> 
> I am not sure if it could be useful for anyone, but I have just reimplemented 
> VERIFY.COM  by Peter Mikalajunas -1995- 
> (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/verify/ 
> ) in 
> pure assembler. It is not a big deal, but was a personal challenge. With this 
> main .COM executable gets reduced from 5,444 bytes to just 653 bytes.
> 
> Also I noticed that "original" VERIFY was not compatible with the internal 
> command, allowing only /ON or /OFF. My implementation works with ON and OFF, 
> but also with 1 or 0.
> 
> Source code and binaries are available at: 
> https://sourceforge.net/projects/nikkhokkho/files/VERIFY/ 
> 
Your VERIFY and CLS projects seem to have a similar goal to one of my projects. 
I’ve been occasionally creating small and fairly simple assembly programs to 
interact with DOS and BIOS functions. Mostly, it is to fill in those little 
gaps where (Free)DOS doesn’t provide a utility. When (IF) there is enough of 
them to make the project worthwhile, I’ll see about maybe trying to get them 
included with the OS. But for now, I don’t think it is useful enough for 
inclusion.

Anyhow, it is called DONUTS (Disk and Other New Utility Tool Suite) for DOS. 
https://gitlab.com/DOSx86/donuts 

BootDrv - Returns Boot Disk as known to DOS.
LastDrv - Returns Last Drive as known to DOS.
DosVer - Return DOS version number. (DOS 2+ ax=3001, should be enhanced with 
DOS 5+ ax=3306 information)
DosOemID - Return DOS OEM byte. (maybe someday also print things like MS-DOS, 
FreeDOS, etc)
VeriFlag - Return current write verify setting. (Should probably set it)
TestAnsi - Detects if ANSI support is provided. (This is how I found the 
compatibility issue with DEVLOAD, see early posts in this mailing list)
VidKind - Return type of video card support detected (MDA, CGA, EGA, MCGA, VGA, 
VESA/SuperVGA). 

All under MIT License. (However, since these are generally very small and 
simple programs, I'm considering switching it all to The Unlicense)

The small ones are not bound to specific runtime address. Those use only short 
jumps and look up message text relative to the current CS:IP. 
Those can be compiled with org 0x0100, org 0x or org 0xwhatever and that 
output will still work fine as a COM file. 

Anyhow if you think you (or anyone) would like to contribute to the project, 
I’m open to the idea of adding additional tools or improving the existing ones.

Some things off the top of my head that may be useful…

DrvList - Return a list of Drives. Probably differentiating between Floppy, 
Hard, CD/DVD and etc.
Now - return current time (similar to using TIME /d)
Today - return current date (similar to using DATE /d)
Epoch - return elapsed time in seconds since 1980. 
DosSwtch - return / set dos switch char.
IsLoaded - return wether or not any driver, TSR or other program is currently 
loaded into memory.
DosCntry - return DOS country specific information (ax=3800)
DrvOnOff - enable/disable drive and possibly status. (ax=5f07,ax=5f08)
GetCodeP - return current codepage settings (ax=6601)
LFNAvail - return if LFN support is active. 
and many more…

Also, most of the existing tools should be enhanced to provide ERRORLEVEL 
results as well. 

:-)

Jerome

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

Re: [Freedos-devel] Ré : When a system with limited filenames length combine directories into one

[Jerome Shidel]

Hi Paul, 

Well….

> On Sep 6, 2022, at 12:18 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> I wrongly said:
> >It's probably ok... because fdnpkg probably won't too.
> Nonsense! fdnpkg have no way to know that many directories have been combined 
> into one.
> 
> So I just need fdpkg to accept to combine directories with same 8 chars 
> truncated length to be combined together.


If the DJGPP program (DJ_GPP) works fine when the long directory names are 
truncated and combined, a possible solution would be to create a utility (or 
add an option/modify fdpkg.sh) to perform the task. Basically, scan directory 
names and if the would be truncated to 8.3 chars (and collide with another 
directory), to just do that in advance. 

I don’t know how familiar you are with bash scripting. However, the fdpkg.sh 
shell script was something thrown together quickly and is not very complex.

A general overview of what happens when it is executed…

First, it sets a couple internal global variables. Everything else is broken 
into functions to make it more organized. Then it calls the PKGU_main function 
with the command-line passed to the script.

PKGU_main - parses the command line options and either expands zips or tries to 
compress paths into archives. When compressing and it is LFN mode is enabled 
(the default, set by "LFN_ZIP=true”), it will call the a function 
(PKGU_SmashLFN) to see if any LFNS are present and any LFNFILES.ZIP archives 
are required. Otherwise, it will just proceed without checking. Next, it will 
attempt to compress the path as DOS 8.3 compatible. If this cannot be done, the 
script will abort with an error.  

PKGU_SmashLFN - looks at the the primary directory names and determines if they 
are SOURCE, NORMAL or SPECIAL directories (like LINKS). Those are either 
handled like sources (PKGU_CheckSources), the binaries (PKGU_CheckPath) or 
specifically exempt from LFN scanning and compression. 

PKGU_CheckSources and PKGU_CheckPath - Basically do the same things in a 
slightly different way with with slightly different settings. The search for 
the LFNs and Compress those when found. Their are slightly different conditions 
used by each to determine what qualifies as a Long File Name. PKGU_CheckPath 
uses the PKGU_SearchLFN to scan for any files that are NOT compatible with 8.3. 
However, PKGU_CheckSources uses PKGU_SearchEFN that will do the same but 
include any filename that is not uppercase. 

When the RBE performs the compression of packages, it does some similar 
scan/compressing. However for several reasons, it always compresses the SOURCE 
directory. Primarily, this tends to reduce the overall size of the archive. It 
also requires less disk space when sources are installed. A side benefit is 
that when always compressing that path, it never needs to actually scanned. I 
should update fdpkg.sh to just always compress those files without scanning to 
make it more like process used by the RBE.

So….

There are several ways to add a TRUNCATE and COMBINE long path names to the 
script. First, probably add a global variable to en/disable allowing the 
action. Something like LFN_CRUSH=false. Then a command line option like ‘-c’ to 
enable and maybe ‘-n’ to disable it. (default probably -c)

Then under PKGU_SmashLFN for specific paths call a new function to perform the 
action. Or, do that under PKGU_CheckSources and/or PKGU_CheckPath. The new 
could be called PKGU_CrushDirs. 

PKGU_CrushDirs could be implemented several ways. The easiest would be to just 
figure out what the truncated directory name would be and see if that collides 
with anything else. When that happens, just move that stuff into the same 
truncated directory. 

If that sounds like it would solve the problem, I could add it to the fdpkg.sh 
script. Then if it works, implement the equivalent in the RBE.

:-)

Jerome





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

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

Re: [Freedos-devel] Make fdpkg.sh to work with gitlab zip files

[Jerome Shidel]

Hi, 

> On Sep 5, 2022, at 11:35 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> Sadly... fdpkg.sh does not work on dowloaded zip project files from Gitlab, 
> most probably because the wanted dirs (APPINFO, SOURCE, etc) are not in root.
> 
> Would you consider to edit fdpkg.sh to work for these zip files too?
> ...
> Or would you prefer to let it as an exercise to the user?

A couple things… If you intend on updating the Git packages, why are you not 
cloning them? Why download as a zip?

Not sure what you are doing to experience an issue...

It works fine with those downloads. But, you need to make sure the tp directory 
is correct. For example, you download dj_flex and receive dj_flex-master.zip 
from gitlab. You extract it to d_flex-master/ and now have a broken package. 
You need to rename that directory to dj_flex.  SO, you end up with 
dj_flex/APPINFO/* and similar paths. Then from the the parent directory of 
dj_flex you run "fdpkg.sh dj_flex" and it will compress it into dj_flex.zip.

I just did that with dj_flex to verify GitLaB was not doing something odd.

:-)

Jerome

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

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

Re: [Freedos-devel] source directory (DJGPP packages)

[Jerome Shidel]

> On Sep 5, 2022, at 12:03 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> Is there a process that will take the files in SOURCE/(PKG)/ and make them a 
> SOURCES.ZIP file?

The answer to that is… Yes, no, sort-of, not really.

> I explore a bit and saw that some packages are just source files (not 
> compressed)... and some packages have sources.zip.
> So I begin to think that there is nothing special that produce SOURCES.ZIP 
> files... and so, that would means my source files should be
> 8.3 compatible (for fdnpkg to accept them).

While there are several ways of doing things, to see how we are currently 
packaging programs, the “exploring” you should look at the latest release 
media. Not packages from previous install media or other places like the online 
repository or “FreeDOS packages” provided by 3rd parties. 

> Using zip -k (yeah... I was using my GUI Zip archive... that was causing 
> incompatibility with fdnpkg... but install zip that I believe will be 
> compatible) that coerce
> long file names to compatible DOS filenames and that check for conflicts with 
> truncated files... I could generate 8.3 ok files... but with very very 
> annoying and dangerous
> efforts (any change risk to make the code not to compile I think).
> 
> Remember... source code for DJGPP packages are source code used on Linux 
> (mostly)... so they were not designed with 8.3 filenames... and could even
> contains some unicode sometimes.. I think.
> 
> Also, some are very big like:
> http://www.delorie.com/pub/djgpp/current/v2gnu/gcc1220s.zip 
> 
> which is 116 Mb zipped. (For this particular case I proposed a separate 
> source package: https://gitlab.com/FreeDOS/devel/dj_gcc/-/issues/1    
> )
> 
> So my intention goes toward in most cases, to just include the zip files 
> dowloaded from DJGPP (renamed SOURCES.ZIP ... or not renamed... unsure about 
> that).
> 
> This message is mostly a ... does it seems an appropriate decision?

The FreeDOS GItLab Archive is where packages for the OS and Online 
Download/Update repository are staged. The RBE (Release build Environment) 
pulls each of those projects down, does some verification, minor processing and 
compresses them for inclusion in an OS release. 

The compression portion of that process has several actions it performs. It 
will compress all sources to preserve long file names and possible 
case-specific files. It will also check the remaining files in other 
directories to verify they are 8.3 compatible. If LFN files exist in those 
directories, the are compressed by section (top most sub-directory) into a 
embedded LFNFILES.ZIP archive. For several reasons, this is not a perfect 
solution. It is just a compromise that hopefully causes the fewest problems for 
end users. 

Eventually, there are a couple additional things that will probably be done to 
make LFNs in FreeDOS more user friendly. For example, the package could include 
some LFN related information in the metadata file. Like has LFN sources, LFN 
files, or possible needs LFN support to work at all.  Requiring LFN to work at 
all is a bad idea for DOS applications. Additionally, future versions of 
FDIMPLES could uses such flags and alert the user when LFN support is 
recommended (and not being used) before a package is installed. 

When working with the FreeDOS GitLab Archive (whenever possible), all archives 
within a package should be extracted. The utilities used by the RBE and 
elsewhere will deal with LFNs and what/how things get compressed automatically. 

As for testing packages that get may be added to the FreeDOS GitLab Archive 
included, I have not got around to adding the functionality to the fdvcs.sh 
utility. Mostly, that is because I haven’t had the time or motivation. So, I 
keep using a much older separate tool that does things in a slightly different 
way than those in the RBE. But, the old tool is “close-enough” and is what gets 
used when sending things to the Online Download Repository. 

In the meantime, I’ve added the old package compression utility that I still 
use when making updates for the Repositories to the PDK (Package Development 
Kit) under the 
https://gitlab.com/FreeDOS/OS/pkgdevel/-/tree/main/tools/obsolete 
 directory. 

*** DO NOT *** run it on your packages git (or any other VCS) working 
directory. It will strip out all of the VCS data during compression. Since 
filename collisions are almost guaranteed when things are stored in the root of 
a package, any files there are stripped out as well. 

It is easy to use and is for macOS and Linux.  Simply copy your files to a new 
directory and run the tool with that path as a parameter. It excepts multiple 
paths and wildcards. So for example you have a dozen DGJPP packages you what to 
check, you could copy them and run “fdpkg.sh dj*” 

[Freedos-devel] IBIBLIO timestamps

[Jerome Shidel]

Hi All, 

Just want to give you all heads up… 

As you maybe aware, Jim has been spending time straightening out much of the 
files stored/mirrored on ibiblio. Part of the process has been adjusting many 
of the timestamps for archives. To help visitors easily see the age of files 
spread out through all of those sub-directories, I ran a simple option provided 
by my fdvcs.sh[1] script. Basically, it adjusted all of the directory 
timestamps under files/ to that of the latest file they contain in their 
hierarchy. 

So, you may notice some directories might be older (or newer) than the last 
time you visited. 

:-)

Jerome

[1] FDVCS.SH is a script preserving and managing timestamps and some other 
functions that are mostly for dealing with version controls systems like git 
that trash timestamps. It’s not perfect. But, it works well enough. 
https://gitlab.com/FreeDOS/OS/pkgdevel/-/blob/main/tools/fdvcs.sh 


[2] http://ibiblio.org/pub/micro/pc-stuff/freedos/files/ 
 ___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] group-devel.htm file broken by dj_ renaming

[Jerome Shidel]

> On Sep 2, 2022, at 7:54 PM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> Yes, indeed... (the cache issue again), sorry.
> using Firefox 104.0.1 under NixOS

Interesting.

Lately for compatibility reasons, I’ve been using Firefox (104.0.1) more for 
stuff on macOS. I have not noticed an issue. If it has been a little while 
since I visited a page (like on the download repo), it will automatically 
refresh it. However, if I visit one of those pages, push an update and go pack 
to that page, the old data is displayed. Because of normal caching, it is 
expected. I’ll just click the refresh button and it will fetch the new page.

I’m far from an expert on FireFox. Perhaps there is a setting that is causing 
your browser to not automatically update the page (even when it has been a 
month since your last visit).  

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

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

Re: [Freedos-devel] group-devel.htm file broken by dj_ renaming

[Jerome Shidel]

Hi…

> On Sep 2, 2022, at 5:37 PM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> On:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/group-devel.html
> the DJGPP packages seems to not work anymore due to the package renaming.
> 

That’s the browser caching issue again. 

 I thought you said you are using Linux. But, what browser are you using?



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

Re: [Freedos-devel] An allegro game library version 4.2.2 package

[Jerome Shidel]

Hi, 

> On Sep 1, 2022, at 7:44 PM, Jim Hall  wrote:
> 
> Those 8.3 DOS filenames can be limiting for package names, so I like
> the idea of moving the DJGPP packages to DJ_x instead of DJGPP_xx.
> I saw your note on GitLab about this, too.
> 
> If you're also rebuilding the DJGPP packages (newer version?) you
> might rename the packages to something like this:
> 
> djgpp_bn (DJGPP binutils) ==> dj_bin
> djgpp_bs (DJGPP Bison) ==> dj_bison
> djgpp_db (DJGPP gdb) ==> dj_gdb
> djgpp_fq (DJGPP faq) ==> dj_faq
> djgpp_fx (DJGPP Flex) ==> dj_flex
> djgpp_gc (DJGPP gcc) ==> dj_gcc
> djgpp_gp (DJGPP gpp) ==> dj_gpp
> djgpp_mk (DJGPP make) ==> dj_make
> djgpp_ob (DJGPP Objective-C compiler) ==> dj_objc
> djgpp_rh (DJGPP rhide) ==> dj_rhide
> djgpp_tx (DJGPP Texinfo) ==> dj_txinf
> djgpp (DJGPP environment) ==> djgpp [keep the same]
> 
> Those names make more sense to me.
> 
> Jerome just released the T2209 test build, but maybe this could be
> added to the T2210 test build?

I’ll go ahead and implementing the new DJGPP package naming scheme. 
While not difficult, there are several steps involved with renaming packages 
and it will take a few minutes. 

:-)

Jerome



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

Re: [Freedos-devel] FreeDOS T2209

[Jerome Shidel]

Hi,

> On Sep 1, 2022, at 11:08 PM, Jim Hall  wrote:
> 
> 
> 
> 
>> On Thu, Sep 1, 2022, 6:59 AM Jerome Shidel  wrote:
>> (...)
>> Since we have not made a final decision on how many or where to keep 
>> previous test builds, I simply placed the old T2208 under 
>> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/previous/T2208/
>> 
>> (...)
> 
> 
> 
> Didn't we decide to keep one older version: the current year build at test 
> and the previous test build at test.old?

I wasn’t sure if it was a decision or something we were still considering. 

No problem.

Tomorrow I’ll move T2208 from test/previous/T2208/ to simply test.old/.

:-)

Jerome

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

Re: [Freedos-devel] Ré : FreeDOS T2209

[Jerome Shidel]

> On Sep 1, 2022, at 9:46 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> the report.htm seems up to date... but the title is still about T2208, and it 
> says it was built: 
> Monday August  1, 2022 at 05:56:27 AM EDT

You probably need to refresh your browser or dump it’s cache.



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



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

[Freedos-devel] FreeDOS T2209

[Jerome Shidel]

Hello all,

The FreeDOS interim test build T2209 is now available for download at

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Primary changes since T2208:

2022-08-21 15:03:44 curl (shidel): updated to v7.84.0
2022-08-21 13:53:47 edlin (shidel): update to v2.21
2022-08-21 09:17:22 pgme (shidel): Improved mouse compatibility
2022-08-09 15:23:58 project_FD-NLS (shidel): report update
2022-08-09 10:43:04 sort (shidel): NLS: Update FR and TR for SORT
2022-08-09 10:12:14 project_FD-NLS (shidel): Merge pull request #141 from 
cardpuncher/master
2022-08-09 16:38:46 project_FD-NLS (cardpuncher): Add files via upload
2022-08-04 17:23:31 himemx (shidel): updated to v3.37
2022-08-03 21:19:16 keyb (Aitor Santamaría): XT class fixes by Davide Bresolin
2022-08-03 07:40:26 fbc (shidel): updated to version 1.09.0
2022-08-03 07:27:29 fbc_help (shidel): updated to version 1.09.0
2022-08-03 00:48:14 keyb (Aitor Santamaría): Fix codepage issues
2022-08-03 00:21:08 keyb (Aitor Santamaría): More control over allocation 
strategy (/NOUMB)

Since we have not made a final decision on how many or where to keep previous 
test builds, I simply placed the old T2208 under 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/previous/T2208/
 


Going forward, I think we have a couple practical ways to handle it.

1) Always place all interim builds under there version under test. For example, 
test/T2208, test/T2209 and when next moth comes out test/T2210. And so on.

2) Place the latest build under test (current location) and retire them to 
directories life test/T2208. 

3) Just keep the current placements of test for current build and directories 
like test/previous/T2208 for retired builds. However, if we only keep one or 
two previous builds around, this seems like an unnecessary extra directory 
layer. 

And obviously, we will need to decide how many old test builds to keep around. 

:-)

Jerome


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

Re: [Freedos-devel] Editing LSM files under Linux (code page considerations)

[Jerome Shidel]

Hi,

> On Aug 31, 2022, at 2:36 PM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> 
> I am trying to do a 12.2.0 packagte for GCC.
> I am editing LSM files on Linux... and beginning to ask myself how much bad 
> it is.
> I means... I am probably transforming them to UTF-8 unicode... so the 
> codepage indicated in the file would be wrong now.
> And if  I would edit them in DOS... I would have to change code page before 
> editing any of them... I would guess.
> So... can I edit them in UTF-8 unicode... is there a tool that check that and 
> add the modified-date?
> 

First, you don’t need to worry about the modified-date field. If the field is 
not present, the repository management utilities will add it automatically when 
the package is added to a repository. 

As for the basic LSM meta-data file, that needs to be in DOS codepage 437. 

The language specific files in that directory must be in the appropriate DOS 
codepage for that language. The fields in those language specific files work 
like overrides to the standard English version (LSM). 

For example, the English contains a version field. But, that field is excluded 
from the language specific version. So, when the version is updated, all 
languages show the new version. However, each language has its own description 
and summary field. So, those are shown for that language instead of the default 
English when using programs like FDIMPLES. 

For packages that are kept on the official repository and/or provided on the 
various release media, there is some additional things to be consider.

The master English meta-data always lives in the packages. However, the 
translations for the package metadata lives over at the FD-NLS project[1] in a 
couple big language specific CSV files. 

That data gets staged in the GitLab FreeDOS Archive[2]. Which is used to 
assemble packages for the releases and for the update repository on ibiblio[3].

The easiest way to edit those massive CSV files for the language specific 
metadata is through the FD-NLS Desktop App[4] that I created. There are 
Windows, Linux and macOS versions. 

The app is pretty code at editing those and does all the UTF/Codepage 
conversion stuff automatically. It has a live simulation/preview of what the 
metadata will look like in DOS using FDIMPLES and some other features.

Eventually, it will support working on actual translations for the individual 
programs as well as their metadata. But unfortunately, I just don’t have the 
time to work on it at present.

:)

Jerome

[1] https://github.com/shidel/fd-nls
[2] https://gitlab.com/FreeDOS
[3] 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html
[4] https://up.lod.bz/FDNLS_LNX




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

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

[Jerome Shidel]

Hi all,

When it comes to releasing something as public domain, I think “The Unlicense” 
(aka CC0) is a great choice and maintains the spirit of public domain.

Basically it says, do whatever you want with it. But, don’t blame me if it 
doesn’t work or breaks something.

https://opensource.org/licenses/Unlicense

It is also a recognized open source license.

:-)

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

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

[Jerome Shidel]

> On Aug 25, 2022, at 4:10 AM, Eric Auer  wrote:
> [..]
>> It seems there is a lot of programs that cannot run on 8086...
> 
> Those should be excluded in 8086 installs, but as far as
> I remember, at least one of the installers already pays
> attention to that. Mateusz and Jerome might know more :-)

Since a user is most likely not going to have either a CD or USB drive in a 
system that is not at least a 386, the CD and USB media will install programs 
that require s 386. Those also boot the 32bit kernel.

The Floppy Edition boots the 16bit kernel. It installs based on hardware 
capabilities. At present, you must tell it to limit its install to only 8086, 
186 or 286 machines. Otherwise, it will assume at least a 386 level of support. 
Eventually when I have the time (and feel like it), I will get around to 
updating the CPU detection and auto detection of sub-386 machines.




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

Re: [Freedos-devel] GitLab - problem with codepages

[Jerome Shidel]

Hi, 

> On Aug 2, 2022, at 7:15 PM, Andrew Bird via Freedos-devel 
>  wrote:
> 
> Hi Aitor,
> 
> On Wed, 3 Aug 2022 00:37:29 +0200
> Aitor Santamaría mailto:aitor...@gmail.com>> wrote:
> 
>> Hi,
>> 
>> I am trying to adapt to work with GIT from the GitLab repository, and am
>> committing a couple of changes on FD-KEYB that I had ready.
>> 
>> However, I have noticed a problem with the codepages. I try to avoid
>> non-ASCII characters, but seldomly use those that are common to most
>> codepages.
>> What I see is that neither the character stored (that the web omits) or the
>> character committed (strange character) are correct, which obviously didn't
>> happen when I simply committed a ZIP file with everything:
>> 
>> [image: image.png]
>> 
>> I can live with them and try and take all characters from ASCII, but I am
>> just worried if the sources at GIT would all be affected by this apparent
>> codepage problem.
>> 
>> Maybe someone more expert on GIT than myself can add something on this.
>> 
>> Aitor
> 
> The thing is that git stores text files internally as UTF-8, so unless
> any uploaded text file has a match in the .gitattributes file it's assumed to 
> be that (or
> binary if can't be interpreted as UTF-8). Consequently any diff shown
> is anybody's guess as to what codepage it might be encoded in. You
> could set .gitattributes to match each codepage which might make sense
> for nls files etc, like I have done for some projects like find (you'll see 
> that the diff is rendered properly)
> https://github.com/FDOS/find/commit/f763ce94f837e15c2e865e8fc333f8ca8396d427 
> 
>  . Though ideally we'd keep all master translation files in UTF-8 format and 
> translate to specific codepages at build time.
> If the problematic file is a source code file, then I'd tend to encode it in 
> UTF-8 format as any special chars are likely to be in comment sections and so 
> have no bearing upon output.
> 
> Hope it helps, Andrew

There some things I’ve noticed while doing the FD-NLS project on GitHub and the 
Archive on GitLab regarding DOS Codepage files.

Basically, some of the code page translation files, when viewed through the web 
interface, show incorrect characters. However, checking out the project (or 
cloning) it back to a local machine shows the files were not changed and the 
codepage was preserved. 

The biggest problem I’ve found is modern editors mangling codepages or 
incorrect codepages being used for a given language. In part that is why I 
started the FD-NLS Desktop App. 

Overall, It is probably a good idea to include a UTF-8 version of any 
translated text along with the codepage versions.

Jerome

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

Re: [Freedos-devel] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Eric,

> On Aug 1, 2022, at 2:18 PM, Eric Auer  wrote:
> 
> 
> Hi! Trying to sort through the log on
> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
> 
> it seems that most changes are NLS updates, build infrastructure,
> documentation and similar. Actual app changes seem to be those:
> 
> - Sayswho (Senso) game now with Adlib sound
> - WDE update to 0.99? 0.30b? 3.0c??

Well, several years back, when we were fixing License information and other 
meta data, WDe had its version changed from 3.0b to 3.0c to not confuse package 
installation, management software and whatnot. However, doing that confused a 
lot of people.

I recently noticed WDe had an update. However, it was v0.99. This caused me to 
examine the 3.0b package more closely. As it turned out, it was labeled 
incorrectly the whole time. It was not v3.0b. It was v0.30b. 

So, I fixed the version number for the existing package from v3.0c to v0.30b. 
Then updated it to v0.99.

> - MCTP update to 2022-07-01
> - JWASM update to 2.15
> - DOSLFN 0.41f "extending directory fixes"
> - VMSMOUNT 0.5c
> - LINKS 2.27
> - SBPMIXER added
> - XDEL 2.08
> - FASM 1.73.30
> - HIMEMSX 3.54
> - JEMM 5.81
> - DOJS 1.8.0
> - DOSZIP 2.63
> - UTF8TOCP 0.9.4 (also mostly infrastructural)
> - MEM 1.12
> - GOPHERUS 1.2.1
> - EUPHORIA 3.2.2
> 
> Maybe this list would be useful for an announcement, while the
> log is more for providing a chronological under-the-hood view
> of internal changes :-)
> 
> Regards, Eric
> 
> PS: Let me know if I overlooked additions or updates of apps/drivers!

I think that is all the updated packages. But, I’m not at my computer right now 
and cannot easily compare the log against the list.

:-)

Jerome

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



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

Re: [Freedos-devel] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi, 

> On Aug 1, 2022, at 10:51 AM, tom ehlert  wrote:
> 
> Hallo Herr Jim Hall,
> 
> am Montag, 1. August 2022 um 16:08 schrieben Sie:
> 
>>> Hi! I agree it would be good to have a changelog visible before
>>> downloading those 100s of megabytes
>> [..]
> 
 I think it's pretty rude behaviour wrt the testers to throw once per
 month 500 MB with a bazillion of subprojects at the testers, with only
 'please test this' without any mentioning of
>> [..]
> 
> 
>> I think folks may have missed that there's a changelog in the Interim
>> Test Build directory:
> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
> 
>> From my reading of the changelog, almost all of the changes in this
>> Interim Test Build from FreeDOS 1.3 are NLS updates, plus some version
>> updates of other packages like dojs, jemm, gopherus, and a few others.
> 
> so we should test the version numbers?
> 
> 2022-02-25 06:46:13 gopherus (Shidel): v1.2.1
> 2022-03-02 13:54:44 utf8tocp (Shidel): v0.9.4
> 
> is not a changelog. a changelog explains the what and why of the
> change. not that the change resulted in a new version number.
> 
> version numbers of the packages contained should be possible to obtain 
> somewhere
> else, even if the package didn't change.
> 
> Tom

You are correct that it is not a change log for the programs themselves (like 
gopherus and utf8tcp). 

It is however a changeling for the Release itself. Using your example, the 
Release was updated to v1.2.1 and v0.9.4 for those packages. (I  should 
probably commit with messages like “updated to v1.2.1” instead of just 
“v1.2.1”. I do need to work on improving my commit messages.) 

Anyone who would be interested in what changed when updated to v1.2.1 would 
need to examine the change.log for that specific package.

In part, that is because few packages have their development repository in the 
FreeDOS Archive on GitLab and are maintained elsewhere. In part, it is because 
the different developers maintain their change.logs in different ways with 
different formats. In part, it is because highly active projects would pollute 
the release change log and possibly the log mostly worthless. But perhaps for 
convenience, it would be better to include those when possible.

An example of such pollution is all those “NLS: Package and Description update” 
entries. After Wilhelm and Berki updated the package descriptions at FD-NLS for 
DE, FR & TR, I ran an automation tool. It checked each packages LSM metadata 
and updated it when needed. It also imported any new translations for those 
packages. Once that was done, if there were any changes, it pushed the updates 
to the FreeDOS Archive. There were a lot of minor changes spread across nearly 
all packages. In the future, I may have the RBE filter out such things.

The exception to all that is a couple packages that live in the Archive. Like 
the FDHELPER package. Also projects used directly by the RBE to build the 
release are included. Like the RBE itself, FD-NLS, FDI and FDI-x86 get all of 
their messages (with some filtering) included. 

This is the first interim build and automated change log creation for the 
release. 

No doubt there will be changes. (which I’ll need to remember to log)

:-)

Jerome

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

Re: [Freedos-devel] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Jim,

> On Aug 1, 2022, at 7:32 AM, Jim Hall  wrote:
> 
> 
> Do you want me to post this as a news item on the website?

Probably a good idea. Also, maybe Facebook and Twitter. The more testers the 
better. 

I figured I’d just mention it here. Then leave all the other “public” 
announcement stuff to you. :-)

> 
> My first thought is Yes, because this is a good way to engage folks who want 
> to test FreeDOS. And I think it's good to let folks know about the Interim 
> Test Builds. At the same time, I'd want to be clear in that news post that 
> this is a test build, so things may be broken, or incomplete, etc, because 
> it's meant for testing and is not meant to be a new version of the official 
> distribution.
> 
> I don't think we'd want to post news items about every test build, though. I 
> think that would be too much.

Those were my thoughts as well. 

Probably be good to mention that it is planned for a new one to be created 
monthly. Probably, the 1st of the month. Unless we feel it’s better to do it on 
a different schedule.

The build will include all changes to date. May be very little. May be a lot. 
In the event there are no changes, then one won’t be released. But, I assume 
that will be rare. 

> 
> But I wanted to ask what you preferred.

When T2209 is release, I think I will move T2208 into a sub-directory under 
test. Basically….

…/test/- current test build
…/test/T2208/   - old test build

Then we can keep as many old ones around as we want. 

> 
> 
>> On Mon, Aug 1, 2022, 5:19 AM Jerome Shidel  wrote:
>> Hi Jim and All,
>> 
>> The 1st FreeDOS interim test build is up and available for download at:
>> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
>> 
>> :-)
>> 
>> Jerome
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Jim and All,

The 1st FreeDOS interim test build is up and available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


:-)

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

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

[Jerome Shidel]

Hi,

> On Jul 31, 2022, at 5:46 AM, tom ehlert  wrote:
> 
> 
>> interesting find. did you try any of the alternatives DRVLOAD, DEVLOD,
>> DDL ...
> 
> a compilation of devload, drvload, loadsys
> http://toogam.com/software/archive/drivers/dosstart/dosstart.zip
> 
> Tom

Ok, this is interesting….

I tried a couple loaders in the zip (reboot between tries).

DEVLOAD, either version, failed.
DRVLOAD, failed.
LOADSYS, failed.

CTLOAD, passed and ANSI detected. 

So, the issue is most likely with DEVLOAD. 
Possibly, something it is doing or neglecting to do. 

:-)

Jerome

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

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

[Jerome Shidel]

Hi,

> On Jul 31, 2022, at 3:49 AM, TK Chia  wrote:
> 
> Hello Jerome,
> 
>>> Generally, I would not include an attachment. However, this is a
>>> tiny zip and includes the test source, build scripts and the compiled 
>>> version.
> 
> Well... I found that your ansitest.com still works with the FreeDOS 1.3
> kernel + nansi.sys 4.0d.  (I.e. there was no regression between FreeDOS
> 1.0 and 1.3.)
> 
> I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it
> so that it loads nansi.sys on startup and does not start the installer,
> then ran it under QEMU.  ansitest.com says "ANSI supported".
> 
> (I will try to enclose a floppy disk image once I manage to pare it down
> to a small enough size...)
> 
> Are you using devload.com to load the nansi.sys driver?  If so, this
> might explain the failure.  I found that if I use devload.com --- rather
> than load the driver through fdconfig.sys --- then for some reason
> nansi.sys's input handling routines are not triggered, and there is no
> ESC [ y ; x R response.  This would mean there is an issue in devload.com.

I did not see your message until now. However, it did not take long to narrow 
down.

I did some testing under VirtualBox and it didn’t take long to when the issue 
occurs.

I saw almost immediately that when booting with NANSI.SYS in the config 
file the test passes successfully. However, post boot loading using DEVLOAD 
(high or low) would cause the test to fail detection.

This is occurs even when nothing other than the SHELL= is in the config with an 
empty 
autoexec. 

So, my test results match yours and it is easy to replicate.

Finding the actually issue may be a little more complicated.

I’m suspecting the issue may not be NANSI itself. 

:-)

Jerome



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

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

[Jerome Shidel]

Hi again,

> On Jul 30, 2022, at 4:51 PM, Jerome Shidel  wrote:
> 
> Hi,
> 
>> On Jul 30, 2022, at 3:03 PM, TK Chia  wrote:

I just created a boot floppy with 1.3’s Kernel, Command, NANSI and the Test 
program. 

Loaded Command and NANSI to low memory with nothing else in the CONFIG.SYS and 
nothing in an AUTOEXEC.BAT.

Booted the Pentium Pro and ran the test.

Result: Ansi supported.

So, this will take some CONFIG testing to find out what is breaking MS-DOS 
compatibility. 

:-)

Jerome

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