[RFC] Idea how to fix PATH (and other) problems

[Christian Ehrlicher]

Von: Andreas Pakulat <apaku at gmx.de>
> On 08.08.07 06:32:51, Christian Ehrlicher wrote:
> > Andreas Pakulat schrieb:
> > >On 07.08.07 10:50:38, Christian Ehrlicher wrote:
> > >>Hi,
> > >>
> > >>Due to recent discussions on k-c-d where to put shared libs on win32,
> I 
> > >>thougt it would be nice to think about what else is different on win32
> / 
> > >>where we have to take care of:
> > >>
> > >>- we have to modify the PATH env var - this makes it impossible to
> move 
> > >>around our install dir
> > >>- we have to take care that we use the correct dependency libs
> > >>- we've two different compilers which are not ABI compatible
> > >>- the application icon is not included in the executable because it's
> handled 
> > >>totally different on non win32
> > >>
> > >>All this makes it hard for a normal user to use kde apps on win32.
> > >>
> > >>My idea is to create a wrapper executable which handles all the things
> above 
> > >>for us. This wrapper is merged with the executable on install time and
> is 
> > >>written with pure win32 api to avoid dependencies. On execution the
> wrapper 
> > >>sets up all things needed to execute the programm (maybe saving some
> settings 
> > >>in the registry to avoid delays on the next run). It sets up the
> correct 
> > >>PATH, looks if all our dep libs are available (in the path) and also
> knows if 
> > >>it's a mingw or msvc binary (and therefore set the path to 
> > >>kde4-install/lib/msvc or kde4-install/lib/mingw).
> > >>After all is done, the real executable is executed with CreateProcess 
> > >>directly from the memory - like a packer for executables. When the app
> is 
> > >>crashing, it should also be possible to get some more informations
> because we 
> > >>launched the app and therefore can play Dr.Watson.
> > >Hmm, sounds like an ok plan to me, as long as this really stays within
> > >the limits of changing some library paths, PATH and packing the
> > >executable. PutHuhn just said some very scary things on IRC (he
> > >mentioned upx and relocating , fixing import tables and what not) and I
> > >don't think thats a good way to make it easier for users (he also said
> > >that would be trial/error and pretty much black magic stuff going on).
> > As I only want to have one executable we'Ve two options
> > a) 'unpack' the real executable into a temp directory and execute it
> > b) execute it from memory
> > 
> > I'd prefer the second, but for the start the first will work too
> 
> Uhm, but CreateProcess doesn't work for execut memory, or does it? I
> mean that solution that PutHuhn presented for executing from memory
> sounded extremly scary and I'd rather have the packager copy the .dll's
> around for the packages instead of that ugly solution.
> 
But with your solution you don't solve anything - I as the user want to execute my program by clicking on my executable and not on another one somewhere else.
As I said - for now we can extract the real executable to the disk and execute it, and later we can try to add in-memory execution.

Christian
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail