Re: [Freedos-devel] zoo

[Jerome Shidel via Freedos-devel]

Hi Tom,

> On May 23, 2024, at 2:04 PM, tom ehlert via Freedos-devel 
>  wrote:
> 
> Hi Wilhelm ,
> [..]
>> But I got the feedback from Jerome  to ask the FD mailing list first as it 
>> is not possible to remove it if only one person  
>> asks for removing. So I did this.   
> 
> So Jerome is now suddenly the official rule maker for FreeDOS? I don't 
> remember dicussing this.

I do not make rules regarding FreeDOS.

I did not say “it is not possible to remove something if only one person 
requests it”

In the past, there have been many off list requests made to Jim and me for the 
addition, removal or replacement of packages that are included with the OS. 
Such changes should be discussed publicly on this mailing list and not in 
private. 

It is not any sort of rule which I made. However, I completely agree that is 
the proper course of action regarding included packages. 

So when I’m asked “off-list” about such changes, I simply reply that it needs 
to be discussed here by the FreeDOS community before any changes such changes 
are made.

Personally, I have very few opinions on the addition or removal of specific 
packages. I do know that users tend to get upset when something is removed that 
they use. 

At present, we provide many programs that are probably not used by end users. 
However, I think there are a sufficient number of users that benefit from 
having at least some of those packages easily available for installation to 
warrant their inclusion. It can be difficult for an inexperienced user to 
locate some of those programs. It can also be difficult for them to get the 
software onto their computer or into their virtual machine. But, that is simply 
a convenience we provide.

As for zoo in particular, it is small and included on the larger installation 
media. However, it is not installed automatically with either BASE or FULL. It 
is simply on the media as a convenience for those who may need it. 

Jerome






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

Re: [Freedos-devel] still can't find the source code

[Jerome Shidel via Freedos-devel]

On 5/10/24 09:45, Green Fog via Freedos-devel wrote:
There you go. The 2 requirements for free dos being a thing are just 
not there. not ease of use. I need to use an antique mail list for 
communication and wiki/documentation. It's absurd and very not 
efficient. I am very busy, and I can't afford the time to download 
each of these packages one by one. That is not how the source code 
should be distributed.


That statement is funny. on several levels.

FreeDOS is a combination of multiple programs by different authors. Not 
a single program.


Each are their own project. But we mirror all the ones we provide with 
FreeDOS on GitLab for convenience.


The SOURCES are included with the RELEASE. Download the OS and you have 
the SOURCES.


No need to download hundreds of separate packages.

Why would anyone want to want to "check out" all of those sources?

You probably would spend several lifetimes just trying to understand all 
that source code.


Ease of use is none. Documentations are very bad. The sites linked to 
are web 0.1 material. Good documentation and know-hows are what drive 
further development, so I can say free dos is dead, and I will not 
invest more time on it.


No documentation is every good enough.

Recently, I spent several days trying to figure out how to make the 
pin-head sized icons in the FireFox GUI larger on my 4k monitor under 
Linux. You'd think I could not be the only person with that problem. But 
it took me days to get the problem resolved. And I've been using Linux 
for decades!




Calling me a troll and telling me not to talk to me? How old are you? 
That is not very welcoming and very immature. Either way, I am gone.


You start off aggressive, condescending and belligerent.  When help is 
attempted, you spend little to no effort of your own to investigate the 
advice.


Bye. I won't miss 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] still can't find the source code

[Jerome Shidel via Freedos-devel]

> On May 8, 2024, at 5:50 AM, Green Fog via Freedos-devel 
>  wrote:
> 
> I can see the potential of Freedos if these 2 conditions are met:
> 
> 1, ease of use. Absolutely both for users and developers. Or else who is 
> going to use it? or develop more fun and useful applications to it. So that 
> means better documentation, easier access to not only the source code but 
> also the known-hows on everything. I am able to find some source code from 
> github, which only consists of 3.7MB. I am not sure how that translates into 
> a 400MB ISO. I can't find any developer section. Are we in the matrix?

On the FreeDOS website there was an other button. But to save you the time:

https://gitlab.com/FreeDOS

> 
> 2, Better documentation. The site has a wiki section that is not part of the 
> site, and is very inadequate. The official site absolutely needs to provide 
> more information on many aspects including the full source code if it's 
> available. 
> ___
> 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] still can't find the source code

[Jerome Shidel via Freedos-devel]



> On May 8, 2024, at 5:50 AM, Green Fog via Freedos-devel 
>  wrote:
> 
> I can see the potential of Freedos if these 2 conditions are met:
> 
> 1, ease of use. Absolutely both for users and developers. Or else who is 
> going to use it? or develop more fun and useful applications to it. So that 
> means better documentation, easier access to not only the source code but 
> also the known-hows on everything. I am able to find some source code from 
> github, which only consists of 3.7MB. I am not sure how that translates into 
> a 400MB ISO. I can't find any developer section. Are we in the matrix?

On the FreeDOS website there was an other button. But to save you the time:

https://gitlab.com/FreeDOS

> 
> 2, Better documentation. The site has a wiki section that is not part of the 
> site, and is very inadequate. The official site absolutely needs to provide 
> more information on many aspects including the full source code if it's 
> available.
> ___
> 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] A FreeCOM+DOSBox bug

[Jerome Shidel via Freedos-devel]

A little more follow-up.

First, I should be a little clearer. This is FreeDOS installed in hybrid 
mode inside of DOSBox. This is where the all of the utilities provided 
with FreeDOS are available and the FreeCOM shell is being used on top of 
the DOSBox kernel. This allows for all the additional benefits of 
FreeCOM will still having easy access to the HOST file system. The 
hybrid install is something the FreeDOS installer has been capable of 
since FreeDOS 1.2.


I just noticed that if you are quick enough (or slow DOSBox way down), 
pressing a key while doing a short directory listing (one that does not 
pause), causes the  FreeCOM shell to terminate as well.


So, IDK.


On 5/4/24 03:05, Jerome Shidel via Freedos-devel wrote:


Hi all,

I do a lot of my programming under DOSBox running the FreeCOM shell. 
This provides me with the most convenient development process.


However on occasion, FreeCOM would terminate and the simplest thing to 
do to get things back to normal would be restart DOSBox.


This is not a new issue. It's been happening for years.

Sometimes there would be some sort of error message. Most often no 
message.


I had no idea why this would happen. I just lived with the occasional 
nuisance.


Until now.

I figured out what causes that to happen. And it is creditably easy to 
reproduce with an 11 byte program.


Fire up DOSBox, run FreeCOM, compile and execute this NASM source:

    use16              ; 16-bit code cpu 8086       ; 8086 
compatible org 0x100          ; COM file
WaitForKey: ; Label for wait loop mov ah,0x01        ; Check for 
keystroke function int 0x16           ; call the BIOS function jz  
WaitForKey ; if Zero Flag, then no keystroke, repeat
mov ax, 0x4c00 ; function to exit to dos, with no error int 
0x21       ; call the DOS function



For those familiar with assembly, you can see it is very simple. The 
program just waits for a key to be pressed. Then terminates leaving 
the keystroke in the buffer.


Nothing odd or fancy.

But, leaving a keystroke in the buffer will cause the FreeCOM shell to 
terminate under DOSBox.


This can happen in any program when there is a delay in termination 
after the last keystroke was pulled from the buffer.


It was happening to me because I sometimes start typing before a build 
script (batch file) would completely finish.


I suspect it is not a bug in FreeCOM. But, it is  more likely a bug in 
DOSBox.


I have not seen it happen when running "Pure" FreeDOS inside a Virtual 
Machine or on real hardware.


I have seen it happen under several versions of DOSBox and DOSBox 
Staging with both Mac and Linux Hosts.


But, that's just a guess. The bug could be in either.

After all, running the test program again after FreeCOM shuts down, 
the key just shows up on the command line like it should.


So, IDK.

Unfortunately, I don't have the time to dive into it further.

:-)

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] A FreeCOM+DOSBox bug

[Jerome Shidel via Freedos-devel]

Hi all,

I do a lot of my programming under DOSBox running the FreeCOM shell. 
This provides me with the most convenient development process.


However on occasion, FreeCOM would terminate and the simplest thing to 
do to get things back to normal would be restart DOSBox.


This is not a new issue. It's been happening for years.

Sometimes there would be some sort of error message. Most often no message.

I had no idea why this would happen. I just lived with the occasional 
nuisance.


Until now.

I figured out what causes that to happen. And it is creditably easy to 
reproduce with an 11 byte program.


Fire up DOSBox, run FreeCOM, compile and execute this NASM source:

    use16              ; 16-bit code cpu 8086       ; 8086 
compatible org 0x100          ; COM file


WaitForKey: ; Label for wait loop mov ah,0x01        ; Check for 
keystroke function int 0x16           ; call the BIOS function jz  
WaitForKey ; if Zero Flag, then no keystroke, repeat


mov ax, 0x4c00 ; function to exit to dos, with no error int 0x21    
   ; call the DOS function



For those familiar with assembly, you can see it is very simple. The 
program just waits for a key to be pressed. Then terminates leaving the 
keystroke in the buffer.


Nothing odd or fancy.

But, leaving a keystroke in the buffer will cause the FreeCOM shell to 
terminate under DOSBox.


This can happen in any program when there is a delay in termination 
after the last keystroke was pulled from the buffer.


It was happening to me because I sometimes start typing before a build 
script (batch file) would completely finish.


I suspect it is not a bug in FreeCOM. But, it is  more likely a bug in 
DOSBox.


I have not seen it happen when running "Pure" FreeDOS inside a Virtual 
Machine or on real hardware.


I have seen it happen under several versions of DOSBox and DOSBox 
Staging with both Mac and Linux Hosts.


But, that's just a guess. The bug could be in either.

After all, running the test program again after FreeCOM shuts down, the 
key just shows up on the command line like it should.


So, IDK.

Unfortunately, I don't have the time to dive into it further.

:-)

Jerome



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

Re: [Freedos-devel] FreeDOS Interim Build T2405

[Jerome Shidel via Freedos-devel]

Hi Willi,On May 1, 2024, at 10:20 AM, Wilhelm Spiegl via Freedos-devel  wrote:Hi Jerome, thanks for this statement.

 

I know that you are very very busy, and it is not really urgent, but it would be nice to keep it in mind.

 

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/apps/ - and there: doszip.zip

or:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel - and there dojs.zip

 

are not up to date, which leads to the result that it is not possible to download the latest versions via fdnpkg update.

 

Willi
They’ll be updated either later today or tomorrow at those location.I wasn’t able to make time to update the packages for T2405 until last night. Basically what happens is this…I update the packages at the GitLab FreeDOS archive.  Which performs a bunch of validation and such things. It also wraps them up into a package. This is where the RBE (release build environment) fetch’s the packages for the Interim and Release builds.Then I download the FreeDOS compatible package from GitLab.Then I upload them to my server at http://fd.lod.bz and the repository management tools make some adjustments to the metadata. My server checks for such updates hourly.Then I download that from my server and upload it ibiblio. The repo management tools also are running there. However, they will see the adjustments to the metadata have already been made and just update its web pages. Ibiblio only checks automatically once per day for updates.Unfortunately, the underlying utilities that get used to update the metadata can very slightly between the 2 servers. That can result in different hashes for the packages. Since the repo management software on both servers is the same. The order of upload to those servers is not important. It’s just easier to update ibiblio last. Especially since there can be multiple copies of the packages in the different OS version repositories on that server.Anyhow, those are already on GitLab and my server. Just waiting for me to download them and upload copies to ibiblio. I will be away from a computer for most of the day today. (Sending this from a phone). But, I should get to that at some point before tomorrow.:-)Jerome 

Sent: Wednesday, May 01, 2024 at 12:12 PM
From: "Jerome Shidel via Freedos-devel" 
To: "FreeDOS Developers" 
Cc: jer...@shidel.net
Subject: [Freedos-devel] FreeDOS Interim Build T2405



The FreeDOS Interim Test Build T2405 for May is now available for download at:

 

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

 

