www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's up with the windows headers?

reply "Jack" <Jack Jack.com> writes:
For newcomers doing the jump from C++ to D and current D users, 
wanting to program on windows, the missing windows import files 
are like a major step back. In C++ you got the full headers & 
stuff - ready to use.

The incomplete 'core.sys.windows.windows' isn't enough and 
sometime interferes with the necessary definitions you do on your 
own since you are forced to do it.

This way to exclude most windows users and thats where you might 
win a lot of new programmers, due to the nice support via Visual 
D.

Is that on the agenda/road map?
Jan 02 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
You can fetch better headers from here:

https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI/win32

the .lib files are old too though but this will go a long way.


If you need one individual function, you can also declare it 
yourself with extern(Windows).


BTW bundling these and getting new .libs are something Windows 
devs have wanted for a long time. They're all available, just as 
separate downloads :(
Jan 02 2015
next sibling parent reply "Jack" <Jack Jack.com> writes:
Will they work for 64bit? If they don't, D unfortunately becomes 
unusable for me. :(


On Friday, 2 January 2015 at 14:53:15 UTC, Adam D. Ruppe wrote:

 You can fetch better headers from here:

 https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI/win32

 the .lib files are old too though but this will go a long way.


 If you need one individual function, you can also declare it 
 yourself with extern(Windows).


 BTW bundling these and getting new .libs are something Windows 
 devs have wanted for a long time. They're all available, just 
 as separate downloads :(
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 15:12:18 UTC, Jack wrote:

 Will they work for 64bit? If they don't, D unfortunately 
 becomes unusable for me. :(


I'm not sure, I've never done any 64 bit Windows development at 
all, but I think the headers are the same.
Jan 02 2015
parent reply "Jack" <Jack Jack.com> writes:
It seems that they are not the same. i downloaded the imports, 
re-installed D and tried an older project.
Too bad - D is not yet usable for windows development. I need to 
stay with C++ - merde.

Well mybe Andre has a plan to get things to work and not shut out 
th windows people.

Thank you anyway for your kind advice.






On Friday, 2 January 2015 at 15:49:01 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 15:12:18 UTC, Jack wrote:

 Will they work for 64bit? If they don't, D unfortunately 
 becomes unusable for me. :(


 I'm not sure, I've never done any 64 bit Windows development at 
 all, but I think the headers are the same.
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 15:55:15 UTC, Jack wrote:

 It seems that they are not the same. i downloaded the imports, 
 re-installed D and tried an older project.


What happened? I betcha the differences aren't that big.

I have a 64 bit windows computer now and installed visual studio 
a while ago, let me spend a couple hours and see if I can fix it.


 Too bad - D is not yet usable for windows development.


I use it for a lot of win32 stuff so I'm sure the problems can be 
fixed kinda quickly for 64.
Jan 02 2015
parent reply "Jack" <Jack Jack.com> writes:
I used to it privately for win32 too and it worked great. 
Unfortunately, the bosses want both, win32 and win64, these days 
and you just can't do it with D.
I am not a compiler person and due to the project time 
constraints can't spend the time to get the usual stuff working, 
that works with c++ out of the box. My bosses will NOT pay for 
such tasks, even though they would be willing take another 
language then C++, IF it is maintainable by other programmers 
(the -> you might die thing).
Somehow I have the feeling, that it will not be fixed quickly as 
you suggests.



On Friday, 2 January 2015 at 16:04:58 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 15:55:15 UTC, Jack wrote:

 It seems that they are not the same. i downloaded the imports, 
 re-installed D and tried an older project.


 What happened? I betcha the differences aren't that big.

 I have a 64 bit windows computer now and installed visual 
 studio a while ago, let me spend a couple hours and see if I 
 can fix it.


 Too bad - D is not yet usable for windows development.


 I use it for a lot of win32 stuff so I'm sure the problems can 
 be fixed kinda quickly for 64.
Jan 02 2015
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 16:29:56 UTC, Jack wrote:

 Somehow I have the feeling, that it will not be fixed quickly 
 as you suggests.


Eh, maybe, but I just got it working for me. Try this on for size:

download
http://arsdnet.net/dcode/dmd-windows-addon.zip

Put it in your dmd2 folder and unzip it there. It will make a new 
win32 folder and want to overwrite a gdi32.lib (the one that 
comes with dmd is from like Windows 98).


Then try compiling your project with -m64. (It is called win32 
but I just used it to do a 64 bit hello world too.)



If you don't have the 64 bit compiler installed, first install 
Visual Studio, then install dmd through the Windows installer 
exe. That's what I did. Then you can just put my zip in the 
c:\d\dmd2, extract it there, and hopefully be good to go.



The fixes I had to do to the headers were pretty minor - a 
function was declared in the wrong version block and the CONTEXT 
struct for 64 bit was missing, so I brought it over from my VS 
install.


It seems to work. I had to specify user32.lib on the compile 
command line too btw so it would bring in MessageBoxW on my hello 
world.



 I am not a compiler person and due to the project time 
 constraints can't spend the time to get the usual stuff 
 working, that works with c++ out of the box.


Yeah there's still the possibility of bugs but I really doubt it 
is that bad.
Jan 02 2015
prev sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1/2/15, Adam D. Ruppe via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You can fetch better headers from here:

 https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI/win32


I recommend https://github.com/CS-svnmirror/dsource-bindings-win32
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 17:06:30 UTC, Andrej Mitrovic via 
Digitalmars-d wrote:

 I recommend 
 https://github.com/CS-svnmirror/dsource-bindings-win32


Ooooh, and the 64 bit looks like it is already there!

we *desperately* need this bundled with the main dmd download. I 
noticed today that they separated out the OS zips. For the love 
of the D, let's just drop this in there so it all just works.

Who's zipping them up nowadays?
Jan 02 2015
next sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1/2/15, Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:I

 I noticed today that they separated out the OS zips.



never integrating the Windows bindings to the zip. No idea who makes
the zips though.
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 17:29:38 UTC, Andrej Mitrovic via 
Digitalmars-d wrote:

 No way! First I've heard of it.


check it out: http://dlang.org/download.html

It looks like what I wanted: same folder structure, 1/5 the 
download size per OS. (I like to download the Windows and Linux 
together, I then cross compile with Wine, but I don't need Mac 
and BSD.)



 bindings to the zip. No idea who makes the zips though.


Anybody know? Once we get that winapi package in the default 
import path, we can go ahead and compile the little functions 
right in and drop in all the updated 32 bit OMF libs....

and then we Windows programmers can actually rely on it to work! 
Simpledisplay.d could slice out like 1,000 lines... it wouldn't 
need to version=with_opengl anymore... my comhelpers would just 
work.

Ooooh, it'd be a renaissance of D on Windows!

And best of all, no more new folks running away saying D on 
Windows sucks.
Jan 02 2015
parent "Jack" <Jack Jack.com> writes:
YUP


On Friday, 2 January 2015 at 18:32:25 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 17:29:38 UTC, Andrej Mitrovic via 
 Digitalmars-d wrote:

 No way! First I've heard of it.


 check it out: http://dlang.org/download.html

 It looks like what I wanted: same folder structure, 1/5 the 
 download size per OS. (I like to download the Windows and Linux 
 together, I then cross compile with Wine, but I don't need Mac 
 and BSD.)



 bindings to the zip. No idea who makes the zips though.


 Anybody know? Once we get that winapi package in the default 
 import path, we can go ahead and compile the little functions 
 right in and drop in all the updated 32 bit OMF libs....

 and then we Windows programmers can actually rely on it to 
 work! Simpledisplay.d could slice out like 1,000 lines... it 
 wouldn't need to version=with_opengl anymore... my comhelpers 
 would just work.

 Ooooh, it'd be a renaissance of D on Windows!

 And best of all, no more new folks running away saying D on 
 Windows sucks.
Jan 02 2015
prev sibling next sibling parent "Jack" <Jack Jack.com> writes:
will try - you guys are wizzards. now i hope it'll work!!



On Friday, 2 January 2015 at 17:10:01 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 17:06:30 UTC, Andrej Mitrovic via 
 Digitalmars-d wrote:

 I recommend 
 https://github.com/CS-svnmirror/dsource-bindings-win32


 Ooooh, and the 64 bit looks like it is already there!

 we *desperately* need this bundled with the main dmd download. 
 I noticed today that they separated out the OS zips. For the 
 love of the D, let's just drop this in there so it all just 
 works.

 Who's zipping them up nowadays?
Jan 02 2015
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 2 January 2015 at 17:10:01 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 17:06:30 UTC, Andrej Mitrovic via 
 Digitalmars-d wrote:

 I recommend 
 https://github.com/CS-svnmirror/dsource-bindings-win32


 Ooooh, and the 64 bit looks like it is already there!

 we *desperately* need this bundled with the main dmd download. 
 I noticed today that they separated out the OS zips. For the 
 love of the D, let's just drop this in there so it all just 
 works.

 Who's zipping them up nowadays?


A script. Here and in main() is probably where you'd want to add 
them (but I'd ask Martin to be sure):

https://github.com/D-Programming-Language/installer/blob/master/create_dmd_release/build_all.d#L208
Jan 02 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 6:27 AM, Jack wrote:

 For newcomers doing the jump from C++ to D and current D users, wanting to
 program on windows, the missing windows import files are like a major step
back.
 In C++ you got the full headers & stuff - ready to use.

 The incomplete 'core.sys.windows.windows' isn't enough and sometime interferes
 with the necessary definitions you do on your own since you are forced to do
it.

 This way to exclude most windows users and thats where you might win a lot of
 new programmers, due to the nice support via Visual D.

 Is that on the agenda/road map?


When you find yourself inserting the necessary definitions manually in your 
code, file a PR as well to put them in windows.d. If that is too much work,
then 
just cut&paste your extern(Windows) { ... } block into a bugzilla bug report.
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 21:48:34 UTC, Walter Bright wrote:

 When you find yourself inserting the necessary definitions 
 manually in your code, file a PR as well to put them in 
 windows.d.


How would you feel about a PR to dump that whole win32 bindings 
into the druntime tree?

I'll change the module names from win32.xxx over to 
core.sys.windows.xxx so it blends in, but it would be a wholesale 
copy of the public domain MinGW based headers.

Then we wouldn't even have incompatiblity between 
core.sys.windows.windows.HANDLE and win32.windows.HANDLE anymore. 
It'd all go well together.

it *might* break instances where we've done manual bindings 
before... but that'd be the good kind of breakages, we'd know we 
can remove that useless code. (And the module system might even 
keep it from actually breaking the build anyway.)


I'd say it is totally worth it. We have reasonably complete 
core.stdc and core.sys.posix. Let's do the same with 
core.sys.windows.
Jan 02 2015
next sibling parent reply "Jack" <Jack Jack.com> writes:
1. that would be nice

2.
everything compiles now, but the linker shows:

Building Debug\ConsoleApp1.exe...
LINK : fatal error LNK1104: cannot open file 'netapi.lib'

i checked the paths and sc.ini. the linker should find it.
i installed VS12, D and the new visual d. does anybody have the 
same problem?


to walter - i will/would


On Friday, 2 January 2015 at 21:57:09 UTC, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 21:48:34 UTC, Walter Bright wrote:

 When you find yourself inserting the necessary definitions 
 manually in your code, file a PR as well to put them in 
 windows.d.


 How would you feel about a PR to dump that whole win32 bindings 
 into the druntime tree?

 I'll change the module names from win32.xxx over to 
 core.sys.windows.xxx so it blends in, but it would be a 
 wholesale copy of the public domain MinGW based headers.

 Then we wouldn't even have incompatiblity between 
 core.sys.windows.windows.HANDLE and win32.windows.HANDLE 
 anymore. It'd all go well together.

 it *might* break instances where we've done manual bindings 
 before... but that'd be the good kind of breakages, we'd know 
 we can remove that useless code. (And the module system might 
 even keep it from actually breaking the build anyway.)


 I'd say it is totally worth it. We have reasonably complete 
 core.stdc and core.sys.posix. Let's do the same with 
 core.sys.windows.
Jan 02 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 2:14 PM, Jack wrote:

 1. that would be nice

 2.
 everything compiles now, but the linker shows:

 Building Debug\ConsoleApp1.exe...
 LINK : fatal error LNK1104: cannot open file 'netapi.lib'

 i checked the paths and sc.ini. the linker should find it.
 i installed VS12, D and the new visual d. does anybody have the same problem?


 to walter - i will/would


probably have to get the netapi.lib from the VC system and run coffimplib.exe
on it.
Jan 02 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 22:18:37 UTC, Walter Bright wrote:

 probably have to get the netapi.lib from the VC system and run 
 coffimplib.exe on it.


He's compiling 64 bit so it uses the VC stuff natively!
Jan 02 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 2:21 PM, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 22:18:37 UTC, Walter Bright wrote:

 probably have to get the netapi.lib from the VC system and run coffimplib.exe
 on it.


 He's compiling 64 bit so it uses the VC stuff natively!


Good, i.e. no work for me to do!
Jan 02 2015
parent "Jack" <Jack Jack.com> writes:
searching for netapi.lib I find:
C:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\x64\netapi.lib
and
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64\netapi.lib

the netapi32.lib i can only find in x86 folders.

i copied the to another folder, renamed it to netapi.lib. put 
folder into lib path and it works. well i guess re-install vs12.
thank you all



On Friday, 2 January 2015 at 22:23:10 UTC, Walter Bright wrote:

 On 1/2/2015 2:21 PM, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 22:18:37 UTC, Walter Bright wrote:

 probably have to get the netapi.lib from the VC system and 
 run coffimplib.exe
 on it.


 He's compiling 64 bit so it uses the VC stuff natively!


 Good, i.e. no work for me to do!
Jan 02 2015
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 January 2015 at 22:14:56 UTC, Jack wrote:

 LINK : fatal error LNK1104: cannot open file 'netapi.lib'


try netapi32.lib

On my copy of VS, netapi.lib isn't there anymore (I think it was 
16 bit) but netapi32.lib works on both 32 and 64 bit.
Jan 02 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2015 1:57 PM, Adam D. Ruppe wrote:

 On Friday, 2 January 2015 at 21:48:34 UTC, Walter Bright wrote:

 When you find yourself inserting the necessary definitions manually in your
 code, file a PR as well to put them in windows.d.


 How would you feel about a PR to dump that whole win32 bindings into the
 druntime tree?

 I'll change the module names from win32.xxx over to core.sys.windows.xxx so it
 blends in, but it would be a wholesale copy of the public domain MinGW based
 headers.

 Then we wouldn't even have incompatiblity between
 core.sys.windows.windows.HANDLE and win32.windows.HANDLE anymore. It'd all go
 well together.

 it *might* break instances where we've done manual bindings before... but
that'd
 be the good kind of breakages, we'd know we can remove that useless code. (And
 the module system might even keep it from actually breaking the build anyway.)


 I'd say it is totally worth it. We have reasonably complete core.stdc and
 core.sys.posix. Let's do the same with core.sys.windows.


Sounds like a good idea to me.
Jan 02 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, January 02, 2015 21:57:08 Adam D. Ruppe via Digitalmars-d wrote:

 On Friday, 2 January 2015 at 21:48:34 UTC, Walter Bright wrote:

 When you find yourself inserting the necessary definitions
 manually in your code, file a PR as well to put them in
 windows.d.


 How would you feel about a PR to dump that whole win32 bindings
 into the druntime tree?


It's one of those things that's long past due but requires that someone
actually put the time and effort in to get it done, and no one has done so
yet. So, if you're willing to do it and have the time, go for it. It would
be a huge improvement for dealing with the win32 API from D.

- Jonathan M Davis
Jan 11 2015
prev sibling parent reply "FrankLike" <1150015857 qq.com> writes:
On Friday, 2 January 2015 at 14:27:11 UTC, Jack wrote:

 For newcomers doing the jump from C++ to D and current D users, 
 wanting to program on windows, the missing windows import files 
 are like a major step back. In C++ you got the full headers & 
 stuff - ready to use.

 The incomplete 'core.sys.windows.windows' isn't enough and 
 sometime interferes with the necessary definitions you do on 
 your own since you are forced to do it.

 This way to exclude most windows users and thats where you 
 might win a lot of new programmers, due to the nice support via 
 Visual D.

 Is that on the agenda/road map?


Re: What's up with the windows headers?

You can look at this:

https://github.com/FrankLIKE/WindowsServiceInD/tree/master/src/onedge/win32

Here not have the '_WIN32_WINNT_ONLY' in winbase.d and other d 
file ,no trouble in here.

Frank
Jan 04 2015
parent "Jack" <Jack Jack.com> writes:
thanx, i will try it. when the headers go to the release version 
of D, than it would be a great time to adapt dlf. maybe one 
should do  that with these headers of yours wright now.



On Sunday, 4 January 2015 at 14:58:23 UTC, FrankLike wrote:

 On Friday, 2 January 2015 at 14:27:11 UTC, Jack wrote:

 For newcomers doing the jump from C++ to D and current D 
 users, wanting to program on windows, the missing windows 
 import files are like a major step back. In C++ you got the 
 full headers & stuff - ready to use.

 The incomplete 'core.sys.windows.windows' isn't enough and 
 sometime interferes with the necessary definitions you do on 
 your own since you are forced to do it.

 This way to exclude most windows users and thats where you 
 might win a lot of new programmers, due to the nice support 
 via Visual D.

 Is that on the agenda/road map?


 Re: What's up with the windows headers?

 You can look at this:

 https://github.com/FrankLIKE/WindowsServiceInD/tree/master/src/onedge/win32

 Here not have the '_WIN32_WINNT_ONLY' in winbase.d and other d 
 file ,no trouble in here.

 Frank
Jan 04 2015