www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D, windows developement, frustration and fish

reply ketmar <ketmar ketmar.no-ip.org> writes:
today i was in need of a little utility that must download the file using=20
"wininet.dll". nothing fancy, just send a request and receive the=20
contents. no, curl was not a choice. and -- oh, well, wininet is a dll=20
which any windows box has, right? at least any windows box with XP and=20
higher, which is ok.

allright, i know that winapi bindings is a separate project, and it's ok=20
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=20
"read after free" patch) to compile a simple test program.

aaah! there is no "wininet.lib"! ok, installing msvc is a time and space=20
consuming thing, and i know that dmc has that cool "implib" utility,=20
which i can use to make the corresponding .lib file (ah, i love windows=20
developement!).

so i ran "implib.exe /s wininet.lib c:\windows\system32\wininet.dll",=20
copied the resulting "wininet.lib" to "lib" directory of dmd and tried to=20
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=20
with "implib"? ah, fine, let's try...

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

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

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

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

after some experiments i found that DMD simply ignores `pragma(mangle)`=20
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=20
simple regexp. then i generated "wininet.lib" once again. then i tried to=20
compile my sample once again. and this time i got working ".exe". great.=20
a simple utility which using one of standard windows dlls. i can write it=20
in no time, right?

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

years in developement. 2.067 release. still can't compile simple utility=20
without solving stupid puzzles. manual creating of .def files. my C=20
developement mates making fun of me, showing me how their mingw doesn't=20
need any ".lib" files at all: mingw linker can parse .dlls! my younger=20
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 =E2=80=94
  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."
=
Feb 01 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
p.s. "and where is the fish?" one can ask me. alas, there is no fish in=20
this pool. there is no water too.=
Feb 01 2015
parent reply "eles" <eles eles.com> writes:
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
Feb 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 11:25:04 +0000, eles wrote:


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

 this pool. there is no water too.


=20
 [OT] Just for the sake of it:
=20
 https://www.youtube.com/watch?v=3D00509MQxRB8


ah, this is not OT at all, it perfercly illustrates my point! ;-)=
Feb 01 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
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".


=20
 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=20
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=20
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=20
at "CS-svnmirror/dsource-bindings-win32" -- bingo! but there is no "lib"=20
directory and no ".def" files.

sure, it's entirely my fault. instead of just installing the compiler and=20
tools i had to check all repos, download the big one, then cherry-pick=20
the necessary, took .libs and so on. oh, that's really what i'm doing=20
when i want to write a simple utility with mingw... or? or i'm just=20
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=20
i need 'em. i used to use mingw, and mingw "just works". and now i=20
decided to give D a try -- i sucessfully used it in GNU/Linux, and=20
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=20
it's toolchain is definitely hostile. it's almost like "hahaha! you=20
aren't smart enough to use our Cool Language, you looser!" ok, now you=20
lost me. i'm really not smart enough to figure out how this smart plan =20
("gain popularity by alienating newcomers") ought to work.=
Feb 01 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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=20
files to link windows executables. maybe it's a weird art of forbidden=20
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=20
bullshit. dmd is an alien for GNU/Linux. dmd is an alien for windows. yet=20
there is *no* *single* *fsckin'* *word* about better platform support in=20
"H1 2015 Priorities". "Improving our brand"? "2000 pull requests"? "C++=20
integration"? really? it *that* what D desperately needs? D is unusable=20
for bare metal. D is unusable for simply daily programming tasks. sure,=20
that is that "brand" thing that aimed to fix the situation. upgrading=20
toolchain is not an option.=
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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...


=20
 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=20
was no import library for it in my mingw. than i simply add that to=20
options: "-Wl,--enable-auto-import -Wl,--enable-stdcall-fixup" and placed=20
"urlmon.dll" in my build directory. and voila! no stupid import=20
libraries, no other mess -- mingw "ld" happily used that dll to resolve=20
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=20
extent that D is unisable on windows without heavy googling and puzzle=20
solving. not that i really care about windows, but there is no way to=20
gain popularity with the current state of the things. alas.=
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.)
Feb 01 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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"


=20
 That's pretty cool.


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

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

besides, this will allow makefile unification, as alot of "posix.mak" can=20
be reused for mingw builds. i did that myself while hunting for=20
multithreading heisenbug. the side effect of switching to mingw was=20
faster dmd.exe: compiling phobos took only 2/3 of time comparing to dmc=20
version.=
Feb 01 2015
parent reply FG <home fgda.pl> writes:
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?
Feb 01 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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.