A special thanks to Wilhelm for pointing out most of the updates and providing links for me to download.

 

I’ve been very time constrained of late. Without his support, the only updated program in this Build would have been NASM. He also provided information and links regarding several other items. However, I should follow up on that in a different post. 

 

Thanks again Willi for the time and effort you put into searching for updates. It is a big help. :-)

 

 

Overview of changes in this Interim Build:

 


2024-04-30 21:54:27 suppls (shidel): relocated developer files from source to devel

2024-04-30 21:39:55 dojs (shidel): updated to v1.12.1 (The puny port)

2024-04-30 21:36:21 doszip (shidel): updated to v2.66

2024-04-30 21:32:30 testdisk (shidel): updated to v7.2 (final)

2024-04-30 21:27:47 fasm (shidel): updated to v1.73.32

2024-04-30 21:22:13 nasm (shidel): updated to v2.16.03

2024-04-13 07:11:10 nasm (shidel): updated to version 2.16.02

2024-04-04 20:33:02 project_FD-NLS (cardpuncher): Add files via upload

2024-04-04 16:14:11 project_FD-NLS (shidel): report update

2024-04-04 15:19:11 project_FD-NLS (shidel): Merge pull request #191 from cardpuncher/master

2024-04-03 20:02:23 project_FD-NLS (shidel): report update

2024-04-03 19:18:04 project_FD-NLS (shidel): Merge branch 'master' of github.com:shidel/fd-nls

2024-04-03 18:46:51 project_FD-NLS (shidel): FDNET DOSBox Staging Strings

2024-04-03 15:03:49 project_FD-NLS (shidel): Merge pull request #190 from cardpuncher/master

2024-04-03 15:02:20 fdnet [unstable] (shidel): DOSBox Staging networking support

2024-04-03 14:40:43 project_FDI [unstable] (shidel): DOSBox Hybrid install, FDAUTO path typo fix


 

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





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

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2405 for May is now available for download at:

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


A special thanks to Wilhelm for pointing out most of the updates and providing 
links for me to download.

I’ve been very time constrained of late. Without his support, the only updated 
program in this Build would have been NASM. He also provided information and 
links regarding several other items. However, I should follow up on that in a 
different post. 

Thanks again Willi for the time and effort you put into searching for updates. 
It is a big help. :-)


Overview of changes in this Interim Build:

2024-04-30 21:54:27 suppls (shidel): relocated developer files from source to 
devel
2024-04-30 21:39:55 dojs (shidel): updated to v1.12.1 (The puny port)
2024-04-30 21:36:21 doszip (shidel): updated to v2.66
2024-04-30 21:32:30 testdisk (shidel): updated to v7.2 (final)
2024-04-30 21:27:47 fasm (shidel): updated to v1.73.32
2024-04-30 21:22:13 nasm (shidel): updated to v2.16.03
2024-04-13 07:11:10 nasm (shidel): updated to version 2.16.02
2024-04-04 20:33:02 project_FD-NLS (cardpuncher): Add files via upload
2024-04-04 16:14:11 project_FD-NLS (shidel): report update
2024-04-04 15:19:11 project_FD-NLS (shidel): Merge pull request #191 from 
cardpuncher/master
2024-04-03 20:02:23 project_FD-NLS (shidel): report update
2024-04-03 19:18:04 project_FD-NLS (shidel): Merge branch 'master' of 
github.com:shidel/fd-nls
2024-04-03 18:46:51 project_FD-NLS (shidel): FDNET DOSBox Staging Strings
2024-04-03 15:03:49 project_FD-NLS (shidel): Merge pull request #190 from 
cardpuncher/master
2024-04-03 15:02:20 fdnet [unstable] (shidel): DOSBox Staging networking support
2024-04-03 14:40:43 project_FDI [unstable] (shidel): DOSBox Hybrid install, 
FDAUTO path typo fix

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

[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]

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 note, the message the displays “CD-ROM configured as ?: drive (FDCDX001)” 
is
performed by calling "CDROM.BAT status” which is not present here. Also, when 
the 
system does not configure a CD drive (either by boot option omission, or 
initialization
failure), it displays “CD-ROM not configured"

if not exist %DOSDIR%\BIN\CDROM.BAT goto NOCDSTATUS
call %DOSDIR%\BIN\CDROM.BAT status
:NOCDSTATUS

>> if not exist %DOSDIR%\BIN\WELCOME.BAT goto NOHELLO
>> call %DOSDIR%\BIN\WELCOME.BAT
>> :NOHELLO
>> 
>> MEM /C /N

I think this should not appear after Welcome to FreeDOS, type Help, etc.

>> 
>> REM - local settings
>> 
>> set BLASTER=A220 I5 D1 H5 P330
>> set DIRCMD=/O:GNE /Y
>> set COPYCMD=/-Y
>> 
>> REM nlsfunc %DOSDIR%\BIN\COUNTRY.SYS
>> REM display CON=(EGA,858,2)
>> REM mode CON CP PREP=((858) %DOSDIR%\CPI\EGA.CPX)
>> REM keyb US,858,%DOSDIR%\BIN\KEYBOARD.SYS
>> REM chcp 858
>> REM mkeyb UK

Not sure about the local stuff being loaded after the welcome messages. 

Personally, I feel that the very last text presented to the user should be
the Cd-Drive letter and the Welcome, help and done processing messages.
But, maybe thats just me. 

Also, I just realized there are no LANG or TZ settings. There are a couple 
programs
that complain when TZ is not set. But, really need the LANG setting and very 
early in the
config. 

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

I personally never use the cfgfile or autofile variables or the cfg/auto 
aliases. 

But, using the AUTOFILE=%0 will solve the user file renaming.

Changing there "set CFGFILE" to:

REM 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

should be sufficient to handle renaming of that file as well.

> 
> Jim
> 

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 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/ 
<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 
> <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 
> <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 
> <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 
<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 
<https://github.com/shidel/FDI/tree/master/SETTINGS>
(or, the unstable branch if it exists)
https://github.com/shidel/FDI/tree/unstable/SETTINGS 
<https://github.com/shidel/FDI/tree/unstable/SETTINGS>

Floppy Edition Settings:
https://github.com/shidel/FDI-x86/tree/master/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 
<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 
<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 
<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-dev

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/ 
>> <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/ 
<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/ 
<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/ 
<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] format \s

[jerome]

Hi, 

> On Jun 24, 2023, at 9:50 AM, Patrick McCavery  wrote:
> 
> Hi Everyone
> 
> Thanks very much for all the excellent posts here.
> 
> I am a little mixed up. One message seems to say that format /s will write 
> solely to the boot sector while another says it won't.
> 
> I am being a bit lazy, I am using gparted under Slackware Linux. I formatted 
> to Fat32. I ran qemu with -hda freedos.img -hdb /dev/sdc
> 
> freedos did not like the way that gparted formatted it so it reformatted it. 
> It copied over files. I was able to boot the usb device under qemu, FreeDos 
> came up just fine.
> 
> gparted says that that almost 15Mb are used on the USB key. du command says 0.
> 
> I would like to dd the minimal image of FreeDOS. If I write this to disk, and 
> copy over, fdconfig.sys, command.com, an exe and an autoexec.bat that calls 
> it, I think things should be good. Am I missing anything? Is it only a 
> minimal pre-kernel in the boot sector? Do I also need to copy over the kernel?
> 
> I work with scientific instruments. Surely, as per your industry, there are 
> too many people trying to sell "new and improved" items. There are people 
> selling new scientific instruments that are hardly better than the old ones 
> and in many cases are worse. Lots of people have old computers with ISA cards 
> lying around that could control their old instruments but they don't have the 
> software to run nor the staff to write software for it.
> 
> So the requirements are soft real time, astronauts will not suffocate etc :)
> 
> Thanks again to all-Pat

As for creating a bootable DOS image, you could settle for the same method used 
by the RBE. The RBE (Release Build Environment) is a fully automated linux 
system that uses some fairly complicated scripting to pull various components 
from the internet, modify them and generate a FreeDOS Release or the Interim 
Build media. Simply run “make” and return an while later to retrieve all the 
various release files.

The RBE creates bootable media of various sizes and media types. When it comes 
to creating the Floppy or Hard Disk images, the process more or less works like 
this:

Included with the RBE is a tiny compressed floppy image (a Bootstrap image). 
The floppy image contains a boot sector. The RBE copies over other items like 
the Kernel, FreeCom, other utilities and a job runner batch file. It then 
executes QEMU booting the updated floppy with the new disk image also attached. 
The QEMU instance partitions the drive, reboots, formats the filesystem, then 
transfers the system files to the new disk image and shuts down. The New disk 
image is now bootable.

Since you only need a bootable disk image, you could perform a similar task in 
a much less complicated way. You could create a bootstrap floppy image that 
contains all the tools needed to perform the partition, reboot, format and 
system transfer files. Then when you deploy a build. A script could generate 
the new disk image, use DOS under QEMU to perform the tasks needed to make it 
bootable, then copy the program over and boot the new image. 

So when you compile and deploy the program, it could call a script that looked 
something like…

# create hard disk image
qemu-img create -f raw DOSDISK.IMG 15M || exit $?

# boot bootstrap image to partition, format and transfer system files.
qemu-system-i386 -display none -m 16M -drive 
file=bootstrap.img,media=disk,index=0,if=floppy,format=raw -drive 
file=DOSDISK.IMG,media=disk,format=raw -boot a

# mount disk image
# copy executable files to DOSDISK.IMG
# unmount disk image
# boot DOSDISK.IMG for testing compiled executables

Or to simplify things even more, you could just keep one or more various 
“ready-to-go” disk images of the size(s) needed compressed, then expand a fresh 
copy when deployed. Like…

# Pick an appropriate image size
if [[ ${needed} -gt 16 ]] ; then
img=DOS32MB.tar.gz
elif [[ ${needed} -gt 8 ]] ; then
img=DOS16MB.tar.gz
else
img=DOS8MB.tar.gz
fi

# extract a ready to go copy of DOSDISK.IMG from an archive
tar -xzf ${img}

# mount disk image
# copy executable files to DOSDISK.IMG
# unmount disk image
# boot DOSDISK.IMG for testing compiled executables

Of course, there are other ways to handle all of this. 

For example, you most likely could just use one single larger pre-made image. 
After all, 64Mb is not a lot of disk space and would be an enormous DOS program.

Personally, I think you should just go with a single larger compressed "ready 
to go” image and not worry about it much.

:-)

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 June 18

[jerome]

Hmmm, that will be a little later today. :-)

> On Jun 4, 2023, at 4:15 PM, Jim Hall  wrote:
> 
> Hi everyone!
> 
> I wanted to share a reminder that our next FreeDOS virtual
> get-together is coming up on Sunday, June 18, 2023 at 11am US/Central.
> That's two weeks from today.
> 
> We alternate topics every time. This month's focus is "social time."
> We'll probably cover technical topics too, but this is mostly a time
> for folks to get to know each other as more than just an email
> address.
> 
> As always, we'll do the meeting via BlueJeans (I use this for remote
> meetings in my consulting practice). I'll share the meeting URL
> shortly before the meeting starts. I'll also share it on the website,
> on Facebook, and on Mastodon.
> 
> 
> ___
> 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] VTEST

[jerome]

Hi All, 

The latest version of V8Power Tools for DOS is now available. 

It includes the new VTEST beta for general testing.

It can be downloaded at https://up.lod.bz/v8power <https://up.lod.bz/v8power> 
or https://fd.lod.bz/repos/current/pkg-html/v8power.html 
<https://fd.lod.bz/repos/current/pkg-html/v8power.html>

Some general information on usage:

VTEST exists with one of 3 exit codes, 0=TRUE, 1=FALSE, 100=Syntax or invalid 
option error. 

By default, only error messages are displayed.

There is a /tf option than can be placed anywhere on the command line to 
display the final result of TRUE, FALSE or ERROR.

When comparing any two strings, it will attempt to compare them numerically by 
default (supporting signed 64-bit integers in decimal or hexadecimal). For 
example 123 is less than 0456. If either of the strings is not a valid number, 
they will be compared as non-case specific text. You can force the strings  to 
be compared as text by using either /i (case-less) or /c (case-specific) at the 
start of an expression. Examples:

