
Stuff that I might do some day...

- switch the TCP stack to use picoTCP
    --> or (better?) make FDNPKG a 16-bit application and use real-mode Watt32
DONE

- make it possible to install sources for a package that was installed without sources
    --> store sources separately (*.zib + *.zis instead of a single *.zip)
DONE WITH REINSTALL AND INSTALL WITH SOURCES

- for a given on-disk file, make it possible to check if it belongs to a package
I'll discuss this with FreeDOS people what this means

- (?) look for %DOSDIR%\PACKAGES\%PKGNAME%\REMOVE.BAT and INSTALL.BAT scripts
I'll discuss this with FreeDOS people what this means

- optimize db-related operations (creating db, loading it from file), to speed up the process
    --> or move this to server-side? but what about from-disk installs then? could use same format as today, reading directly from disk instead of compiling a database aggregate
This is a 1.0 feature I should implement this soon, but I am afraid of breaking it.

- look for FDNPKG.CFG first in current EXE dir instead of in %DOSDIR%/BIN (but %FDNPKG.CFG% should still have priority over everything else)
DONE!

- add a way to install a specific version of a package without relying on the latest version autodetection (fdnpkg install pkgname/0.50)
again This is a 1.0 feature I should implement this soon, but I am afraid of breaking it. but I can try with this one!
    cannot be done need work on repo/server side (possible! just need fdrepo updated)

- when the connection to network fails, we should continue with what we have (looks like wattcp is calling exit() if it fails to get an IP via DHCP?)
I dont think this can't be implemented. Because it would not have any package files! You can (re)install packages via locally on a disk! :D



- Implement modification-date version finding
    --> Needs server repo side and the making of index16.gz file son server which has this additional info! :D


- force install!
    --> prompt sent to force install a file if it exists
DONE

- multipackage install!!! >:3
    --> now we getting into big leagues!! :D program should work as "fdnpkg16 reinstall fdnpkg16 fdnpkg" xD
DONE!






- additional todo thanks to willi! :D
1. /? "Press any key except Q to continue" This works, but is unusual for me, as in most cases it shows the options twice and nerves the user. I would do it as follows:
        "Press S to show the short options" (otherwise it exits)
        and from short options:
        "Press L to show the long options" (otherwise it also exits)
        Additional you could offer the options /S and /L to show the short or long options at once. (option=action) Maybe in one line "/S /L" show short / long help" to save             space in the help section.
