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