C:>VTEST /tf 123 /gt 0456
FALSE
C:>VTEST /tf 0x1234 /gt -456
TRUE
C:>VTEST /tf 0x1234 /lt 1234
FALSE
C:>VTEST /tf /i 123 /gt 0456
TRUE
C:>VTEST /tf abc /eq ABC
TRUE
C:>VTEST /tf /c abc /eq ABC
FALSE

Quotations for strings is not used or required. Quotation characters are 
treated as string text. Also, leading and trailing whitespace in strings is 
ignored. (however, at least one space is required after an option)

C:>VTEST /tf a b c /eq A B C
TRUE
C:>VTEST /tf a bc /eq A B C
FALSE
C:>VTEST /tf abc/eqABC
TRUE
The / character must be escaped in strings by using //.

C:>VTEST /tf Y//N
TRUE
C:>VTEST /tf a/b
Invalid option “/b”.
ERROR
(That is because no operand (like /GT or /AND is between “Y” and “/N”)

Missing strings are interpreted as NULL strings.

C:>VTEST /tf /lt hello
TRUE
C:>VTEST /tf /gt hello
FALSE
C:>VTEST /tf 1 /gt
TRUE
C:>VTEST /tf 1 /lt
FALSE
C:>VTEST /eq/tf
TRUE
C:>VTEST /tf /ne
FALSE

Comparisons are made from left to right and can be strung in a sequence.

C:>VTEST /tf 3 /lt 5 /gt 2
TRUE
(That would be like “3 < 5” then “5 > 2")


Test expressions can be chained using /AND or /OR

C:>VTEST /tf 3 /lt 5 /and B /gt a
TRUE
(That would be like “3 < 5” and case-less “B > A")


Entire expressions can be negated using /NOT.

C:>VTEST /tf /not 3 /lt 5 /gt 2 /or /not /c B /gt a
TRUE
(That would be like "NOT (3 < 5 > 2 = TRUE) = FALSE”  or "NOT (case specific, B 
> a = FALSE) = TRUE")


When a filesystem test is made using /f (file), /d (directory) or /e (exists), 
the item string is replaced by the on disk value. For example assume file 
“Hello program 1.h" exists:

C:>VTEST /tf /f hello program 1.h
TRUE
C:>VTEST /tf /c /f hello program 1.h
FALSE
C:>VTEST /tf /f Hello program 1.h /eq hello program 1.h
TRUE
C:>VTEST /c /tf /f Hello program 1.h /eq hello program 1.h
FALSE
C:>VTEST /c /tf /f Hello program 1.h /or /f HELLO-1.H
TRUE

Wildcards can be used with file system items.

C:>VTEST /tf /d C:\FREEDOS
TRUE
C:>VTEST /tf /f C:\FREEDOS\BIN\*.*
TRUE

The Exists option (/e) is a little different from /f and /d. It can be used to 
test for any type directory entry, including system volume labels.

C:>VTEST /tf /e C:\FREEDOS2.012
TRUE

Known Limitations regarding the filesystem related tests:

The /f, /d and /e options are only permitted at the beginning of an expression 
at present. A little extra overhead would be required to permit things like 
“VTEST hello /eq /f HELLO” and I haven’t decided if that is worth the effort.

It may be useful to add tests for date/time stamps and size.

It may be useful to add some drive type tests. Like is removable media, cd-rom, 
floppy, etc.

The /f and /d options to not care if a file is system or hidden. Perhaps tests 
for those will be added at some point.

At present where wildcards are used, only the first matching filesystem item is 
compared from the unsorted directory. It may be useful to test all matching 
directory items.  Making it possible to compare against all files/dirs. For 
example, any file is older than DT. Or, possibly File A is older than File B, 
etc. However, not sure how much use it would be. Maybe later.

On a single floppy system, running “VTEST /d a:\ /and /d b:\” will cause DOS to 
prompt for a disk swap. I have not decided if this “is worth the effort” or 
"even should be” prevented. 

Anyhow, it is available now. Have fun testing it. 

:-)

Jerome



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

Re: [Freedos-devel] EXIST NUL

[jerome]

> On Jun 13, 2023, at 4:02 PM, Jim Hall  wrote:
> 
> On Mon, Jun 12, 2023 at 4:05 PM Bret Johnson  wrote:
>> 
>> Rather than merely trying to copy the way MS did/does things regarding
>> IF EXIST X:NUL, I think we can discuss what the "right" way to handle
>> things should be.
> 
> We should still fix the FreeDOS behavior to match the MS-DOS behavior.

Issue #2 is simply a bug.

Issue #1 is a little different. Although Issue #1 matches the behavior of 
MS-DOS, it 
can be assumed to be a bug as well. Even Microsoft changed this to be 
consistent 
in Windows Command Shell at some point. 

> But if we're going to talk about the "right" way to do things, what
> about a new, separate "test" command to evaluate things?
> 
> I'm using Unix and Linux as a model, but not suggesting we emulate
> completely the features of Unix. But the Unix 'test' tool does some
> neat things. My suggestions for a "test" like command:
> 
> TEST /F file
> Returns errorlevel zero if the file exists, nonzero if not. This is like 
> doing:
> IF EXIST d:\path\file [..]
> ..but it puts the test on a separate line in the batch file, and you
> use the errorlevel afterwards to do your condition.
> 
> TEST /D dir
> Returns errorlevel zero if the dir exists, nonzero if not. This is like doing:
> IF EXIST d:\path\NUL [..]
> ..but it can be made more reliable.
> 
> 
> I think string tests are also useful:
> 
> 
> TEST /Z str
> Returns zero if the str is empty, nonzero if not. This is like doing:
> IF z%VAR%==z [..]
> ..but it makes the test more obvious.
> 
> TEST /S str
> Returns zero if the str is not empty, nonzero if empty. This is the
> opposite of "TEST /z str"
> 
> 
> Number value comparisons can also be a handy thing for some batch files:
> 
> 
> TEST /n n1 comp n2
> Test various comparisons on numbers. My nature is to use Fortran-like
> comparisons here, like:
> 
> TEST /n a LT b
> TEST /n a LE b
> Returns errorlevel zero if "a" is less than "b" (for LE, "less than or
> equal") nonzero if not
> 
> TEST /n a GT b
> TEST /n a GE b
> Returns errorlevel zero if "a" is greater than "b" (for GE, "greater
> than or equal") nonzero if not
> 
> TEST /n a EQ b
> Returns errorlevel zero if "a" is equal to "b", nonzero if not
> 
> TEST /n a NE b
> Returns errorlevel zero if "a" is not equal to "b", nonzero if not

I was going to wait until it was completely finished. But, there is no
harm in announcing it now.

I have already written a utility that does this and much more. It is part of 
V8Power Tools for DOS and called VTEST. It weighs in at under 3Kb. 
Because like all the programs in V8PT, it is written in assembly. 

It is capable of things like:

vtest 1234567890123 /gt -56789012345 
vtest /not hello /eq goodbye /and /d c:\ /and /not /f readme.txt
vtest 1 /lt 2 /lt 5 /gt 3 /and /not /c hello my friend /gt Goodbye /or /v 15
vtest  /f 00*.* /lt 005.txt 
vtest /not /f This text document.doc /and /not /f That text document.doc

It 64-bit numbers, long file names and even both case-specific and case-less 
string comparisons. 

All that is working great and it will be available for general testing sometime 
over the next few days. If I can spare a few minutes, possibly tomorrow.

If you are interested, the help text for VTEST can be viewed at:

https://github.com/shidel/fd-nls/blob/master/v8power/help/en/vtest.en 
<https://github.com/shidel/fd-nls/blob/master/v8power/help/en/vtest.en>

Source is at:

https://github.com/LoopZ/V8Power/blob/master/SOURCE/VTEST.ASM 
<https://github.com/LoopZ/V8Power/blob/master/SOURCE/VTEST.ASM>

Binary will be available soon.


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 & LOGGER

[jerome]

Hi All,

Logger version 1.00 was released several weeks ago. That should have been 
sufficient time those who are interested in it to have a chance to try it out. 
I feel it is now time to pose a few questions and get your opinions on a couple 
things.

Should a package for LOGGER be included on the FreeDOS release media?
If so, should LOGGER be installed with FULL or BASE? Or, possibly just 
available as an EXTRA? (However, I assume it should not automatically be 
started on an installed system. Possibly, having a REM’ed line in the 
FDCONFIG.SYS file.)
Should LOGGER be included and possibly started automatically when booting the 
FreeDOS USB or CD release media?
If so, I assume integrating logging into the FreeDOS installer would be desired.

Once again, there is a boot floppy that can be used with either the FreeDOS 1.3 
Live CD or any of the interim builds. That boot floppy brings up a Live 
Environment that has LOGGER running. The example floppy can be retrieved from 
https://fd.lod.bz/redist/system/ <https://fd.lod.bz/redist/system/>

Jerome


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

Re: [Freedos-devel] FreeDOS T2306

[jerome]

Hi Willi,

> On Jun 5, 2023, at 10:06 AM, Wilhelm Spiegl  wrote:
> [..] 
> b) I had the hope that the english test version of help 1.1.0 would be in 
> FDT2306 for testing, but nothing happened. I had informed Andy Stamp before 
> too. So what can I do  that this version english version comes into one of 
> the next FDT versions to see if everything works fine? And to ask the group 
> which commands should be added / removed?

I did receive the latest HTMLHELP text files you sent a few days back.  

Those have been added to FD-NLS at 
https://github.com/shidel/fd-nls/tree/master/htmlhelp/v1.1.0 
<https://github.com/shidel/fd-nls/tree/master/htmlhelp/v1.1.0> . 

However, those files have not yet been integrated into the HTMLHELP package at 
https://gitlab.com/FreeDOS/base/htmlhelp 
<https://gitlab.com/FreeDOS/base/htmlhelp> . 

Therefore, the updated files were not included in T2306. Since no one has 
updated the GitLab package, it is waiting for me to do it. 

Unfortunately, do mostly to financial reasons and the lack of sufficient 
community support threw means like my Patreon page, the amount of time I can 
dedicate to working on FreeDOS and related items has been dramatically 
curtailed. Of the very limited amount of time remaining, I must prioritize even 
the smallest of tasks. For the most part, that means I can only allocate time 
to nibble away at one problem or project at a time. It is also the reason for 
the increased response time regarding email.

At present, my “FreeDOS time” is dedicated to creating a new command-line 
utility that will be included with V8Power Tools for DOS. When that is 
finished, I will be working on assisting another FreeDOS developer run down a 
file truncation issue that is occurring under FreeDOS EDIT in specific 
circumstances. Following that, I will integrate the new HTMLHELP text into the 
GitLab Package before looking in to the visual glitch that sometimes occurs in 
the FreeDOS installer when using the new FDISK. Hopefully, that integration 
will be before T2307 is released.

Once those items are knocked out, almost everything related to FreeDOS will be 
going into maintenance only mode. At that point, only bug fixes and general 
FreeDOS package updates will get allocated time. The exceptions being V8Turbo 
and the FD-NLS desktop application. However, based on the amount of time I can 
dedicate to working on FreeDOS related items, It will be a while for V8Turbo 
and I may not get back to the FD-NLS app for a year or more. As for things like 
the next version of FDIMPLES with mouse and networking support, a couple games 
and other new programs I was going to create, those have been put off 
indefinitely. 

It is unfortunate. But, it is what it is. 

Jerome


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

Re: [Freedos-devel] EXIST NUL

[jerome]

Hi Ralf,

To further prove Issue #1 is a bug under both the current version of FreeDOS 
and last version of MS-DOS (6.22),

I booted up a Windows 10 machine and opened a command shell window. 

On that machine, drive Z: is a CDROM (with disk inserted) and drive T: does not 
exist. 

C:>if exist C:\NUL echo yes
yes
C:>if exist T:\NUL echo yes
C:>if exist Z:\NUL echo yes
yes
C:>

Although the Windows 10 command shell is not DOS, Microsoft did correct this 
behavior at a later point for batch processing.

:-)

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

Re: [Freedos-devel] EXIST NUL

[jerome]

Hi Ralf, 

> On Jun 5, 2023, at 5:06 PM, Ralf Quint  wrote:
> 
> On 6/5/2023 1:56 AM, jer...@shidel.net <mailto:jer...@shidel.net> wrote:
>> Hi All,
>> 
>> There are two separate issues when using:  IF EXIST ?:\NUL 
>> 
>> I'm lazy and wrote up a info text file over at 
>> https://fd.lod.bz/redist/testing/devNUL/ 
>> <https://fd.lod.bz/redist/testing/devNUL/> and 
>> 
>> bug report at https://github.com/FDOS/freecom 
>> <https://github.com/FDOS/freecom> that I will just copy/paste here. 
>> 
>> Additional testing would be required to determine the cause of these 
>> problems. Since 
>> the same problem exists for Issue #1 under MS-DOS, an argument could be made 
>> to 
>> 
>> not fix that problem.
> I am not sure why you would think this is a bug at all. I am pretty sure that 
> this test will not only fail for CD-ROM drives, but for mapped network drives 
> as well, as MSCDEX is nothing but a version of the network redirector.
> 
For Issue #1… 

I did write “The result is always FALSE”  for CD or Network Drives. 

Yep, it is most likely involves the redirector. 

I feel it is a bug because the behavior deviates from that of other system 
drives.  

For example, assume that an internal drive D: exists and NETWORK drive N: 
exists and is mounted. 

IF EXIST D:\NUL echo Drive D: exists.
IF EXIST N:\NUL echo Drive N: exists.

When executing such commands in a batch file, only "Drive D: exists.” would be 
displayed.

This makes testing for NUL useless in determining wether or not a 
drive/directory exists. Not does it behave as one would expect.

Lets say your AUTOEXEC has some instructions to conditionally add directories 
to the PATH. Maybe something like this:

IF EXIST D:\TOOLS\NUL SET PATH=D:\TOOLS;%PATH%
IF EXIST N:\TOOLS\NUL SET PATH=N:\TOOLS;%PATH%

The N:\TOOLS directory would never be inserted into the PATH.

Under the current behavior, testing NUL should never be used to SIMPLY test if 
a drive or directory exists. 

However…

At present, it could be used to detect if a drive might possibly disappear 
while the system is running. 

Although floppy drives behave like internal hard drives, one can assume 
anything on either drive A: or B: might be removed. 

A batch program could conditionally adds a directory to PATH when the drive 
will never disappear from the running system.

REM %DRV% is the drive to test before inserting the directory in PATH
REM Only local drives with fixed media will be inserted into the path
IF “%DRV%” == “A:” GOTO NO_ADD
IF “%DRV%” == “B:” GOTO NO_ADD
IF NOT EXIST %DRV%\TOOLS\NUL GOTO NO_ADD
SET PATH=%DRV%\TOOLS;%PATH%
:NO_ADD

So, it is possibly that there are batch programs that do rely on this behavior. 

Also, it is probably more often the case that a batch would need to know if a 
file exists in a directory and not that a directory simply exists. 
Testing if a file exists on a CD or Network share does work as expected. 

IF EXIST N:\TOOLS\MYTOOL.EXE SET PATH=N:\TOOLS;%PATH%

That would add the N:\TOOLS path if MYTOOL.EXE is present in that directory. 

:-)

Jerome


> Ralf
> ___
> 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] EXIST NUL

[jerome]

Hi All,

There are two separate issues when using:  IF EXIST ?:\NUL 

I'm lazy and wrote up a info text file over at 
https://fd.lod.bz/redist/testing/devNUL/ 
<https://fd.lod.bz/redist/testing/devNUL/> and 

bug report at https://github.com/FDOS/freecom <https://github.com/FDOS/freecom> 
that I will just copy/paste here. 

Additional testing would be required to determine the cause of these problems. 
Since 
the same problem exists for Issue #1 under MS-DOS, an argument could be made to 

not fix that problem. As for Issue #2, it is a FreeDOS specific bug and will 
need fixed. 

:-)

