Windows & importing dives

[Lubomir I. Ivanov]

On 5 March 2013 21:16, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>
>> On 5 March 2013 19:24, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>> On 5 March 2013 18:46, Dirk Hohndel <dirk at hohndel.org> wrote:
>>>> Miika Turkia <miika.turkia at gmail.com> writes:
>>>>
>>>>> Seems that XSLT files are not found in Windows if subsurface is
>>>>> invoked by opening a data file (and selecting subsurface as a program
>>>>> to handle it). E.g. I use file exploder to double click on
>>>>> testdives.DLD and select subsurface to handle the DLD files.
>>>>
>>>> Interesting. Windows is such an odd OS in the way things are found - I
>>>> wonder what the CWD is when starting an app like this. And how it is
>>>> able to switch back to its own executable path - as that is how we
>>>> attempt to find the files.
>>>>
>>>> Lubomir, do you know more about this?
>>>>
>>>
>>> i think for that to work in a clean way, we need to obtain the process
>>> path (e.g. /proc/self/exe)
>>>
>>> char buf[MAX_PATH];
>>> GetModuleFileName(NULL, buf, MAX_PATH);
>>>
>>> the buffer includes the executable name e.g. "<c:\....>\myfile.exe" so
>>> it has to be stripped.
>>>
>>> the result then has to be put _in front_ at mark <P> using concat (of
>>> sorts), but obviously on runtime:
>>> static const char *xslt_path = <P> XSLT ":xslt:.";
>>>
>>> but also check if the XLST build for Windows accepts full paths with
>>> drive letters.
>>>
>>
>> i've just realized that the localization is not working as well when
>> e.g. opening a .DLD file from the desktop, which means that the
>> process working directory has to be changed, otherwise the location of
>> all relative path assets is lost.
>
> That's what I figured when I saw Miika's report - it's all using the
> same logic.
>
>> GetModuleFileName still has to be used, but then there is a method
>> called SetCurrentDirectory which will have to accept the stripped
>> path, unless there is a method that does both things at once.
>
> Let's use the lowest common denominator that gets us XP and later :-)
>
> I assume you'll send me patches at some point?
>

just sent a patch,
i've tested it when the executable is at "c:\program files
(x86)\subsurface\subsurface.exe", while a .DLD file is on the Desktop
and is associated with this executable.

technically we can auto-associate some extensions from NSIS, but that
can be a bit intrusive since the user may not want .DLD associated
with Subsurface.

according to the API, this should work back to early XP; also UTF-16
paths should work as well.

lubomir
--