On Sun, 01 Feb 2015 11:39:17 +0100, Jacob Carlborg wrote:

> On 2015-02-01 10:42, ketmar wrote:
>> today i was in need of a little utility that must download the file using "wininet.dll". nothing fancy, just send a request and receive the contents. no, curl was not a choice
> 
> I don't know your exact requirements but I use Tango [1] to download files in my D projects. It's cross-platform and doesn't require any external libraries except system libraries.
> 
> [1] http://dsource.org/projects/tango/docs/current/

i have my own library to work with http. but you can substitute any other windows dlls in place of of wininet, the story will not change. the story is about (lack of) usability.

On Sunday, 1 February 2015 at 10:54:20 UTC, ketmar wrote:
> "-Wl,--enable-auto-import -Wl,--enable-stdcall-fixup"

That's pretty cool.

> actually, D support for GNU/Linux is far better than windows one.

It's gotten much better.

Here's what you had to do to create a DLL in D:

http://digitalmars.com/d/1.0/dll.html

(The page is old, but the situation didn't change for a long time, until fairly recently.)

On Sunday, 1 February 2015 at 09:44:27 UTC, ketmar wrote:

> this pool. there is no water too.

[OT] Just for the sake of it:

https://www.youtube.com/watch?v=00509MQxRB8

On Sunday, 1 February 2015 at 09:42:49 UTC, ketmar wrote:
> today i was in need of a little utility that must download the file using
> "wininet.dll". nothing fancy, just send a request and receive the
> contents. no, curl was not a choice. and -- oh, well, wininet is a dll
> which any windows box has, right? at least any windows box with XP and
> higher, which is ok.
>
> allright, i know that winapi bindings is a separate project, and it's ok
> for me: i fired my git and cloned the repo. surely, "wininet.d" was there.
>
> then i used my shiny fresh DMD build (i just did that to check my fix for
> "read after free" patch) to compile a simple test program.
>
> aaah! there is no "wininet.lib"! ok, installing msvc is a time and space
> consuming thing, and i know that dmc has that cool "implib" utility,
> which i can use to make the corresponding .lib file (ah, i love windows
> developement!).
>
> so i ran "implib.exe /s wininet.lib c:\windows\system32\wininet.dll",
> copied the resulting "wininet.lib" to "lib" directory of dmd and tried to
> compile my sample:
>
> dmd.exe test.d ... /L+wininet.lib


Shouldn't you compile with the following cmds ?

dmd.exe test.d wininet.lib wininet.di -I<path_to_di_file>

?

On Sun, 01 Feb 2015 11:04:38 +0000, Vladimir Panteleev wrote:

> On Sunday, 1 February 2015 at 10:54:20 UTC, ketmar wrote:
>> "-Wl,--enable-auto-import -Wl,--enable-stdcall-fixup"
> 
> That's pretty cool.

yes. i was amazed by the fact that i finally can forget about all that "implib/deffile" crap. GNU/Linux has that for ages. and your "extern" proposal will fix windows situation too... if it ever be accepted, of course.

the best thing, of course, is to kill that ancient toolchain altogether and switch to binutils, they are already working for mingw and they are free. and there is COFF writer already too. so only one little step is needed: drop dmc and build dmd with mingw. and with dmc all it's tools will go.

besides, this will allow makefile unification, as alot of "posix.mak" can be reused for mingw builds. i did that myself while hunting for multithreading heisenbug. the side effect of switching to mingw was faster dmd.exe: compiling phobos took only 2/3 of time comparing to dmc version.

On Sun, 01 Feb 2015 11:28:51 +0000, jkpl wrote:

> Shouldn't you compile with the following cmds ?
> 
> dmd.exe test.d wininet.lib wininet.di -I<path_to_di_file>
> 
> ?

that doesn't really matter how i'll pass that .lib file to linker. and i replaced part of the command line with ellipses, as there is no reason to quote it all.

On Sunday, 1 February 2015 at 11:28:51 UTC, jkpl wrote:
> Shouldn't you compile with the following cmds ?
>
> dmd.exe test.d wininet.lib wininet.di -I<path_to_di_file>

wininet.lib is unnecessary because wininet.d has `pragma(lib, "wininet");`.

wininet.di is unnecessary because it does not contain any code, only declarations - an import inside test.d is sufficient. (This may not be true if you pull in .init of struct types, for example)

On Sun, 01 Feb 2015 11:25:04 +0000, eles wrote:

> On Sunday, 1 February 2015 at 09:44:27 UTC, ketmar wrote:
> 
>> this pool. there is no water too.
> 
> [OT] Just for the sake of it:
> 
> https://www.youtube.com/watch?v=00509MQxRB8

ah, this is not OT at all, it perfercly illustrates my point! ;-)

On Sunday, 1 February 2015 at 11:37:46 UTC, Vladimir Panteleev wrote:
> On Sunday, 1 February 2015 at 11:28:51 UTC, jkpl wrote:
>> Shouldn't you compile with the following cmds ?
>>
>> dmd.exe test.d wininet.lib wininet.di -I<path_to_di_file>
>
> wininet.lib is unnecessary because wininet.d has `pragma(lib, "wininet");`.
>
> wininet.di is unnecessary because it does not contain any code, only declarations - an import inside test.d is sufficient. (This may not be true if you pull in .init of struct types, for example)

okay but the -Ipath is still missing, wouldn't be a bit the reason why dmd complains about undefined symbols ?

On Sunday, 1 February 2015 at 11:40:13 UTC, jkpl wrote:
> okay but the -Ipath is still missing, wouldn't be a bit the reason why dmd complains about undefined symbols ?

No, the errors are coming from the linker, not the compiler.