Jerome

NUL Device Existence Test

https://fd.lod.bz/redist/testing/devNUL/ 
<https://fd.lod.bz/redist/testing/devNUL/>
2023-05-23

This test reveals two separate issues:

Issue 1:

Testing for the existence of a path by using the NUL device does not
work on CD/DVD drives or Network Shares. The result is always FALSE.

IF EXIST N:\NUL ECHO Drive N: exists.

See either result0.htm <https://fd.lod.bz/redist/testing/devNUL/result0.htm> or 
result1.htm <https://fd.lod.bz/redist/testing/devNUL/result1.htm>.

Although this behavior deviates from that of other drives, it is
consistent with the behavior of MS-DOS 6.22 using MSCDEX. There is
the possibility that correcting this issue has the potential to break
compatibility with any program that may rely on this behavior.

Issue 2:

Testing for the existence of a non-existing drive returns unreliable
results. This seems reproducible based on the current working directory
when the test is performed. For each test, a copy of the TEST.BAT 
<https://fd.lod.bz/redist/testing/devNUL/test.bat> was
placed in the current working directory.

result0.htm <https://fd.lod.bz/redist/testing/devNUL/result0.htm> was run with 
the current drive and directory on an internal
local drive (C:). It incorrectly shows that the non-existing drive (P:)
was found.

result1.htm <https://fd.lod.bz/redist/testing/devNUL/result1.htm> was run with 
the current drive and directory on an remote
network share (N:). It correctly shows that the non-existing drive (P:)
was not found.

Switching back and forth between drive C: and N: and running the
TEST.BAT <https://fd.lod.bz/redist/testing/devNUL/test.bat> consistently 
produces the same results.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS T2306

[jerome]

Hi All, 

The FreeDOS Interim Test Build T2306 for June 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] I want my 10K

[jerome]

Hi, 

> On May 22, 2023, at 7:03 AM, Rugxulo  wrote:
> 
> Hi,
> 
> On Mon, May 15, 2023 at 6:48 PM  wrote:
>> 
>> Let me show you a MEM print out from my Pentium Pro:
>> 
>>  NANSI3,536(3K)  0(0K)  3,536(3K)
>>  SHSURDRV   400(0K)  0(0K)400(0K)
>>  LBACACHE10,576   (10K)  0(0K) 10,576   (10K)
>>  CTMOUSE  3,104(3K)  0(0K)  3,104(3K)
> 
> NNANSI [sic] can unload, so if you switch to that, all of these can
> optionally be unloaded (if you put them last) to free up memory. Of
> course, SHSURDRV will also unload your whole XMS RAM disk, too.

Sure. But...

Even with loading and keeping all that stuff, the system still has 94K free 
upper memory and 84K of that is consecutive. 

Unloading those drivers would not free up the 11K of Low memory used by the 
Kernel. 
It would just free upper memory of which there is plenty.

The largest executable size is 628K. 
Nothing should every require over 600K of low memory to load. 

I would just like to see all ZEROs in the middle column.
It also wouldn’t hurt to get another 10K added to the largest EXE that can be 
loaded.

Actually, that MEM print out is outdated for that machine. Just to use up some 
more upper memory, it now loads CWSDMPI at boot. That brings free upper memory 
down to about 45K. But if upper memory gets too low or their are compatibility 
issues, I’ll stop loading it at boot. 

Side Note: At boot, the system transfers the main OS files over to RAM disk, 
reconfigures the environment accordingly and primarily runs from RAM. Much 
better performance. A lot less wear and tear on 25+ year old drives. Besides, 
it has got to do something with all that RAM under DOS. 

:-)

Jerome



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

[Freedos-devel] Logger

[jerome]

Hi All, 

Logger is now out of BETA.

Version 1.00 is now available.

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


:-)

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

Re: [Freedos-devel] I want my 10K

[jerome]

Hi,

> On May 16, 2023, at 8:43 PM, Bret Johnson  wrote:
> 
>>> But mostly, I think it would look really cool to have all Zeros in
>>> the Conventional Memory Column.
> 
>> I think this would be an exercise in futility. After all, there are
>> parts of the kernel, which are the first part of (Free)DOS being
>> loaded (by the boot code in the MBR) and then are being used to put
>> in place any further drivers, etc, including any memory manager. I
>> am not so sure that this part "could" be in fact moved up in higher
>> memory (and thus no longer accessible in Real Mode) without opening
>> up not just a can but a whole 55gal drum of worms...
> 
> Ralf is correct.  There are just some parts of DOS that must be below the 
> 640k barrier, particularly if you want to remain compatible with older 
> hardware (8088/80286 CPUs) and older programs.  There are a lot of 
> complicated "games" that go on in the background to get some parts of some 
> programs above 640k or into Expanded or Extended Memory.  If you want things 
> to work correctly, some things just need to be in conventional memory.

Of course, there are actual system related items like the BDA that must remain 
where they are for many reasons. 

Of course on a system without memory or usable memory above 640K (like an 
original 8086), you are stuck using low memory as well.

When MEM displays the contents of programs, I assume SYSTEM is part of the 
Kernel and does not include those items that cannot be located elsewhere. Even 
if it does include such things, those items do not add up to the reported 
SYSTEM usage of 11Kb. 

However, it does not need to be stuck in low memory on more capable hardware. 
On such machines, it should not break compatibility with very old programs that 
were designed for 8086 hardware. All pointers are OFFSET or SEGMENT:OFFSET. 
Wether the call to a DOS interrupt function points to segment in low memory 
(like 0100:1234) or upper memory (like CDEF:1234) will not matter.

The inability to have calls to the kernel in an UMB block (above 640k, bellow 
1M) for compatibility reasons is not accurate. If this was true, then no device 
drivers could be loaded high either. Programs that extend DOS functionality 
(like NANSI), would also break compatibility with old software as well. 

Any program that would not be compatible with kernel calls going to upper 
memory is most likely not compatible with FreeDOS in the first place. Such a 
program, would most likely be using undocumented tricks and require a specific 
version of MS-DOS. However, if support to relocate was included, it should be 
optional just like ‘DOS=HIGH’ to ensure compatibility.

I’m not suggesting that having that portion of the kernel move to an UMB would 
be a simple undertaking. Nor, should it always be done. Only that, it would be 
nice to have the option for it to occur.

To pull it off, several things would need done. As I see it, there are two 
general methods to relocate. Either method would require a lot of going over 
the kernel to make it possible and It would probably require at least some 
restructuring.

It would need a mechanism to have it reinitialize it’s data for the new memory 
location. There would also need to be a method added to perform the actual move 
and reinitialize the data. It may be a lot simpler to just “shutdown” the 
kernel and reload it in an UMB.

This could look something like this. The system boots as normal. A CONFIG 
option like ‘DOSMOVE=UMB’ could exist. The first device driver could check for 
that setting and would verify the kernel could still be relocated. If it can, 
it would relocate or reload that portion of the kernel to an UMB. 

A memory manager is probably the best choice to perform the relocation. It is 
generally loaded before any other drivers. Since JEMM is the default memory 
driver in FreeDOS, I suggest it would be the best choice to perform the 
relocation when possible. JEMM already pulls of quite a few tricks with memory. 
For example, my i686 loads JEMM. Yet, it does not use any conventional or upper 
memory on that machine. It doesn’t even show up with MEM. 

Although it would be a lot of work and probably never happen, it is not an 
impossible task.

:-)

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] I want my 10K

[jerome]

Hi All, 

Let me show you a MEM print out from my Pentium Pro:

