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

no luck.

  Error 42: Symbol Undefined _InternetReadFile@16
  Error 42: Symbol Undefined _InternetCloseHandle@4
  ... and so on

wait, what?! i just successfully created that stupid import library!

ok, maybe i read digital mars site wrong and i shouldn't use "/s" switch with "implib"? ah, fine, let's try...

no luck. the same errors. WTF?! what i did wrong here?! ok, let's think a minute... yes! dmd wants mangled symbols, and wininet.dll has unmangled symbols. so optlink searching for "_InternetReadFile@16", while it should search for "InternetReadFile". got that.

now, when i identified the problem, i see that i must fix it on D side. let's try that nice `pragma(mangle, "xxx")` thingy, that's the exact situation when i need that!

i tried several mangle variants, manually editing "wininet.d" file. recreated "wininet.lib" several times. you know what? still no luck.

shit, that "simple utility" is not so simple after all. it already took much more time than downloading and installing msvc can take. damn it!

after some experiments i found that DMD simply ignores `pragma(mangle)` for `extern(Windows)` definitions. great news. so what i have to do now?

i took that error output and transformed it to "wininet.def" file with simple regexp. then i generated "wininet.lib" once again. then i tried to compile my sample once again. and this time i got working ".exe". great. a simple utility which using one of standard windows dlls. i can write it in no time, right?

that was current DMD git head, which is considered almost ready for releasing. super. brilliant. it's really easy to use. now i see why DMD doesn't need a windows debugger: you simply can't debug a program that you can't compile.

years in developement. 2.067 release. still can't compile simple utility without solving stupid puzzles. manual creating of .def files. my C developement mates making fun of me, showing me how their mingw doesn't need any ".lib" files at all: mingw linker can parse .dlls! my younger mate reads this wonderful verse to me:

  "You are old, father William," the young man said,
  "And your hair has become very white;
  And yet you incessantly stand on your head —
  Do you think, at your age, it is right?"

what can i answer to it?

  "In my youth," father William replied to his son,
  "I feared it would injure the brain;
  But now that I'm perfectly sure I have none,
  Why, I do it again and again."

p.s. "and where is the fish?" one can ask me. alas, there is no fish in this pool. there is no water too.

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".

You can find wininet.lib in the "lib" directory of the bindings repository. There's also a .def file in the "def" directory.

I have a WinINet wrapper here, which loads the DLL dynamically (to avoid the import library dependency):

https://github.com/CyberShadow/ae/blob/master/sys/net/wininet.d

It uses a common interface with two more network implementations (curl and native), so you can swap between them easily.

On Sunday, 1 February 2015 at 09:42:49 UTC, ketmar wrote:
> so i ran "implib.exe /s wininet.lib c:\windows\system32\wininet.dll",

This will not work and is not D's fault. The DLL does not contain information required to create a working import library (the size of parameters on the stack is included in the mangled name).

Another thing you could've done is convert the MSVC .lib to COFF:

C:\dm\bin\coffimplib.exe "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\WinInet.Lib" wininet.lib

BTW, next time please post in digitalmars.D.learn. The bug report about extern(Windows) overriding pragma(mangle) belongs in Bugzilla. The well-known fact that D does not include Windows headers is merely a task waiting for someone to champion it, feel free to take it if you care strongly about this.

On Sunday, 1 February 2015 at 10:03:33 UTC, Vladimir Panteleev wrote:
> BTW, next time please post in digitalmars.D.learn.

OK, so I saw that thread only now. I retract this bit.

On Sun, 01 Feb 2015 09:52:46 +0000, Vladimir Panteleev wrote:

> 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".
> 
> You can find wininet.lib in the "lib" directory of the bindings repository. There's also a .def file in the "def" directory.

there is no such directory. what i did when i found that i need winapi
bindings is "google://dlang+windows+bindings". that gives me link to
http://www.dsource.org/projects/bindings/wiki/WindowsApi
then i read this there: "Just the win32 package (usable as a
submodule) ... (updated hourly)". i took a look at "CS-svnmirror/dsource-
bindings" and found alot of things i don't need there. then i took a look
at "CS-svnmirror/dsource-bindings-win32" -- bingo! but there is no "lib"
directory and no ".def" files.

