Mail Archives: djgpp-workers/1999/04/12/13:12:00
>> I will do this too, but for other purpose - I will insert %PATH% in any
>> path setting lines where it is missing.
>
>Why?! it will change the path it could even break the system, why if the
user
>have a path that overwrites other you want to break it?
It's a really bad thing to have such autoexec.bat where next path=...
overwrites
previous. My installer will not create a new problem, it will reveal an old
one.
There is a lot of installation utilities (especially Borland's) which just
update
first autoexec.bat line and that's all. If user user doesn't want old path,
he has
to REM it. And he will be told so in LBInstDJ's warning. If it doesn't
matter for
him - well, it's up to him. I'd like to hear your opinion.
OK, now about multiconfiguration...
>And your solution doesn't work in multiconfiguration cases, while the thing
>I'm propposing looks like will work at least in most of these cases. See
this
>example:
> (...)
1) If user knows how to setup multiconfigurations, he will be able to
install
DJGPP by himself.
2) There are a lot of issues about autoexec.bat and I even didn't document
well
registry issues yet (Altough code is complete). So, at first, I will target
one-configuration autoexec.bat, for which my way works.
3) For multi-confs my idea is:
* Read from config.sys all configuration names and their descriptions
* List all names and descriptions and ask user, which to update, with
possible case to update all users' settings (adding my stuff before
goto %config%)
* Use the same rule as for updating whole autoexec.bat, just stay in
the bounds of one conf.
>That's why an installer *must* be complemented by djverify.
It *will* be, but later. Now I will mention it in my doc and recommend to
use it after installation. But there is a lot of useful code for my prg.
BTW, about user's interface: how about porting it to turbo vision?
Laurynas Biveinis
- Raw text -