Modules using memory below 1 MB:

  Name   Total   Conventional   Upper Memory
          
  SYSTEM  19,888   (19K) 10,944   (11K)  8,944(9K)
  LOGGER   1,760(2K)  0(0K)  1,760(2K)
  NANSI3,536(3K)  0(0K)  3,536(3K)
  COMMAND  4,400(4K)  0(0K)  4,400(4K)
  SHSURDRV   400(0K)  0(0K)400(0K)
  LBACACHE10,576   (10K)  0(0K) 10,576   (10K)
  3C90XPD 30,400   (30K)  0(0K) 30,400   (30K)
  ETHERDFS 7,440(7K)  0(0K)  7,440(7K)
  FDAPM  928(1K)  0(0K)928(1K)
  CTMOUSE  3,104(3K)  0(0K)  3,104(3K)
  UDVD22,016(2K)  0(0K)  2,016(2K)
  SHSUCDX  6,176(6K)  0(0K)  6,176(6K)
  Free   738,464  (721K)642,704  (628K) 95,760   (94K)

Memory TypeTotal   Used   Free
        
Conventional  639K11K   628K
Upper 171K77K94K
Reserved  214K   214K 0K
Extended (XMS) 97,280K71,824K25,456K
        
Total memory   98,304K72,126K26,178K

Total under 1 MB  810K88K   722K

Total Expanded (EMS)8,576K (8,781,824 bytes)
Free Expanded (EMS) 8,192K (8,388,608 bytes)

Largest executable program size   628K (642,688 bytes)
Largest free upper memory block84K ( 86,144 bytes)
FreeDOS is resident in the high memory area.

As you can see, the only thing in low memory is part of SYSTEM using nearly 
11K. 

The machine still has 94K free upper memory and 84K of that is still in a 
single large block.

Yes, I know why this is "the way it is" and you don’t need to explain it to me. 

But, it doesn’t need to be that way. That portion “could" be moved and it would 
free nearly all 
lower memory. Possibly through some cooperation between the Kernel and Jemm. 
Obviously,
the Interrupt Vectors, BDA, etc would need to remain. But, the rest could be in 
upper memory. 

But mostly, I think it would look really cool to have all Zeros in the 
Conventional Memory Column.

:-)

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

[Freedos-devel] Logger v0.4-BETA

[jerome]

Hi All,

I just released Logger v0.4-BETA. 

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


Plus, an update demo boot disk image.

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

This is the final BETA version. 

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

:-)

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

Re: [Freedos-devel] Logger v0.3-BETA

[jerome]

Hi,

> On May 12, 2023, at 4:31 PM, Mercury Thirteen via Freedos-devel 
>  wrote:
> 
> Nice work!
> 

Thanks. :-)

Earlier today, I finished replacing a bunch of stuff in the interface portion 
of Logger. Instead of those parts of the program directly interacting with the 
logged data, they now go through the driver’s API. Now, there is nothing in the 
interface portion can do that could not be done by a 3rd party program using 
the API. This is great for a lot of reasons. First, any future version of the 
binary can work with the current or future versions of the driver. It also 
means the interface portion does not need to have similar code to the driver 
for reading or appending the log. That change along with the removal of ANSI 
output reduced the dual purpose binary by approximately 10%, going from 10k 
back down to 9k. 

I thought about moving the HTML output into a separate program. With all the 
CSS strings and character remapping data, it makes up about 1.7k of the of the 
binary. But, I really like it. So at least for now, it will remain in the main 
executable. 

There is really not anything else I want to do for version 1.0. So, over the 
next few days I’ll probably do a little more testing, maybe make a couple minor 
tweaks and fix any bugs if discovered. Most likely, release version 1.0 on 
Friday. 

:-)

Jerome

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

[Freedos-devel] Logger v0.3-BETA

[jerome]

Hi All, 

With all the changes I made since v0.2-BETA, I decided to do another beta 
release of Logger. Here is an overview of the changes:

* Addition of an API function (and demo program) for reading the log.
* Removal of fairly useless “JAM” mode (Stop when full support).
* Dropped mostly useless ANSI output support.
* Removed VERSION command, just displayed with INFO now.
* Lots of improvements to HTML log output.
* Some general improvements to shave a few bytes.

Package download - https://fd.lod.bz/repos/current/pkg-html/logger.html
Demo Boot - https://fd.lod.bz/redist/system/

I’m going to go through and remove some “dead” code. Since the API provides 
support for everything needed to interact with the log, I’m going to make some 
changes to the interface portion to utilize that functionality. Most of which 
is straight forward and easily testable. There may or may not be an additional 
beta before the 1.0 release.

:-)

Jerome

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

[Freedos-devel] Logger v0.2-BETA

[jerome]

Hi All, 

Logger v0.2 - BETA is now available. 

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

It includes the API, demo API programs, some bug fixes and a couple minor other 
improvements.

This is most likely the final BETA before the version 1.0 release. No 
additional features are planned before that release. 

There may be some minor optimizations or bug fixes. As for any new features or 
major code overhauls (which it could use in several areas), those won’t be 
coming until after version 1.0. 

If you have not had a chance to check out the demonstration boot floppy 
diskette, you should give it a whirl. It can be used to boot the LiveCD from 
FreeDOS 1.3 or any of the Interim Test Builds. 

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

For all purposes, Logger is done for now.

:-)

Jerome

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

Re: [Freedos-devel] Logger v0.1 (beta)

[jerome]

> On May 3, 2023, at 2:48 PM, C. Masloch  wrote:
> [..]
> Your latest code [1] has an error: If only one parameter is given, it will 
> write a retf, then the header, then (as before) a jmp and retf. The second 
> retf at .FarReturnIISP appears to be unused, and it seems you forgot to 
> delete it once you implemented the %1_FAR_RETURN placement before the header.

Yeah, left over stuff that should have been removed. 

Since Logger sets the RETF for the macro, it was not effected. 

But, that could have caused some big headaches, if the macro got reused. 

Thanks. 

> [1]: 
> https://gitlab.com/DOSx86/logger/-/blob/68952313d0bfa91321a3451b2a335ada70e7504a/source/logger/common.inc#L263
>  
> <https://gitlab.com/DOSx86/logger/-/blob/68952313d0bfa91321a3451b2a335ada70e7504a/source/logger/common.inc#L263>
> 
>>> * The %%PrivateEntry code could hardcode the bx response in an immediate 
>>> "mov bx, imm16" instruction, saving at least 2 bytes. Like the multiplex 
>>> number you could patch this instruction's data if it isn't a constant.
>> Great catch. Don’t know what I was thinking when I used the value stored in 
>> the Device Header for direct driver calls. It could move from version to 
>> version. But, It won’t change during execution.
>>> 
>>> * The %%Uninstall response code 06h is commented by you as "cannot remove, 
>>> loaded in config.sys" but in the specification it says "disabled, but can 
>>> not be removed from memory because loaded from CONFIG.SYS". The "disabled" 
>>> indicates that you should have disabled your resident program when you 
>>> return this function code. (As I mentioned before, the uninstall function 
>>> return codes in the current AMIS leave things to be desired.)
>> Thanks, I mis-read that as being the “uninstall function” is disabled.
>> I’m going to change it to 0x05 “not safe, try again later” or maybe just 
>> 0x01 “unsuccessful” would be better.
> 
> I would go with 01h or 00h. Let me look it up, ah yeah I am returning zero in 
> my debugger. [2]

Since I plan on eventually supporting TSR mode, I’ll go with 0x01. Using 0x00, 
would make it "non-compliant". 

> [2]: https://hg.pushbx.org/ecm/ldebug/file/73873421b18d/source/amis.asm#l46 
> <https://hg.pushbx.org/ecm/ldebug/file/73873421b18d/source/amis.asm#l46>

Oh. I added the LOG-RIO demo (Redirect standard I/O) and have at least started 
the API document.

:-)

Jerome


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

Re: [Freedos-devel] Logger v0.1 (beta)

[jerome]

 a memory 
resident program. I think the last of the TSRs I made was for use on my 486. 
So, that was a little while ago. Ah, the joys of surfing the internet in the 
90’s using Windows 3.11 and the Marathon browser. 

> I also briefly checked out your example programs [2].
> 
> * Unneeded cld in Driver_locate 

Yeah, I left that in there in case anyone just did a copy-paste of the driver 
location function. I’ll comment them out but leave them in place. 

I still need to go through the driver/interface and remove a bunch of them 
there as well. There is only one STD which is changed back after use. It’s just 
a matter of looking to see where to put the single CLD on entry into the 
driver. 

> * You handle all return codes in al except al == 0FFh by jumping to .Next, so 
> a single comparison and branch would suffice instead of two.

Wanted to show that it could be tested for an invalid response. But, that does 
waste bytes. I’ll just remove them and put in some code comments. 

> * "inc bh" already sets the Zero Flag if the multiplex number wrapped around, 
> so you don't need to run a "test bh, bh" afterwards.

oops. 

> 
> * The PrintLoop "cmp si, 82h" instruction is confusing to me. Either it is 
> wrong, or I don't understand it. Seems like at least a comment would be 
> appropriate.

It’s correct. 

PSP Command line Length byte is 0x80, we skip that and start at 0x81. However, 
the first character may or may not be a space. For example, "log-msg test” and 
“log-msg=test” both execute log-msg. However, the first has a space at 0x81, 
the second has a = there. So, it checks if the character is a space, then 
checks if SI is at character position 2. If both are true, it assumes the first 
space is just separating the command line from the option string. Otherwise, it 
assumes it is intended additional indentation. 

I added some comments to hope clarify that.


> * It would be more efficient to write a zero terminator behind the command 
> line tail, then write the entire command line in one call to the multiplexer. 
> If you were willing to display them in the same colour you could even add in 
> the CR LF sequence after the text, to reduce the number of calls to one 
> instead of two.

I wanted to demonstrate both API function 0x14 “Add Character to Log” and 0x15 
“Add ASCIIZ to Log”

However, I’m lazy and did not want to write 2 separate demo programs that add 
simple command line text to the log. :-)

I should probably add a demo for redirecting Standard I/O into the log. It 
would be great for floppies. Because, there would be a very small program that 
could be substituted for the Logger Interface for everything but viewing, 
printing and checking how full state. The STDIO demo (probably called LOG-RIO) 
could also use the driver far call method which would be much faster if 
multiple 0x2d hooks are in place. 

> [1]: 
> https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/source/logger/hookamis.inc#L116
> [2]: 
> https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/doc/logger/devel/log-msg.asm
> 
> 
>> The addition of the API and inclusion of the UPX’ed driver only version 
>> makes the size of the single dual-mode binary much less important for usage 
>> on boot floppy diskettes. For example, if it were used with the FreeDOS 
>> install media, only 2.6kb would be required for the driver. If non-user 
>> visible debug messages are desired, the simple 141 byte demo “add message” 
>> program could be used. This would consume about 3kb of disk space instead of 
>> the roughly 10kb used buy the dual-mode binary. As a bonus, having a batch 
>> execute the small demo program repeatedly would be much faster than 
>> launching the bigger program to simply append the log.
>> The API only supports the functions mentioned earlier. It does not support 
>> reading the log. I think that would be of very limited use and most likely 
>> not worth the additional cost in memory to provide those functions. However, 
>> those may be added in future versions if there is enough demand for them.
> 
> I appreciate that you documented the API by way of examples, but it would 
> still be useful IMO to list all the interface functions in a single list 
> somewhere. For example, this is the list in my debugger's amis.asm source 
> file: [3].

I’ve just been very busy and haven’t done that yet. I will probably add them to 
my HTML version of RBIL as well. 

The API demos were also test programs to make sure everything was working as 
they should. 

:-)

Jerome

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

Re: [Freedos-devel] Logger

[jerome]

Hi,

