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

Ralf Habacker ralf.habacker at freenet.de
Wed Aug 8 15:15:34 CEST 2007


Christian Ehrlicher schrieb:
> 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.
>   
Are you really working in this way with complex gui apps on windows ?
The regular way is that some kind of installer installs an application, 
creates some start menu entries with which the related application is 
started.

This is one of the targets the kdewin installer has. If a bin package is 
installed, the installer looks if there are desktop files inside and 
creates related entries into the windows start menu proxied by a common 
wrapper application i refered.

What other use cases are there ? If for example all shared qt libraries 
are in lib dir it is not possible to start assistant by clicking on the 
assistant.exe in the bin. Instead if there would be a start menu entries 
all reauired settings like path setting and so one are possible but 
hidden to the user. Is this bad ?

Ralf











More information about the Kde-windows mailing list