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>
> 
> 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. ;-)

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

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

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

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.

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.

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

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. ;-)
> 
> 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.

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

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.