> On May 1, 2023, at 7:04 AM, C. Masloch  wrote:
> [..]
> 
> I adjusted my inicomp stage slightly, originally an lDOS boot iniload stage, 
> to allow using it to compress the dual-mode (single binary) Logger. First 
> change was to allow setting up a stack based on the flat .COM style 
> entrypoint [2]. The second option is for a very small optimisation that 
> disables boot-loaded mode entrypoints into the stage [3]. Then I modified 
> Logger's log-drvr.asm to use the entrypoints expected by inicomp for the 
> device header [4].
> 
> During rebuilding Logger I found that a very recent NASM version, like 2.16 
> ish, is required to build. This is because you use the istruc support of 
> struc local labels, which was added to the standard macros in [5]. Rebuilding 
> also required to work around a new NASM problem [6]. The new macros could be 
> used in an older NASM as well, if you included some %unmacro lines and the 
> new macros in your sources. NASM is under the 2-clause BSD license [7] so you 
> could copy their macros.
> 
> Here's the results of building my compressed dual-mode Logger executable, 
> compressed using LZIP (high ratio, slow) and LZSA2 (faster):
> 
> [..]
> logger/BIN$ ls -lgG
> total 48
> -rw-r--r-- 1 9240 May  1 11:10 LOGGER.COM
> -rw-r--r-- 1 5601 May  1 12:21 logger.lz
> -rw-r--r-- 1 8608 May  1 12:21 loggerlz.com
> -rw-r--r-- 1 6050 May  1 12:21 logger.sa2
> -rw-r--r-- 1 7456 May  1 12:21 loggersa.com
> logger/BIN$
> 
> I'm not impressed, but at least it is a little savings. I tested the files as 
> both device driver and application mode executable. As you can see, the LZSA2 
> executable is actually smaller than the LZIP one because the LZIP depacker is 
> much larger. For my usual use case of the lDebug debugger (> 100 KiB), the 
> bigger depacker costs less space than is saved by the higher compression 
> ratio.
> 
> A problem with my depackers as opposed to UPX's is that I do not take 
> advantage of the fact that Logger's binary is very small. Indeed, my 
> depackers support operation spanning more than 64 KiB of both the compressed 
> payload and the resulting decompressed program image. If I took that out I 
> could improve the depacker size.
> 
> And I am worse at size optimisation than the UPX people. But if they do not 
> yet provide support for dual-mode executables then my contribution could 
> still be useful to you.
> 
> 
> [2]: https://hg.pushbx.org/ecm/inicomp/rev/aa0974fdd6e2
> [3]: https://hg.pushbx.org/ecm/inicomp/rev/41860de1db0e
> [4]: 
> https://github.com/ecm-pushbx/logger/commit/5cbd3b1f9548568458f92962e83cc0bdd7d61818
> [5]: https://github.com/netwide-assembler/nasm/pull/40
> [6]: https://bugzilla.nasm.us/show_bug.cgi?id=3392822
> [7]: 
> https://github.com/netwide-assembler/nasm/blob/a916e4127b2eaa3bf40bddf3de9b0ceefc0d98a4/LICENSE

That is very interesting and will defiantly keep it in mind. If Logger does not 
eventually move to EXE format and probable UPX support, this would be a great 
alternative. 

Space saving on floppies is very important. With the inclusion of the driver 
only version that supports UPX and the tiny API demonstration programs, I don’t 
think compression of the dual-mode binary is as important at present. After 
all, the viewer could always be on a separate diskette if required. 

I do want to eventually compress the dual-mode binary as well. But for now, I 
think I’ll just put off worrying about that until a later version. It will give 
everyone something to look forward to getting. 

:-)

Jerome

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

[Freedos-devel] Logger v0.1 (beta)

[jerome]

Hi All, 

Yesterday, I released the new version of Logger. It has come a long way since 
the first Alpha release and works great. I made some final decisions on a 
couple aspects and it is now in the Beta stage. Other than some probable byte 
squeezing, there is only one other possible feature I might add before the 
final version 1.0 is released (see below). 

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

Here is a summary of the major changes and final decisions I made since the 
Alpha-7 release:

Interface can export the log as HTML in full color.
Driver supports VESA mode changes.
Driver supports AMIS and IISP.
Driver provides the ability to check status, enable/disable logging, clear and 
append the log through an API.
API is usable through AMIS or by direct far call to driver by other programs.
Driver and Interface will be released as a single dual-mode binary. (popular 
request)
Release includes very small and simple API examples. (For example, a 141 byte 
COM program with source to append the log.)
Release includes UPX’d driver only version for usage on limited capacity media 
like boot floppies when needed.

Adding AMIS, IISP and the API increased the memory resident footprint of the 
driver by approximately 30%. But, that is still only a total memory footprint 
of 1,472 bytes for the 0.1-BETA version. I think those features are worth the 
couple hundred bytes required for their support. There is no API documentation 
at present. Instead, I included simple examples that include all the different 
API functions. 

The addition of the API and inclusion of the UPX’ed driver only version makes 
the size of the single dual-mode binary much less important for usage on boot 
floppy diskettes. For example, if it were used with the FreeDOS install media, 
only 2.6kb would be required for the driver. If non-user visible debug messages 
are desired, the simple 141 byte demo “add message” program could be used. This 
would consume about 3kb of disk space instead of the roughly 10kb used buy the 
dual-mode binary. As a bonus, having a batch execute the small demo program 
repeatedly would be much faster than launching the bigger program to simply 
append the log. 

The API only supports the functions mentioned earlier. It does not support 
reading the log. I think that would be of very limited use and most likely not 
worth the additional cost in memory to provide those functions. However, those 
may be added in future versions if there is enough demand for them.

The only other feature I am considering adding before the version 1.0 release 
is triple-mode support to the binary. Along with behaving like a device driver 
for loading in the CONFIG.SYS, it would be (very, very) useful to be able to 
simply run the binary from the command line and use the driver portion as a 
TSR. However, I’m tired of working on Logger and may put this feature off until 
version 1.1. We will see.

What will not be in version 1.0 is NLS support. Other than the help, status 
information and a couple error messages, Logger really does not have much user 
facing text of itself. The primary reason for eventually adding NLS support is 
because of the HTML output. As most of you are aware, many DOS ASCII characters 
are not displayed by HTML directly. Many symbol and special characters require 
remapping to HTML sequences. For example, simple characters like “<“ need 
converted to “”. The HTML output by logger already does this for some 
characters. But, many more should be added. Eventually, it will get NLS support 
and the capability to use alternate mappings for different languages. 

On a side note… Logger has seen some “real world” use over the last week. One 
of my DOS machines was causing another developers programs to have a couple 
issues. Using Logger made it very easy to record the program output and other 
information which I was able to easily share with the developer in order to 
solve the issues. This is where I really have grown to like the HTML output a 
lot. With the inclusion of color, they look really nice when viewed on common 
desktop operating systems like macOS and Linux. 

Oh, I also updated the Logger demo boot diskette image that can use either the 
LiveCD from FreeDOS 1.3 or any of the Interim Test Builds to start a Live 
Environment. 

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

:-)

Jerome


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

[Freedos-devel] FreeDOS T2305

[jerome]

Hi All, 

The FreeDOS Interim Test Build T2305 for May 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] LOGGER - Just because: why not

[jerome]

Hi All,

I forgot the repository management software would delete the logger sample HTML 
file when performing automatic cleanup. So, I uploaded a new sample file to a 
different location. It is only visible via direct link and does not show up on 
the index page itself. 

https://fd.lod.bz/logger-sample.html <https://fd.lod.bz/logger-sample.html>

:-)

Jerome

> On Apr 26, 2023, at 5:31 AM, jer...@shidel.net wrote:
> 
> Hi All, 
> 
> As I mentioned previously, LOGGER can log both in monochrome and color. Along 
> with the built in viewer, the log could be printed to include ANSI escape 
> sequences for color. But, that is of very limited use. So along with the 
> PRINT and ANSI commands that output the log to StdOut, there is a new one in 
> ALPHA-7. It is of little use in DOS itself. Rather, it is intended for 
> sharing a full color log that can be viewed on common desktop and mobile 
> operating systems. Check out the new HTML log output sample. 
> 
> https://fd.lod.bz/repos/current/pkg-html/logger-sample.html 
> <https://fd.lod.bz/repos/current/pkg-html/logger-sample.html>
> 
> or, download and try for yourself
> 
> https://fd.lod.bz/repos/current/pkg-html/logger.html 
> <https://fd.lod.bz/repos/current/pkg-html/logger.html>
> 
> Oh BTW, I also added support for VESA mode changes as well. 
> 
> :-)
> 
> 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] Logger

[jerome]

> On Apr 28, 2023, at 5:42 PM, Bret Johnson  wrote:
> 
>> For fun, I decided to implement a single binary compiler directive.
>> When enabled, it generates a single COM that acts as both the driver
>> and interface program. But, I am unsure if I will use that or the
>> dual (SYS+COM) build for the 1.0 release.
> 
> FWIW, in my TSRs I don't try to create a SYS program at all but just stick 
> with COM.  At least in later versions of DOS, you can install TSRs with the 
> INSTALL= option in CONFIG.SYS.  So, you don't actually need a SYS (or 
> dual-mode) program to install something in CONFIG.SYS instead of 
> AUTOEXEC.BAT.  TSRs have so many advantages over device drivers (particularly 
> in their ability to be uninstalled and reconfigured) that I don't see a real 
> need for device drivers.
> 
> Exceptions would be if you're using an older version of DOS (before the 
> INSTALL= functionality was added to CONFIG.SYS which in MS-DOS was version 
> 4.0) or you need the device driver to be installed really early in the boot 
> process (which I think may be the case for your logger program).  Unlike 
> AUTOEXEC.BAT, CONFIG.SYS has a prioritization of which commands get processed 
> first so the order of installation is not necessarily the same as the order 
> things are listed in CONFIG.SYS.  I'm not sure exactly where in the 
> prioritization the INSTALL= lines are processed compared to the DEVICE= lines.

Although you don’t “need” to load it very early, it is best to load it 
immediately after the memory manager. That way it can record all the boot 
messages. Including those of the memory manager(s) that were loaded before 
Logger. 

At some point in a future version, it will probably be released as a single 
binary instead of using a SYS+COM model. It can already compile to a dual-mode 
COM file that can function as both a driver and interface program. Implementing 
a triple mode binary that could also function as a TSR would not be difficult 
or add that much code to the single binary version. 

But, I think all that stuff is better suited for a post 1.0 version. I don’t 
want the initial release to suffer from feature creep and be put off for months 
or indefinitely. 

:-)

Jerome




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

[Freedos-devel] Logger

[jerome]

Hi All,

Logger is coming along great and I’m currently working on the final ALPHA-8 
version. Once that is done, it will be time for a BETA or two. Then finally 
version 1.0. 

For fun, I decided to implement a single binary compiler directive. When 
enabled, it generates a single COM that acts as both the driver and interface 
program. But, I am unsure if I will use that or the dual (SYS+COM) build for 
the 1.0 release. 

Mostly, it comes down to the size of the binary. At present, both the driver 
and interface programs are UPX compressible. Their uncompressed size are about 
3k & 6k respectively. So, when space may be tight on a boot floppy, the driver 
will only need about 2.5k (UPX’d) of diskette space. Also if the interface 
program is used in batch files to append debugging comment messages (not shown 
to the user) directly to the log, it requires loading just the 4k (UPX'ed) 
interface program . 

When compiled as a single COM for both the driver and interface, UPX 
compression cannot be used and the binary is about 9k at present. Because there 
is some common (or at least similar code) shared between the driver and 
interface, this could most likely be reduced by 1 or 2k in some future version. 
But that level of optimization will not happen anytime soon. I have other 
things of much higher priorities that need doing. 

So, the single COM will require almost 4 times the space of the dual binary 
format. While it may not matter much for Hard Drives, CD-ROMs and USB sticks, 
it could matter a lot for a floppy. 

I guess for version 1.0, it could include the SYS and the single binary COM. 
But, that could be confusing. Probably better to go with either the dual 
binaries or just the single binary. And, I am leaning towards the dual binaries 
for version 1.0. 

IDK.

On a side note…

I was playing with the single binary version and noticed some interesting 
things. Under VirtualBox, I could even wait to load it post boot using DEVLOAD 
(high or low). Which reported "1 char device installed. Driver Loaded.” and 
everything worked fine. 

But under DOSBox, DEVLOAD reports an “ERROR: free drive letter not found, 
increase LASTDRIVE”. I get that it is DOSBox and did not expect it to work. 
But, the driver is a char device and doesn’t use a drive letter. And, DOSBox 
uses drive Z: for it’s pseudo-commands. So, it was not the error I was 
expecting. Too be fair, I was expecting just a crash and not an error. 

:-)