=20
 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]?
=20
 [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=20
dmd.exe itself work with binutils. but i believe that with "-m32mscoff"=20
switch making dmd.exe using "ld.exe" and other tools will be trivial, as=20
those using COFF object files. yet i'm not interested enough in windows=20
to work on that, and i will not write a single line of code without it=20
being preliminary approved by BOTH Walter and Andrei.=
Feb 01 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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]?
=20
 [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=20
rejected PRs which i found useful, but don't believe that they will go=20
into mainline. but it doesn't matter, as Aliced does everything that=20
vanilla D can do, and all my patches are rebased on git head on dayly=20
basis. so it doesn't matter whether it DMD or "aliced DMD" for this case.=
Feb 01 2015
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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).
Feb 01 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 01 2015
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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).
Feb 01 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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


=20
 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.
=20
 [1] http://dsource.org/projects/tango/docs/current/


i have my own library to work with http. but you can substitute any other=20
windows dlls in place of of wininet, the story will not change. the story=20
is about (lack of) usability.=
Feb 01 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 13:27:27 +0100, Jacob Carlborg wrote:


 On 2015-02-01 12:01, ketmar wrote:
=20

 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.


=20
 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=20
something completely different, like "urlmon", for example. everything=20
else will remain intact.=
Feb 01 2015
prev sibling parent reply "jkpl" <jkpl nowhere.fi> writes:
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>

?
Feb 01 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 11:28:51 +0000, jkpl wrote:


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


that doesn't really matter how i'll pass that .lib file to linker. and i=20
replaced part of the command line with ellipses, as there is no reason to=20
quote it all.=
Feb 01 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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)
Feb 01 2015
next sibling parent reply "jkpl" <jkpl nowhere.fi> writes:
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 ?
Feb 01 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 11:40:12 +0000, 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<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)


=20
 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=20
aren't interesting in the context of the story itself.=
Feb 01 2015
parent reply "jkpl" <jkpl nowhere.fi> writes:
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.
Feb 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 12:06:31 +0000, 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.


=20
 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=20
specified that i added the necessary import library to make it clear that=20
i not forgot about it. i can't see any sense in adding unnecessary things=20
there, such as my motherboard model, or md5 of "%systemroot%\system32
\*.dll", or something like it.=
Feb 01 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 11:37:45 +0000, 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>


=20
 wininet.lib is unnecessary because wininet.d has `pragma(lib,
 "wininet");`.
=20
 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=20
about missing structure initalizers. i got rid of that with simple=20
template, and wrote "auto pi =3D zeroed!PROCESS_INFORMATION;" and alikes=20
instead. i'm not using batch compilation, so that was easier than=20
building all the libs. ;-)=
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.)
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 11:49:29 +0000, 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 =3D zeroed!PROCESS_INFORMATION;" and alikes
 instead. i'm not using batch compilation, so that was easier than
 building all the libs. ;-)


=20
 This should work too:
=20
 PROCESS_INFORMATION pi =3D void;


that was my template does, actually. ;-)

  public T zeroed(T) () if (__traits(isPOD, T)) {
    import core.stdc.string : memset;
    T res =3D void;
    memset(&res, 0, res.sizeof);
    return res;
  }

due to compiler optimisation of struct returns this is almost the same as=20
inlining call to `memset()`.


 Or, if you actually need it initialized:
=20
 PROCESS_INFORMATION pi =3D {};
=20
 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=20
defaults for winapi bindings, so i'm fine with such hacks. ;-) my own=20
modules are built properly by my build system, so there are `.init`s for=20
all necessary structs.=
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 12:07:26 +0000, 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. ;-)


=20
 Hmm, this:
=20
 import win32.winbase; void main() { PROCESS_INFORMATION pi; }


maybe it wasn't `PROCESS_INFORMATION`, but some other struct, i don't=20
really remember. i just start using my `zeroed!` everywhere, and took the=20
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=20
things including building C libraries and calling external tools to=20
generate some files. i *can* hack my build tool to add batch compilation,=20
but i don't want to. i don't like batch compilation at all, and it's=20
broken in 2.067 anyway (see issue 14704, for example), so i can't use it=20
now without "-allinst" hack.=
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 12:31:25 +0000, 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.


=20
 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=20
that it must sometimes compile .d file to .o file and sometimes just add=20
it as is. and then i should remember where that .d was added to not add=20
it second time by accident. all in all it will create more problems that=20
it meant to solve. ;-)=
Feb 01 2015