Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 16:12:13 UTC, FG wrote: What? How did you do that and what problems did you encounter? Does it work with regular DMD/Druntime/Phobos or only with Aliced[1]? You can gain a big DMD compilation speed boost by using practically any C++ compiler other than DMC to build DMD. For example, there's Visual Studio project files included with the compiler source (although they often go out of date).
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 17:12:11 +0100, FG wrote: > What? How did you do that and what problems did you encounter? > Does it work with regular DMD/Druntime/Phobos or only with Aliced[1]? > > [1] I only saw it mentioned once in the forum. What exactly is it? p.s. "Aliced" is my private D fork. it's mostly parser enhancements and rejected PRs which i found useful, but don't believe that they will go into mainline. but it doesn't matter, as Aliced does everything that vanilla D can do, and all my patches are rebased on git head on dayly basis. so it doesn't matter whether it DMD or "aliced DMD" for this case. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 17:12:11 +0100, FG wrote: > On 2015-02-01 at 12:29, ketmar wrote: >> 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. > > What? How did you do that and what problems did you encounter? > Does it work with regular DMD/Druntime/Phobos or only with Aliced[1]? > > [1] I only saw it mentioned once in the forum. What exactly is it? i only built dmd.exe with mingw, i wasn't invested any efforts to make dmd.exe itself work with binutils. but i believe that with "-m32mscoff" switch making dmd.exe using "ld.exe" and other tools will be trivial, as those using COFF object files. yet i'm not interested enough in windows to work on that, and i will not write a single line of code without it being preliminary approved by BOTH Walter and Andrei. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On 2015-02-01 at 12:29, ketmar wrote: 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. What? How did you do that and what problems did you encounter? Does it work with regular DMD/Druntime/Phobos or only with Aliced[1]? [1] I only saw it mentioned once in the forum. What exactly is it?
Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 15:57:40 UTC, Andrei Alexandrescu wrote: On 2/1/15 3:04 AM, Vladimir Panteleev wrote: 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.) Could you please update that and bring to dlang.org? -- Andrei The page was on dlang.org all the time, it has recently been moved to the wiki: http://wiki.dlang.org/Win32_DLLs_in_D More improvements coming in next release (SimpleDllMain mixin).
Re: D, windows developement, frustration and fish
On 2/1/15 3:04 AM, Vladimir Panteleev wrote: 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.) Could you please update that and bring to dlang.org? -- Andrei
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 13:27:27 +0100, Jacob Carlborg wrote: > On 2015-02-01 12:01, ketmar wrote: > >> 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. > > I have successfully used the Tango net modules on Windows without > needing to fiddle with DLL's, import libs or def files. It seems you're > doing something different. i *have* to use "wininet" in this case. but you can change it to something completely different, like "urlmon", for example. everything else will remain intact. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 12:31:25 +, Vladimir Panteleev wrote: > On Sunday, 1 February 2015 at 12:18:41 UTC, ketmar wrote: >> i *can* hack my build tool to add batch compilation, >> but i don't want to. > > I don't think batch compilation is required. Separately compiling a > module to an .obj file will put the .init in the .obj, so linking should > succeed. it's easier to make a full batch compilation than to teach build tool that it must sometimes compile .d file to .o file and sometimes just add it as is. and then i should remember where that .d was added to not add it second time by accident. all in all it will create more problems that it meant to solve. ;-) signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 12:18:41 UTC, ketmar wrote: i *can* hack my build tool to add batch compilation, but i don't want to. I don't think batch compilation is required. Separately compiling a module to an .obj file will put the .init in the .obj, so linking should succeed.
Re: D, windows developement, frustration and fish
On 2015-02-01 12:01, ketmar wrote: 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. I have successfully used the Tango net modules on Windows without needing to fiddle with DLL's, import libs or def files. It seems you're doing something different. -- /Jacob Carlborg
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 12:07:26 +, Vladimir Panteleev wrote:
> On Sunday, 1 February 2015 at 11:58:22 UTC, ketmar wrote:
>> yet dmd still insists on having that `.init`. and there are no non-zero
>> defaults for winapi bindings, so i'm fine with such hacks. ;-)
>
> Hmm, this:
>
> import win32.winbase; void main() { PROCESS_INFORMATION pi; }
maybe it wasn't `PROCESS_INFORMATION`, but some other struct, i don't
really remember. i just start using my `zeroed!` everywhere, and took the
first structure i found in my sources to illustrate my point. ;-)
> You can just add win32/winbase.d or whatever to the compiler command
> line. rdmd will do this for you if you use that.
nope, i can't. i'm not using rdmd or dub, and my build tool doing alot of
things including building C libraries and calling external tools to
generate some files. i *can* hack my build tool to add batch compilation,
but i don't want to. i don't like batch compilation at all, and it's
broken in 2.067 anyway (see issue 14704, for example), so i can't use it
now without "-allinst" hack.
signature.asc
Description: PGP signature
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 12:06:31 +, jkpl wrote: > On Sunday, 1 February 2015 at 11:46:06 UTC, ketmar wrote: >> it's not missing, it's in "sc.ini", along with other minor tweaks that >> aren't interesting in the context of the story itself. > > Ok, you should add this precision in the initial post. it is completely clear from the post that the error is from linker. and i specified that i added the necessary import library to make it clear that i not forgot about it. i can't see any sense in adding unnecessary things there, such as my motherboard model, or md5 of "%systemroot%\system32 \*.dll", or something like it. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 11:46:06 UTC, ketmar wrote: it's not missing, it's in "sc.ini", along with other minor tweaks that aren't interesting in the context of the story itself. Ok, you should add this precision in the initial post.
Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 11:58:22 UTC, ketmar wrote:
yet dmd still insists on having that `.init`. and there are no
non-zero
defaults for winapi bindings, so i'm fine with such hacks. ;-)
Hmm, this:
import win32.winbase; void main() { PROCESS_INFORMATION pi; }
compiles and links for me just with `dmd test2`.
my own
modules are built properly by my build system, so there are
`.init`s for
all necessary structs.
You can just add win32/winbase.d or whatever to the compiler
command line. rdmd will do this for you if you use that.
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:49:29 +, Vladimir Panteleev wrote:
> On Sunday, 1 February 2015 at 11:44:12 UTC, ketmar wrote:
>> yep, without properly compiled libraries there are constant complains
>> about missing structure initalizers. i got rid of that with simple
>> template, and wrote "auto pi = zeroed!PROCESS_INFORMATION;" and alikes
>> instead. i'm not using batch compilation, so that was easier than
>> building all the libs. ;-)
>
> This should work too:
>
> PROCESS_INFORMATION pi = void;
that was my template does, actually. ;-)
public T zeroed(T) () if (__traits(isPOD, T)) {
import core.stdc.string : memset;
T res = void;
memset(&res, 0, res.sizeof);
return res;
}
due to compiler optimisation of struct returns this is almost the same as
inlining call to `memset()`.
> Or, if you actually need it initialized:
>
> PROCESS_INFORMATION pi = {};
>
> I did not expect the above to work, but it does.
i wonder why it works.
> (N.B.: PROCESS_INFORMATION is all-zero so it doesn't actually have a
> .init, test with a structure which has non-zero defaults for fields.)
yet dmd still insists on having that `.init`. and there are no non-zero
defaults for winapi bindings, so i'm fine with such hacks. ;-) my own
modules are built properly by my build system, so there are `.init`s for
all necessary structs.
signature.asc
Description: PGP signature
Re: D, windows developement, frustration and fish
On Sunday, 1 February 2015 at 11:44:12 UTC, ketmar wrote:
yep, without properly compiled libraries there are constant
complains
about missing structure initalizers. i got rid of that with
simple
template, and wrote "auto pi = zeroed!PROCESS_INFORMATION;" and
alikes
instead. i'm not using batch compilation, so that was easier
than
building all the libs. ;-)
This should work too:
PROCESS_INFORMATION pi = void;
Or, if you actually need it initialized:
PROCESS_INFORMATION pi = {};
I did not expect the above to work, but it does.
(N.B.: PROCESS_INFORMATION is all-zero so it doesn't actually
have a .init, test with a structure which has non-zero defaults
for fields.)
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:40:12 +, jkpl wrote: > 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 >> >> 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 ? it's not missing, it's in "sc.ini", along with other minor tweaks that aren't interesting in the context of the story itself. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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 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 ?
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:37:45 +, 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 > > 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) yep, without properly compiled libraries there are constant complains about missing structure initalizers. i got rid of that with simple template, and wrote "auto pi = zeroed!PROCESS_INFORMATION;" and alikes instead. i'm not using batch compilation, so that was easier than building all the libs. ;-) signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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.
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:25:04 +, 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! ;-) signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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 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)
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:28:51 +, jkpl wrote: > Shouldn't you compile with the following cmds ? > > dmd.exe test.d wininet.lib wininet.di -I > > ? 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. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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 ?
Re: D, windows developement, frustration and fish
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
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 11:04:38 +, 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. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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.)
Re: D, windows developement, frustration and fish
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. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 10:41:04 +, 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. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
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.
Re: D, windows developement, frustration and fish
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
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 10:03:30 +, 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. signature.asc Description: PGP signature
Re: D, windows developement, frustration and fish
On Sun, 01 Feb 2015 09:52:46 +, 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.
signature.asc
Description: PGP signature
Re: D, windows developement, frustration and fish
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.
Re: D, windows developement, frustration and fish
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.
Re: D, windows developement, frustration and fish
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.
Re: D, windows developement, frustration and fish
p.s. "and where is the fish?" one can ask me. alas, there is no fish in this pool. there is no water too. signature.asc Description: PGP signature
D, windows developement, frustration and fish
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." signature.asc Description: PGP signature
