Am 14.08.2014 um 12:52 schrieb Mateusz Viste <mate...@viste.fr>: > Thanks for your feedback!
Thanks for yours :-) > > On 08/14/2014 12:05 AM, Ulrich wrote: >> FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN. > > This is not really about FDNPKG, but more about "how packages are > structured". Indeed, I tend to avoid putting to much stuff into > %FREEDOS%\BIN, and only put there stuff that is supposed to be part of > the FreeDOS "core" (ie BASE, that is similar functionality than what > MSDOS was providing). Yes I think this a good idea. About the PATH: What about creating an external batchfile like C:\PKGS.BAT, that is automatically called by AUTOEXEC.BAT? FDNPKG could update the PATH statement according to each package. The content, for example: PATH=%PATH%;C:\FDOS\DRIVERS\CRYNWR PATH=%PATH%;C:\FDOS\PROGS\DOSZIP and so on. As you see above, I would put DOSZIP in PROGS instead of C:\. What's the use of these categories, if we do not use them? > Now the question is where to put any 3rd party apps that are still > supposed to be callable from anywhere in the directories tree? One > option could be to create another "BIN-like" directory for these No, I think creating another BIN directory like /usr/bin in GNU/Linux, where we'd put all third-party executables, would complicate things. The next step would be to put configuration files in /ETC. No I think it would be wise, to stay with the DOS way and keep each program and its configuration files in one dedicated directory. > >> The package CTMOUSE is installed into C:\FDOS\BIN\CTMOUSE (yet another >> location for programs). There is no universal MOUSE.EXE like in FreeDOS 1.1, >> instead you need to activate the file according to your language (CTM_EN.EXE >> or CTM_DE.EXE, etc.). > > Yes, I agree this is ugly. unfortunately CTMOUSE doesn't provide a > single executable with NLS support, and provide instead x versions for > every language (this is most probably for saving RAM, which is good I > guess). Problem is - how to install such multi-version package? Shouldn't CTMOUSE just go into C:\FDOS\DRIVERS\CTMOUSE? I think opening another drivers/programs directory under C:\FDOS\BIN isn't so helpful. > I renamed the "GAMES/MIRROR" package to "GAMES/MIRMAGIC" right now. This > should remove any possible source of confusion. Thanks. I installed the correct mirror.exe just now. And BTW: Shouldn't DOSLFN be in the UTIL repository? I can find it at the FreeDOS homepage under UTIL but not in the repo. > I see - the UIDE package contains already RDISK and XMGR. This is > probably an error, since UIDE should be about CDROM stuff, nothing else > (esp. since RDISK and XMGR are already available in separate packages). > > I fixed it now by removing RDISK and XMGR from the UIDE package. > I am not sure about this. AFAIK Jack R. Ellis, the developer of UIDE also takes care of RDISK and XMGR and I think he puts it in one package. It is also updated frequently. So maybe the other way round would be a better way to go: Removing XMGR and RDISK as separate packages and installing just UIDE with BASE. But maybe other people have an opinion on this? > I really don't know why VBox craps everytime FDNPKG is ran.. This is > something I noticed on vbox only and nowhere else (works fine on a real > machine, DOSemu, DOSBox and Qemu). But I will do some research. > FDNPKG works fine from C: in VirtualBox. I am really impressed that I can update my DOS programs now just like I do with apt on my Debian server. But obviously the all_cd boot configuration didn't work too good with VirtualBox, so installation is another puzzle to solve. thanks, kind regards! Ulrich > > > >> Am 13.08.2014 um 08:48 schrieb Mateusz Viste <mate...@viste.fr>: >> >>> On 08/13/2014 12:07 AM, Rugxulo wrote: >>>> Are you saying this is a bug in FD FDISK or VBox? Because as long as >>>> it's not FD FDISK getting inherently confused, you could maybe do a >>>> simple workaround: copy it to and run from RAM disk. Would that avoid >>>> the issue? Just curious. >>> >>> I have no idea, truly. FDISK 1.2.1 works. FDISK 1.3.1 doesn't. But as >>> you know, this kind of problems is rarely black or white, so >>> everything's possible. >>> >>> I think the best is to downgrade FDISK to v1.2.1 on FDNPKG repos. Will >>> do this today. The v1.3.1 does print warnings about being "unstable/beta >>> version" all over the screen, which might indicate it's not totally >>> finished yet. >>> >>> Mateusz >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Freedos-user mailing list >>> Freedos-user@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freedos-user >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freedos-user mailing list >> Freedos-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-user >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ------------------------------------------------------------------------------ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