Jerome

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

[Freedos-devel] LOGGER - Just because: why not

[jerome]

Hi All, 

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

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

or, download and try for yourself

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

Oh BTW, I also added support for VESA mode changes as well. 

:-)

Jerome

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

Re: [Freedos-devel] Extension proposal

[jerome]

After implementing the previous optimizations and adding IISP (IBM Interrupt 
Sharing Protocol) the net savings with resident footprint is 1 paragraph for 
methods 2B and 2D, and 2 paragraphs for the Driver Chain walking. 

> I didn't check all the other resident code for optimisations yet, but I can 
> do so if you're interested.

That would be great.  

Much of the code was written as I worked through the problem of getting a 
stable and reliable capturing system up and running. I was constantly going 
back and changing and re-changing sections until the desired behavior was 
reached. There is little doubt it is not optimal and could probably use a 
complete rewrite of some sections for improved performance and size. But, it 
works and that may be good enough for version 1.

There are also a couple more things like that I should add. Like watching for 
changes to a VESA mode. At present, that will go unnoticed and the logging 
capture method does not switch. It is just a matter of hooking that interrupt 
function as well. 

I may also want to add a 3rd party interface to read, write and control the 
logging driver. But, I don’t know if that is really worth doing and would 
increase the resident footprint a lot. Maybe, I’ll hold off on that until 
version 2.

Once that stuff is done, it will be time for the  BETA version. 

> [..]
>> If it is made "fully compliant” with the AMIS protocol, it will add a 
>> minimum of 22 more bytes. Most likely, it will eventually be double or 
>> triple that. There are advantages to using AMIS. But, it requires calling 
>> the interrupt 255 times to check every multiplexer.
> 
> Up to 256 times, actually.

Yup. 0xff=255, 0x00 thru 0xff=256. 

I saw the typo after I sent the message and knew someone would point it out. 

LOL

> [..]
> 
> In any case, thanks for your work!
> 
> Regards,
> ecm
> 

You are welcome. 

It is not really work, I enjoy it. 

Thanks again for all the feedback.

:-)

Jerome

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

Re: [Freedos-devel] Logger

[jerome]

Hi All,

I implemented walking the device driver chain to locate the Logging Driver. Not 
sure what dumb thing I did wrong the first time I looked at it. But, it seems 
to work fine now. 

After writing the 3 different methods to locate the driver, here are the 
results for the current ALPHA version.

(COM=LOGGER interface binary, SYS=LOGGER device driver)

1) When using the 0x2b interrupt hook, COM size 4460, SYS size 3006, SYS 
resident size 1216. This is definitely the fastest method to locate the driver. 
It is a single interrupt call with verification and it is done. But as 
discussed before, it is a “new standard” that most likely should be avoided. 

2) When using the partial implementation of the AMIS interrupt 0x2d 
multiplexer, COM size 4476, SYS size 3055, SYS resident size 1232. If it is 
made "fully compliant” with the AMIS protocol, it will add a minimum of 22 more 
bytes. Most likely, it will eventually be double or triple that. There are 
advantages to using AMIS. But, it requires calling the interrupt 255 times to 
check every multiplexer. If fully implemented, it would also increase the 
resident footprint by roughly 10% of the current requirements. If additional 
functionality is added to the driver (things like screen capture, hot keys, 3rd 
party driver control interface, etc) the larger size would be less important. 
Plus, it would provide a “semi-official” interface to that additional driver 
functionality. 

3) When walking the device driver chain, COM size 4480, SYS size 2966, SYS 
resident size 1168. This is also very quick and should only require checking a 
couple links in the device driver chain. It requires no extra code in the 
driver and has the smallest memory resident footprint of the three methods. It 
seems to work great under FreeDOS, MS-DOS and PC-DOS. There could be 
compatibility issues under other DOS distributions. However, there are some 
safeguards in place to prevent getting stuck if walking an invalid device 
driver chain. Although it would be nice, I do not really care if it is not 
compatible with other DOS platforms. 

I think for the time being, walking the driver chain will be the way to go. 
Eventually, it will probably be moved to AMIS in a future version.

As for using a single binary that doubles as both the device driver and driver 
interface, I’m still undecided. There are good reasons for doing that. First, 
it would be just a single binary to worry about. Second, the overall size would 
be reduced by not duplicating the code shared between them. But, there are some 
drawbacks as well. Although the total size would be smaller, the single binary 
would be much larger than the two individual binaries. Even though the resident 
footprint of the driver would remain unchanged, it would require a larger free 
memory block when initially loaded. It would also require loading everything 
each time the interface program is used to directly append the log. The extra 
couple KB won’t matter much when running from a hard disk or if caching is 
used. But if run from a floppy, the loading delay would add up with repeated 
execution. To be fair, that probably will not matter very much.  Finally if 
space is critical on a boot floppy, using two binaries allows having just the 
small driver on the boot diskette and putting the interface program on a 
separate diskette. 

I think the advantages of a single binary probably outweigh having two separate 
ones. But like using AMIS and providing a 3rd party log control interface, I 
feel that would be better suited for a version 2.x release. For version 1.x, I 
think it may be better to use the SYS+COM pair of binaries. I’m still undecided.

:-)

Jerome

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

Re: [Freedos-devel] Extension proposal

[jerome]

Hi All,

For “fun”, I implemented initial versions of both the 0x2b interrupt hook and a 
partial 0x2d implementation to locate the Logger device driver. 

The 0x2d version is very bare bones and does not include several functions 
required to be “fully compliant”. It only responds to the install check 
function for whichever multiplexer it allocates. Other function requests only 
respond with AL=0x00 which i guess is “not implemented”. 

As such, 0x2d uses 35 bytes more resident memory than 0x2b. (actually 49 bytes 
more if you count a “title” string that is not required). If I spend the time 
making it fully compliant, it will require even more. It really would need 
function 04 (determine chained ints) and should have 06 (device driver info). 

I think overall, it might be better to figure out why walking the device driver 
chain was not working correctly. Most likely, it was some dumb thing I was 
doing wrong. It would have the smallest resident footprint of the locating 
schemes. 

I’ll probably take another look at that. Or maybe, I’ll just stick with the 
0x2d multiplexer despite it’s larger footprint. 

All are better (and much faster) than the temporary brute force search in 
previous versions.

:-)

Jerome

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

Re: [Freedos-devel] Extension proposal

[jerome]

Hi Tom,

> On Apr 21, 2023, at 2:01 PM, tom ehlert  wrote:
> 
> Hi ecm,
> 
> 
>> [1]: 
>> https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267
> 
> this got me looking into this 'too slow' detection method.
> and it is indeed slow. as in molasse. let me explain.
> 
> 
> a) isn't
> 
>  %%Comparing:
>inc di
>lodsb
>cmp al, [es:di]
>jne %%Next
>loop%%Comparing
> 
> more or less the definition of
> 
>repe cmpsw
> 
> ??

Yes, more or less it was a  “repe cmpsb”

That was a while ago and I forget the reasoning I did it that way. Possibly, 
not requiring a case-specific match. 

> b) decompiling the actual code, it's basically
> 
> 
>  for (seg = 10; seg < 0xa000; seg++)
>{
>if (fmemcmp(MK_FP(seg, 9), "LOGGER", DriverLength))
>{
>return found_our_driver_at(seg);
>}
>}
>   return failure;
> 
> that's indeed slow as it compares all memory up to 0xa000 to lookup the 
> driver,
> or up to the drivers address (which is much better most of the time.

Yup it is a very slow way to locate the driver. It was only meant to be 
temporary until better method was implemented.  

The better method will most likely be INT 0x2D (AMIS).

During the development stage, locating the driver needed to be done quickly so 
other things could be developed and tested. 

That process went something like this:

1) We could walk the MCB chain…. That will require some overhead and 
complexity. Too big of a pain for now (see below).
2) We could walk the device driver chain. Thats fairly straight forward and 
easy enough to implement. Lets do that… Hmmm, not all device drivers are 
showing up in the chain and logger is not being seen. Let’s not worry about 
that for now and do something else.
3) We could hook an interrupt somewhere. Yeah, that will be good and reliable. 
Lets do that. But, which one will not cause any conflicts or collisions. Hmmm, 
lets worry about it later and just get something that works for now.
4) Well a brute force search will work. It is slower than a glacier and as 
clever as a stone. But, it will work well enough that I can get to work on 
writing and testing the important stuff. 
5) Brute force search it is then with a very few optimizations… For now, good 
enough. 

Even though the delay incurred when launching the interface program is not very 
noticable, it is way to slow.

Now that the important stuff has been written and is being tested, the brute 
force search needs to go. 

> when I mentioned microseconds, I had the DOS memory chain in mind where you 
> would have 
> to compare 20-50 locations to your drivers name.

I did consider walking the MCB chain to find it. But, that comes with its own 
set of problems. Some blocks contain sub-blocks. The upper memory blocks may or 
may not be linked into the primary MCB chain. 

There are other aspects involving interaction between the Driver, Interface and 
Log that are also just “good enough for now” and will probably be changed a 
great deal. 

It is an alpha version for a reason.

:-)

Jerome




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

Re: [Freedos-devel] Extension proposal

[jerome]

 than letting the multiplexer return its signature.
> 3. If 2 wasn't already a problem then you still would have an interface that 
> could modify registers unknown to the caller. Is it enough to preserve all 
> 16-bit GPRs and segregs? 386 registers? FPU registers, MMX, XMM, etc?

You would only modify the registers required to test for the signature. If you 
don’t match, you don’t modify anything. If you do match, than you could modify 
whatever. This really is not very different than a combined version of the 
Install Check (0x4300) + Get Driver Address (0x4310) that are used for XMS on 
Interrupt 0x2F. 

> 
>> It requires no additions to the kernel, is backwards compatible and should 
>> have a low probability of any collisions.
>> Any thoughts on using it as a very minimal “standard” extension installation 
>> check?
>> :-)
> 
> I do have thoughts, and most of them go back to "use a standard that exists 
> already". The backwards compatibility and kernel agnostic nature of AMIS is 
> the same as for your proposal. Unlike your proposal so far, AMIS multiplexers 
> can be scanned by other programs regardless of whether they "know" the 
> particular multiplexer.

Overall, using AMIS is probably the best solution.

:-)

Jerome



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

Re: [Freedos-devel] Extension proposal

[jerome]

Hi Eric, 

> On Apr 21, 2023, at 10:27 AM, Eric Auer  wrote:
> 
> 
> Hi Jerome,
> 
> if you are worried about collisions, use AMIS int 2d.
> Overhead is low and it is less crowded than MUX int 2f.
> 
> RBIL was famous enough to make AMIS more widespread. FreeDOS is too
> niche to re-invent that wheel and declare int 2b to be a new trend.
> 
> Why would your RESIDENT driver have to do install checks?
> You can do those in the TRANSIENT part and just store the
> results as static data in the resident driver part.

There driver does do an install check at start up to prevent multiple 
instances. 
However, all of that code is discarded after initialization. But, you still 
need to 
“store the results” in the resident portion and respond to the interrupt calls
properly. 

There is probably little difference in the resident portion between using 2D or 
2B. Only, writing both versions could say for certain which is larger and by
how much. But, RBIL says 64-bytes + 22 per hooked interrupt. A simple ID
string comparison and set return values won't use much.

But we are taking about bytes and the savings may not be worth it.

> So the risk of wasting RAM by using AMIS are minimal :-)
> 
> I agree that MUX can get crowded. However, for disk I/O,
> the actual I/O still is the main bottleneck (unless you
> are a large cache with a very inefficient algorithm) and
> you would not do install checks for each invocation anyway.
> 
> One example of slow call chains which you can feel may
> be old ANSI variants and slow system and VGA BIOS. But
> that was long ago and even those were not THAT slow.
> 
> AMIS can be expected to be much faster than MUX and it
> will not be in the way for your CDEX performance either.
> 
> If you want to avoid the hassle of scanning for a free
> magic number, I would just hardcode one. Collision risk
> will still be lower than when grabbing the whole int 2b.
> 
> I agree with Tom: Use int 2d, it is the better choice and
> 2023 is not the year for MORE standards for simple things.

