Hi,

this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file.

So far I have the following file:

    import std;

    void main(string[] args) {
        import core.runtime;
        static immutable libcurl = import("libcurl.dll");

        import std.file: write;
        auto libpath = tempDir.buildPath("libcurl.dll");
        libpath.write(libcurl);

        auto libcurlMem = rt_loadLibrary(libpath.toStringz);

        import std.net.curl;
        "https://dlang.org/".byLine.count.writeln;

        rt_unloadLibrary(libcurlMem);
        remove(libpath);
    }

Compiled with:  dmd.exe -Jlibdir test.d

It almost work, I can write, load and use the library, but when it comes to
removing it nothing works.

std.file.FileException@std\file.d(1045): C:\users\cym13\Temp\libcurl.dll: Access denied.
----------------
0x00402377 in EntryPoint
0x00413BC7 in EntryPoint
0x00413B49 in EntryPoint
0x004139E3 in EntryPoint
0x0040B77F in EntryPoint
0x7B4754C2 in call_process_entry
0x7B477FC6 in ExitProcess
0x7B4754CE in call_process_entry

I tried using an explicit File handle to explicitely close the file after
writing to it but that doesn't change anything.

I'm pretty sure I'm missing something basic about the way windows handles
open files but I don't know what, could someone explain why this doesn't work
the way I expect it to?

On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote:
> Hi,
>
> this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file.
>
> [...]

I can't explain the behaviour, but you could store the temp file name in a string array and remove these file in the module destructor. That's the way how dub handles temp files/folders.

https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98

Kind regards
Andre

On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote:
> Hi,
>
> this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file.
>
> So far I have the following file:
>
>     import std;
>
>     void main(string[] args) {
>         import core.runtime;
>         static immutable libcurl = import("libcurl.dll");
>
>         import std.file: write;
>         auto libpath = tempDir.buildPath("libcurl.dll");
>         libpath.write(libcurl);
>
>         auto libcurlMem = rt_loadLibrary(libpath.toStringz);
>
>         import std.net.curl;
>         "https://dlang.org/".byLine.count.writeln;
>
>         rt_unloadLibrary(libcurlMem);
>         remove(libpath);
>     }
>
> Compiled with:  dmd.exe -Jlibdir test.d
>
> It almost work, I can write, load and use the library, but when it comes to
> removing it nothing works.
>
> std.file.FileException@std\file.d(1045): C:\users\cym13\Temp\libcurl.dll: Access denied.
> ----------------
> 0x00402377 in EntryPoint
> 0x00413BC7 in EntryPoint
> 0x00413B49 in EntryPoint
> 0x004139E3 in EntryPoint
> 0x0040B77F in EntryPoint
> 0x7B4754C2 in call_process_entry
> 0x7B477FC6 in ExitProcess
> 0x7B4754CE in call_process_entry
>
> I tried using an explicit File handle to explicitely close the file after
> writing to it but that doesn't change anything.
>
> I'm pretty sure I'm missing something basic about the way windows handles
> open files but I don't know what, could someone explain why this doesn't work
> the way I expect it to?

Since deploying a dll is a suspect behaviour outside a normal installation process, most probably you have a lock on the file put by windows defender or an antivirus if installed.

FreeLibrary doesn't guarantee that the dll file is closed, maybe other windows processes are accessing it (like prefetch).

Anyway, you are deploying a dll just to read a file, It's over engineering, use WinAPI UrlDownloadToFile instead or any other winapi functions.

On Thursday, 9 May 2019 at 11:11:56 UTC, Rumbu wrote:
> Since deploying a dll is a suspect behaviour outside a normal installation process, most probably you have a lock on the file put by windows defender or an antivirus if installed.

Thanks for your input but I'm absolutely certain that it's not related to AV since I made sure to test in an AV-free environment (and I'd expect AV to kick in before loading the DLL, but I may be wrong on that).

> FreeLibrary doesn't guarantee that the dll file is closed, maybe other windows processes are accessing it (like prefetch).
>
> Anyway, you are deploying a dll just to read a file, It's over engineering, use WinAPI UrlDownloadToFile instead or any other winapi functions.

Well, that's just a test script, it's feature or DLL doesn't matter.

On Thursday, 9 May 2019 at 11:07:53 UTC, Andre Pany wrote:
> On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote:
>> Hi,
>>
>> this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file.
>>
>> [...]
>
> I can't explain the behaviour, but you could store the temp file name in a string array and remove these file in the module destructor. That's the way how dub handles temp files/folders.
>
> https://github.com/dlang/dub/blob/master/source/dub/internal/utils.d#L98
>
> Kind regards
> Andre

No luck there.

On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote:
> ...

To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result.
For reference my windows system is a 64b windows 10.

On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote:
> On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote:
>> ...
>
> To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result.
> For reference my windows system is a 64b windows 10.

You could try to use the find handle function in Process Explorer to figure out what process has the file open:

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote:
> On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote:
>> On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote:
>>> ...
>>
>> To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result.
>> For reference my windows system is a 64b windows 10.
>
> You could try to use the find handle function in Process Explorer to figure out what process has the file open:
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue.

On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote:
> On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote:
>> On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote:
>>> On Thursday, 9 May 2019 at 11:31:20 UTC, Cym13 wrote:
>>>> ...
>>>
>>> To dismiss any doubt about AV or other processes coming into play I took the binary and ran it with wine on linux with the exact same end result.
>>> For reference my windows system is a 64b windows 10.
>>
>> You could try to use the find handle function in Process Explorer to figure out what process has the file open:
>>
>> https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
>
> I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue.

Can you reproduce the issue with other Dlls or is it only reproducible with curl dll? Does the issue with curl dll also exists if you do not call the curl function?

Kind regards
Andre

On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote:
> On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote:
>> On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote:
>>> [...]
>>
>> You could try to use the find handle function in Process Explorer to figure out what process has the file open:
>>
>> https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
>
> I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue.

Which C runtime are you using?

The old and buggy DigitalMars one or the official MS one?