2.  Update: It would be great to offer a "downgrade" (to one program version earlier) sometimes. For any reason (new program does not work, user does not like new      version etc. Something like remove program and install an older version. See 3.
3.  the repositories at Shidel, your site (not tested) and ibiblio have directories, e.g. repositories/1.3 or  (1.4) or  (latest)/index.html.
So it should be easy to replace 1.4 by latest in fdnpkg16.cfg with a variable and offer the latest folder too (via an additional option/action). This would make it very comfortable to download, e.g. the inofficial kernel. Just an idea. Something like "Update repository"LATEST" kernel".
4. I noticed, that if you have a typo at the options (actions), it reports no error message ("xyz does not exist) but simply exits which maybe a little confusing for newbies.
5. dumpcfg shows a long list. Could you add a pause after each side (something like: | more)?
    DONE

This are only proposals, think about them. I am not angry when you say: this does not work for this or that reason or something like this.

Willi


> 1. Great!
yeah i will implement this feature soon
> 2. yes, it will be problematic and hard to realize something like a downgrade.  I understand, when downloading it later, this will become complex
this one is very hard to implement. as in it will introduce a bunch of bugs
> 3. replacing the fdnpkg16.xyz file is a chance, but uncomfortable. Only people that know that there are different folders for download would have the
> idea to change it. So a small option to change the download section would be nice.
this is not so easy either. i should mention it in the help me
> 4. Simply type "fdnpkg16 dumpcfga" or "dumpcf" (instead of dumpcfg") - and the program gives no error message but directly jumpes back to help.
if there is a typo it dose this on purpose.. to mention to user the help.
> 5. a simple pause after each side would be enough.
i think i can implement this too








experimental dev cleanup todo for dev branch
  it's mostly clean up of old code i made because the project is a little messy where i worked at.
  this is ok it works fine i just need to fix things

clean up old network code not used. like mtcp usage to remove dependancies         --eventually
optimize things for 8088/8086
  database operations
  just over all reduce disk access where unessessary!

eventually get WATT32 guys to fix WATT32 memory leak in some functions!




















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 backstoryc 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 updateh. Well, that was problematic. For a number of packages, it basically skipped updating them because of gfile already existsh errors. Then, it got to updating UPX. It removed the package then the system crashed with an ginvalid opcodeh. So, I rebooted in gsafe modeh (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 ?h, followed by gFDNPKG install ?h to update those packages that the gupdateh skipped because of the gexisting fileh issue. Those steps updated AMBHELP without any problem. Then, I realized I should actually be testing FDNPKG16 instead of running FDNPKG. So, I ran gFDNPKG install FDNPKG16h and switched my focus to that program.

The first problem I encountered was related to this aging netbook. The g1h key only works sometimes and needs banged on repeatedly to register. So, I created an galias fdn=fdnpkg16h in the FDAUTO.BAT and rebooted letting it boot the default boot option with JEMMEX and most drivers high. I then proceeded to try gfdn updateh which did not use my custom online repository config. No problem, jumped back into FDAUTO.BAT and added a gSET FDNPKG16.CFG=c.h To my custom config that uses my server and not IBIBLIO. Rebooted again.

Tried to run gfdn updateh. But, it would also throw a gfile existsh error and offer to install anyway providing a g1=NO, 2=YESh option. Well, the g1h 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 gfdn ri DOSLFNh. This also presented me with a gfile existsh error and the aforementioned options. This seems wrong to me. When the greinstallh 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 gexisting fileh 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 gC:\freedos\ch However, the current running OS is using gC:\FreeDOS\ch. 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 itfs 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 gremoveh followed by ginstallh 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 gsafe modeh with FDNPKG16. This did not work. It had a bunch of gFailed to allocate PACKET DRIVER datag and gNot enough memory to allocate file structures" errors. It also required me to gclearh 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.
done
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 gDOSLFNh 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.
done
7) Possibly add an option to gaborth as well.
8) If not installed, maybe offer to save the download for later.
9) Maybe provide a command line option to gonlyh download the updates and not install them.

10) There is one other thing to check in FDNPKG16 that was an issue in FDNPKG regarding gfile existsh 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 gC:\FreeDOS \bin\xcopy.exeh. FDNPKG and FDINST would see these as conflicts and refuse to update those packages. However, both of those programs had no problem performing a gremoveh then greinstallh 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 spaceh pathname issue.

Thatfs all for now.

Jerome

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













Will implement these impovements.
From Jerome:

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.
    i also need help with this.
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.

    I need a bit of help on this one.

4) FDNPKG seems to get stuck if (1=NO) was selected. Re-launching with any option, it downloaded the gDOSLFNh package again and exited. Had to manually delete the cache.
    i tested this it seems fine.
5) a Zero byte LST file causes FDNPKG to just exit without any messages. Unable to remove, update or install a package.
    should be able to handle this with a remove command or reinstall command


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 gaborth as well.
    hard todo as httpget.exe is a seperate program called by a batch script. and it agressively calls it.
8) If not installed, maybe offer to save the download for later.
    DONE

9) Maybe provide a command line option to gonlyh download the updates and not install them.
    DONE

10) There is one other thing to check in FDNPKG16 that was an issue in FDNPKG regarding gfile existsh 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 gC:\FreeDOS \bin\xcopy.exeh. FDNPKG and FDINST would see these as conflicts and refuse to update those packages. However, both of those programs had no problem performing a gremoveh then greinstallh 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 spaceh pathname issue.
    i need todo this now! :D
