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

Reply via email to