> 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
