i got a bleeding edge version with some improvements
it turns out you can remove the 0 byte file of a package with the rm or
ri commands
i added y and n support for the choice system
1) Case-less filename comparison when checking the TO-BE-INSTALLED files
against the NOW-INSTALLED files in the relevant %DOSDIR%\PACKAGES\*.LST
database file.
i honestly need help with caseless file opening for fileexists function
it uses fopen
2) Do not update the CACHE when the online scan fails.
DONE on next compile as of 5/13/2026
3) A simple check for sufficient memory and not just repeated failures
would be nice. Or at least, stop when the first critical memory related
error occurs.
there is a little warning at the beginning. i should make this abort the
program ill do this rn
4) FDNPKG seems to get stuck if (1=NO) was selected. Re-launching with
any option, it downloaded the “DOSLFN” package again and exited. Had to
manually delete the cache.
i tested this it seems fine. i added y and n support to by pass this
5) a Zero byte LST file causes FDNPKG to just exit without any messages.
Unable to remove, update or install a package.
it seems to work especially if you rm or ri command it out which removes
the file
i hope this is good. sometimes u gotta brute force it
Some possible improvements:
6) While 1 & 2 are acceptable responses to the NO/YES question (except
for my broken keyboard), permitting the language equivalent of
N/Y/NO/YES (caseless) would be nice.
fixed and DONE 1 for no 2 for yes
7) Possibly add an option to “abort” as well.
this will be hard as httpget.exe is a separate program.
8) If not installed, maybe offer to save the download for later.
i can add this tomarrow
9) Maybe provide a command line option to “only” download the updates
and not install them.
same with adding this tomarow
10) There is one other thing to check in FDNPKG16 that was an issue in
FDNPKG regarding “file exists” problems. A long while back (I think
maybe FreeDOS 1.2), there was a typo in the logic that created the
environment variable data used by FDINST at OS install time. It resulted
in an extra space in the file names in the LST file. Those entries
looked something like “C:\FreeDOS \bin\xcopy.exe”. FDNPKG and FDINST
would see these as conflicts and refuse to update those packages.
However, both of those programs had no problem performing a “remove”
then “reinstall” when the extra space was present. That OS installer
issue was resolved a long time ago. But, it is something a user could do
by accident when updating environment variables or the config file
related to FDNPKG16. It would be good to check that FDNPKG16 does not
suffer from the same "extra space” pathname issue.
this will take some time to implement but i did do some stuff above i
hope u can like the program more now! :3
https://github.com/sparky4/fdnpkg16/raw/refs/heads/main/fdnpkg16.exe
https://github.com/sparky4/fdnpkg16/raw/refs/heads/main/fdinst16.exe
latest latest versions! lease try these see if you can use this! <3
On 5/13/26 11:09 AM, Jerome Shidel via Freedos-devel wrote:
On May 13, 2026, at 11:25 AM, victoria crenshaw via Freedos-devel
<[email protected]> wrote:
FINALLY! FEEDBACK!
i will get to work as soon as i can!
Great. :-)
adding improvements list into repository. will implement during the week.
FYI, #4 & #5 should say FDNPKG16. Not sure if I made some typos or just failed
to notice autocorrect changed them.
stating tomorrow! <3
Sounds good.
thank you
You’re welcome. Have fun. My little netbook will be waiting patiently for the
next version.
:-)
On 5/13/26 9:38 AM, Jerome Shidel via Freedos-devel wrote:
While FDNPKG16 has been available for a while, I have been very busy and have
only just now found a little time to do some testing. The results were a little
mixed compared to FDNPKG.
First, a little backstory… I just received a new wired/wireless mouse. I tested
that mouse on macOS and Linux without issue. So for fun, I drug out my FreeDOS
testing netbook to see what would happen. No joy there. The machine would not
POST when either the dongle or mouse was plugged into it. Very odd for a
computer that originally came with Windows XP. However, since the machine was
already sitting on my desk and powered up, I figured I would bring the original
FreeDOS 1.4 packages up to date.
I was just going to update everything using "FDNPKG update”. Well, that was
problematic. For a number of packages, it basically skipped updating them because of
“file already exists” errors. Then, it got to updating UPX. It removed the package
then the system crashed with an “invalid opcode”. So, I rebooted in “safe mode” (no
XMS and only a few drivers loaded low). Then, I ran FDNET which knows how to get
networking up on this machine. That leaves this machine with about 443K of lower
memory available and no UMB, XMS or EMS.
So, I began the process of using "FDNPKG remove ?”, followed by “FDNPKG
install ?” to update those packages that the “update” skipped because of the
“existing file” issue. Those steps updated AMBHELP without any problem. Then, I
realized I should actually be testing FDNPKG16 instead of running FDNPKG. So, I ran
“FDNPKG install FDNPKG16” and switched my focus to that program.
The first problem I encountered was related to this aging netbook. The “1” key
only works sometimes and needs banged on repeatedly to register. So, I created
an “alias fdn=fdnpkg16” in the FDAUTO.BAT and rebooted letting it boot the
default boot option with JEMMEX and most drivers high. I then proceeded to try
“fdn update” which did not use my custom online repository config. No problem,
jumped back into FDAUTO.BAT and added a “SET FDNPKG16.CFG=….” To my custom
config that uses my server and not IBIBLIO. Rebooted again.
Tried to run “fdn update”. But, it would also throw a “file exists” error and
offer to install anyway providing a “1=NO, 2=YES” option. Well, the “1” key
(which is what I wanted) does not really work on this machine. So, I had to
CTRL+C to exit. It would be nice if it would also except N/Y as responses.
So, I tried the reinstall feature for the first program that needed updating
with “fdn ri DOSLFN”. This also presented me with a “file exists” error and the
aforementioned options. This seems wrong to me. When the “reinstall” option is
used. It should uninstall the package and reinstall it. Existing files which
are part of the package should be removed and replaced automatically. However,
it is good to check for any conflicting files before re-installing.
The main part of the “existing file” problem is from an issue that FDNPKG16
inherited from FDNPKG. They are performing a case-specific file name comparison
although the OS is using caseless file and path names. So, during the original
install these packages were installed under “C:\freedos\…” However, the current
running OS is using “C:\FreeDOS\…”. Same path. But, the programs are failing to
notice that and sees them as conflicting files.
So for now, I will hold off on updating all if it’s packages. It is too much of
a hassle to try and update. That kind-of needs to run the process and download
the package. Then, stop it while I try remembering what was conflicted. Then,
run “remove” followed by “install” which needs to download the package again.
The same process that is required by FDNPKG.
But, there was one other test I wanted to try before calling it a day. As I
mentioned earlier, I did run FDNPKG without any XMS. So, I rebooted and tried “safe
mode” with FDNPKG16. This did not work. It had a bunch of “Failed to allocate PACKET
DRIVER data“ and “Not enough memory to allocate file structures" errors. It
also required me to “clear” its cache when I rebooted and had JEMMEX loaded.
As I see it, there are a couple issues with FDNPKG16 that need addressed:
1) Case-less filename comparison when checking the TO-BE-INSTALLED files
against the NOW-INSTALLED files in the relevant %DOSDIR%\PACKAGES\*.LST
database file.
2) Do not update the CACHE when the online scan fails.
3) A simple check for sufficient memory and not just repeated failures would be
nice. Or at least, stop when the first critical memory related error occurs.
4) FDNPKG seems to get stuck if (1=NO) was selected. Re-launching with any
option, it downloaded the “DOSLFN” package again and exited. Had to manually
delete the cache.
5) a Zero byte LST file causes FDNPKG to just exit without any messages. Unable
to remove, update or install a package.
Some possible improvements:
6) While 1 & 2 are acceptable responses to the NO/YES question (except for my
broken keyboard), permitting the language equivalent of N/Y/NO/YES (caseless) would
be nice.
7) Possibly add an option to “abort” as well.
8) If not installed, maybe offer to save the download for later.
9) Maybe provide a command line option to “only” download the updates and not
install them.
10) There is one other thing to check in FDNPKG16 that was an issue in FDNPKG
regarding “file exists” problems. A long while back (I think maybe FreeDOS 1.2),
there was a typo in the logic that created the environment variable data used by
FDINST at OS install time. It resulted in an extra space in the file names in the
LST file. Those entries looked something like “C:\FreeDOS \bin\xcopy.exe”. FDNPKG
and FDINST would see these as conflicts and refuse to update those packages.
However, both of those programs had no problem performing a “remove” then
“reinstall” when the extra space was present. That OS installer issue was resolved a
long time ago. But, it is something a user could do by accident when updating
environment variables or the config file related to FDNPKG16. It would be good to
check that FDNPKG16 does not suffer from the same "extra space” pathname issue.
That’s all for now. :-)
Jerome
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