The only advantages I see in using 2B instead are as follows, it is 
very light weight, it uses very little memory to implement, it has 
almost no chance of conflicts and only being used for an install check
there is no impact on performance of any aspect of the system. 

Unless I just stay with the brute force search, 2D is probably the 
better choice. There are even suggestions that memory managers
can query it to retrieve the driver name. Although, I don’t know 
if the FreeDOS mem command makes use of that or not.

> Regards, Eric

:-)

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] Extension proposal

[jerome]

> On Apr 21, 2023, at 10:21 AM, tom ehlert  wrote:
> 
> Hi,
> 
> 
>> At present, the interface program for Logger just performs a slightly 
>> optimized brute force search for the Logger device driver. Although 
>> reliable, it is very slow compared to providing a simple interrupt call to 
>> test for installation.
> 
> given that this detection will be done once per program start: how many 
> microseconds do you expect to save?

Well, there is the catch.

At present, the current semi-optimized brute force search is quick. The delay 
in finding the driver is not really noticeable when a user invokes the 
interface program to view, print or perform some other operation. 

But there is a delay and those delays can add up. For example, if the FreeDOS 
installer ran the interface program many times to put messages into the log or 
write the results of programs like FDISK there for debugging installation 
issues. All those executions will add up. 

But, like you said, how much performance will be gained? For example, if adding 
a comment to the log takes 1 second to load the interface program from floppy 
diskette and only 1/1000 of a second to find the driver, then improving that 
makes almost no sense at all.  

I should probably benchmark it to see if it is worth the bother. But, it would 
vary widely based on system and numerous other factors.

> 
>> Looking at the different interrupts, I think I have come up with a solution 
>> that will work well for Logger and any other driver or program that needs 
>> such a check. So, I’d like to propose a “standard” we could use. I’d like to 
>> get your feedback on what I’m thinking…
> 
> setting a "standard" which is used probably exactly once ? we write year 2023 
> ;)
> 
> https://xkcd.com/927/
> 
> INT 2D has been mentioned by others

Maybe go for 16 instead. It is an even binary number. LOL

XKCD is great. 

> 
> 
>> Looking at RBIL, interrupt 0x2b is barely used by anything. Under MS-DOS and 
>> FreeDOS, this simply points to an IRET. Under IBM ROM-DOS, AH functions 
>> 0x00-0x03 do some things. But, all other calls do nothing. 
> 
>> https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html 
>> <https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html>
> 
>> An install check issuing this interrupt would be simple to perform. A 
>> program could set the Carry Flag, load AH/AX with “check for install” 
>> function and set DS:BX to point to an identifier string (minimum 8 
>> characters, no maximum). Then call the interrupt. On return, if the Carry 
>> Flag is still set, then the install check failed. If the Carry Flag is 
>> clear, it succeeded and other register would be modified to according to the 
>> needs of the programs. 
> 
>> Implementation for Logger (as an example) could be:
> 
>> 
>> CHECK:
>>push cs
>>pop  ds ; set DS to our code segment
>>stc ; set the carry flag
>>mov  ax, 0xfd00 ; set AX to install check function
>>mov  bx, LOGGER_ID  ; offset to LOGGER device driver ID
>>int  0x2b   ; call install check interrupt
>>jc   NOT_INSTALLED  ; nothing changed, driver is not 
>> loaded
> 
>   ;you should add 
>  cmp ax, MAGIC_VALUE
>  jne   NOT_INSTALLED
> 
> your proposed INT2B might be used by some other software that for some crazy 
> reasons 
> clears the carry flag.

Your correct of course. :-)

In implementation, I would probably have it return the pointer to the driver 
header and verify the signature of the driver again by the caller. 

> 
> anyway, INT2D is probably the better choice anyway.

Probably, I just don’t like to add extra code and increase the resident 
footprint without good cause.

:-)

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] Extension proposal

[jerome]

Hi Eric and Bret,

I looked at 2D, 2F and even absolute AMIS 7D. 

> On Apr 21, 2023, at 7:44 AM, Eric Auer  wrote:
> 
> 
> Hi Jerome,
> 
> there is no need to allocate a whole int 0x2b for just one driver.

It need not be just for one driver. 

Anyone could hook 0x2b and is a very loose and light weight method with an 
extremely low possibility of collision or conflict. Also, nothing else uses 2B 
so it will not effect general system performance. We also don’t need to worry 
about Microsoft changing things and breaking it. 

> There are mechanisms which already invite drivers to share them :-)
> 
> INT 2D - ALTERNATE MULTIPLEX INTERRUPT SPECIFICATION (AMIS) [v3.6]
>AH = multiplex number
>AL = function
>00h installation check
>01h get private entry point
>02h uninstall
>03h request popup
>04h determine chained interrupts
>05h get hotkey list
>06h get device-driver information
>07h-0Fh reserved for future enhancements
>Return: AL = 00h (not implemented)
>other  application-dependent
>other registers vary by function (also see individual entries below)
> 
> You also are in good company there, for example screen thief uses it.

https://fd.lod.bz/rbil/interrup/tsr/2d.html 
<https://fd.lod.bz/rbil/interrup/tsr/2d.html>

I was looking at it. It seems to require a good deal of additional overhead and 
complexity for just a “hey, where are you?” install check. Which will increase 
the memory resident footprint a little unnecessarily. 

However, it is an (at least partially) accepted “standard” and possibly the 
better solution and would not increase the footprint that much. It is 
definitely worth further consideration.

> 
> INT 2F - Multiplex - NOTES
>AH = identifier of program which is to handle the interrupt
>   00h-3Fh reserved for IBM (for DOS)
>   40h-7Fh reserved for Microsoft (for DOS)
>   80h-B7h reserved for IBM
>   B8h-BFh reserved for networks
>   C0h-FFh reserved for applications
>AL is the function code
>   This is a general mechanism for verifying the presence of a TSR and
>   communicating with it.
> 
> AMIS got introduced (by RBIL, sort of?) because so many apps use INT 2F,
> but if you only need an install check, performance is no issue and you
> can use INT 2F without problems.
> 
> You can also use INT 2F just for detection and then acquire a pointer
> to a fast call provided by your driver if you need something quick.

I don’t think 2F would be a good choice. In part, you have the network 
redirector and other filesystem related functions on that interrupt. Every hook 
that gets installed there takes a little slice of time to process. Which in 
turn, can slow down normal file operations. 

Also, I think that there is to high a risk of having a possible collision with 
2F with programs that just arbitrarily grab a fixed “unused” function to 
intercept.

> 
> Regards, Eric
> 

I think it comes down to either using 2D or 2B. I like 2B because there is 
almost no overhead and very simple to implement on both ends. But, 2D might be 
the better way to go and is a pre-existing semi-accepted standard.

:-)

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] Bug 0x5801/41

[jerome]

Has there been any follow up on this issue?



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

[Freedos-devel] Extension proposal

[jerome]

Hi All, 

At present, the interface program for Logger just performs a slightly optimized 
brute force search for the Logger device driver. Although reliable, it is very 
slow compared to providing a simple interrupt call to test for installation. 
Looking at the different interrupts, I think I have come up with a solution 
that will work well for Logger and any other driver or program that needs such 
a check. So, I’d like to propose a “standard” we could use. I’d like to get 
your feedback on what I’m thinking…

Looking at RBIL, interrupt 0x2b is barely used by anything. Under MS-DOS and 
FreeDOS, this simply points to an IRET. Under IBM ROM-DOS, AH functions 
0x00-0x03 do some things. But, all other calls do nothing. 

 https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html 


An install check issuing this interrupt would be simple to perform. A program 
could set the Carry Flag, load AH/AX with “check for install” function and set 
DS:BX to point to an identifier string (minimum 8 characters, no maximum). Then 
call the interrupt. On return, if the Carry Flag is still set, then the install 
check failed. If the Carry Flag is clear, it succeeded and other register would 
be modified to according to the needs of the programs. 

Implementation for Logger (as an example) could be:


CHECK:
push cs
pop  ds ; set DS to our code segment
stc ; set the carry flag
mov  ax, 0xfd00 ; set AX to install check function
mov  bx, LOGGER_ID  ; offset to LOGGER device driver ID
int  0x2b   ; call install check interrupt
jc   NOT_INSTALLED  ; nothing changed, driver is not loaded
mov  [DRIVER_PTR + 2], es   ; save segment of far call to driver 
function dispatcher
mov  [DRIVER_PTR], di   ; save offset of far call to driver 
function dispatcher
jmp  MAIN

DRIVER_PTR:
dw 0, 0 ; pointer to driver function dispatcher

LOGGER_ID:
db 'LOGGERxx'   ; Logger device driver identifier. 8+ 
Characters.

MAIN:   ; do program stuff

NOT_INSTALLED:  ; driver not loaded, die now with error 
message


As for the installed Driver, TSR or other extension, you just hook int 0x2b. If 
AX=0xFD00 and DS:BX points to an identifier you recognize, then it would clear 
the carry flag and return values in whatever registers required. Otherwise, it 
completely ignore it and just jump to the previous interrupt handler. 

It requires no additions to the kernel, is backwards compatible and should have 
a low probability of any collisions. 

Any thoughts on using it as a very minimal “standard” extension installation 
check? 

:-)

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

[Freedos-devel] Get-together follow-up

[jerome]

Hi Ralph,

Not sure if I explained why just "walking the MCB chain" is not sufficient to 
locate the driver during the meeting.

When the config sys includes "DOS=UMB” the upper memory blocks are part of the 
MCB chain. If that is option is not included, then those blocks are not linked 
to the chain. (Un)Linking can be performed using INT 0x21,AH=0x58. 

https://fd.lod.bz/rbil/interrup/dos_kernel/2158.html 


However, based on what memory management drivers are loaded and config 
settings, (un)linking may not be possible and allocating a UMB may not succeed. 
 If this is the case, the driver will try to allocate a UMB through the XMS 
memory manager. The memory may then be allocated but not part of the MCB chain 
because DOS itself is not managing that region of memory. 

If that fall-back allocation is successful, "walking the MCB chain" will not 
locate the driver. It is a rare combination of system configuration options 
that can permit the fall-back memory allocation to be successful. It would be 
easier to not go through the extra steps and only allocate memory when DOS is 
managing that region. 

I do not recall at present the exact configuration of options and drivers that 
are required, that will fail to allocate the memory through DOS but are 
successful when directly using the XMS driver. I can not seem to duplicate that 
result at present. I should have made notes on it.

The UMB test program can demonstrate most of that stuff. However, it does not 
perform the fall-back of using the XMS manager to try and allocate memory.

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

On a side note, once I determine the best interrupt hook, It would be faster to 
just call that interrupt function to see if it is loaded. That could also 
provide an “API” for other programs to easily write to the Log and perform 
other interactions with the driver. 

:-)

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

Re: [Freedos-devel] I wish I had a boot.log file

[jerome]

Hi All,

Fixed a minor issue in Logger, that would cause the interface program to not 
find the device driver when it was loaded low. 

At present, the interface program just does a brute force memory scan to find 
the driver. There are safeguards in place to prevent false positives and some 
optimizations to help expedite the process. But yes, it is a slow crappy way to 
locate the driver. It is only doing it this way until I decide on what is the 
best and most compatible thing to hook with zero chance of a collision or 
failure to find. Needs more pondering. Under general use, you probably won’t 
even notice the delay. But, there would definitely be a large performance hit 
under heavy use of the interface program.

Anyhow, I whipped up a modified version of the Boot Image for the FreeDOS 1.3 
LiveCD and works with the interim build of the LiveCD. It was just a test. But, 
I figured I would share it to save you some work. You can fetch it from my 
server at https://fd.lod.bz/redist/system/ <https://fd.lod.bz/redist/system/> 
Then simply fire VirtualBox with the diskette and a LiveCD 1.3 (or later 
interim build) attached to check it out. Just make sure the VM is booting the 
floppy first. 

:-)

Jerome

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