sure, it's entirely my fault. instead of just installing the compiler and tools i had to check all repos, download the big one, then cherry-pick the necessary, took .libs and so on. oh, that's really what i'm doing when i want to write a simple utility with mingw... or? or i'm just executing mingw installer and got all that things out of the box.

now let's imagine that i don't know what all that ".libs" are for and why i need 'em. i used to use mingw, and mingw "just works". and now i decided to give D a try -- i sucessfully used it in GNU/Linux, and windows is more widespread, so there definetely shouldn't be any problems.

or i used msvc, where i don't have to think about ".libs" too.

now i tried D and... well... it might be fun language and all that, but it's toolchain is definitely hostile. it's almost like "hahaha! you aren't smart enough to use our Cool Language, you looser!" ok, now you lost me. i'm really not smart enough to figure out how this smart plan ("gain popularity by alienating newcomers") ought to work.

On Sun, 01 Feb 2015 10:03:30 +0000, Vladimir Panteleev wrote:

> This will not work and is not D's fault. The DLL does not contain information required to create a working import library (the size of parameters on the stack is included in the mangled name).

i wonder how mingw linker is able to use .dlls without corresponding .lib files to link windows executables. maybe it's a weird art of forbidden black magic or something...

> BTW, next time please post in digitalmars.D.learn. The bug report about extern(Windows) overriding pragma(mangle) belongs in Bugzilla. The well-known fact that D does not include Windows headers is merely a task waiting for someone to champion it, feel free to take it if you care strongly about this.

you seem to completely miss my point. let me quote myself:

> years in developement. 2.067 release. still can't compile simple utility without solving stupid puzzles.

all that "H1 2015 Priorities" are BULLSHIT. complete and utterly bullshit. dmd is an alien for GNU/Linux. dmd is an alien for windows. yet there is *no* *single* *fsckin'* *word* about better platform support in "H1 2015 Priorities". "Improving our brand"? "2000 pull requests"? "C++ integration"? really? it *that* what D desperately needs? D is unusable for bare metal. D is unusable for simply daily programming tasks. sure, that is that "brand" thing that aimed to fix the situation. upgrading toolchain is not an option.

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/

-- 
/Jacob Carlborg

On Sunday, 1 February 2015 at 10:33:51 UTC, ketmar wrote:
> i wonder how mingw linker is able to use .dlls without corresponding .lib
> files to link windows executables. maybe it's a weird art of forbidden
> black magic or something...

What are you talking about? See WinGW\lib\libuser32.a for example.

The D Win32 headers are actually translated from the MinGW headers.

> you seem to completely miss my point.

No, I did not miss it and I do not disagree. I created a thread with a proposal to improve this use case.

However, curiously, D is actually often criticized as being too Windows-biased.

On Sun, 01 Feb 2015 10:41:04 +0000, Vladimir Panteleev wrote:

> On Sunday, 1 February 2015 at 10:33:51 UTC, ketmar wrote:
>> i wonder how mingw linker is able to use .dlls without corresponding .lib files to link windows executables. maybe it's a weird art of forbidden black magic or something...
> 
> What are you talking about? See WinGW\lib\libuser32.a for example.

i'm talking about the case where i was in need of "urlmon.dll", and there was no import library for it in my mingw. than i simply add that to options: "-Wl,--enable-auto-import -Wl,--enable-stdcall-fixup" and placed "urlmon.dll" in my build directory. and voila! no stupid import libraries, no other mess -- mingw "ld" happily used that dll to resolve imports. simple and easy.

> However, curiously, D is actually often criticized as being too Windows-biased.

actually, D support for GNU/Linux is far better than windows one. to the extent that D is unisable on windows without heavy googling and puzzle solving. not that i really care about windows, but there is no way to gain popularity with the current state of the things. alas.