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 f
nough 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
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
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
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!
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.
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!
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
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 binding
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 pr
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 t
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 eno
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 th
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
d
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
togethe
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
On 1/2/15, Adam D. Ruppe via Digitalmars-d
wrote:I
> I noticed today that they separated out the OS zips.
No way! First I've heard of it. That's probably the #1 blocker of
never integrating the Windows bindings to the zip. No idea who makes
the zips though.
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
On 1/2/15, Adam D. Ruppe via Digitalmars-d 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
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
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++
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 ag
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 any
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.
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 t
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 the
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 wi
Hi Stewart,
I read the notes on the page of the win32 project. I looked at
your request for first assigning a module to one's self before
starting to work on it and I did not find any way to do so.
I thought maybe I had to be logged in on the site, so I created
an account but when I log in i
On Monday, December 31, 2012 01:41:38 Stewart Gordon wrote:
> Your comment was posted as a reply to my statement that was about the
> Windows API bindings, not anything that is already in druntime. As
> such, what you ended up saying was that we would need to go to some
> extra effort to have Win2
On 30/12/2012 22:27, Jonathan M Davis wrote:
On Sunday, December 30, 2012 18:33:01 Stewart Gordon wrote:
On 30/12/2012 00:49, Jonathan M Davis wrote:
We specifically decided not to support Win2K. It requires extra
effort that we don't want to go to, and almost no one uses it
anymore.
What e
On Sunday, December 30, 2012 18:33:01 Stewart Gordon wrote:
> On 30/12/2012 00:49, Jonathan M Davis wrote:
>
>
> > Third parties would typically take druntime and make whatever
> > minimal tweaks they need to make it work with their stuff. That's
> > what gdc and ldc do.
>
> All the more reason
On 30/12/2012 00:49, Jonathan M Davis wrote:
Third parties would typically take druntime and make whatever
minimal tweaks they need to make it work with their stuff. That's
what gdc and ldc do.
All the more reason to keep the Win2000 support in, in case one of these
third parties wants it.
12/30/2012 3:20 AM, Stewart Gordon пишет:
On 28/12/2012 19:20, Stewart Gordon wrote:
On 28/12/2012 18:54, Phil Lavoie wrote:
Additional Question: Is there a reason why you use MingW's headers
instead of VC? I am just wild guessing here, but aren't VC's most likely
to be up to date?
Copyright
On Sunday, December 30, 2012 00:32:18 Stewart Gordon wrote:
> On 28/12/2012 04:57, Jonathan M Davis wrote:
> > On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:
> >> On 27/12/2012 13:52, Jonathan M Davis wrote:
>
>
> >>> We're not supporting anything older than XP, but we're still
> >
On 28/12/2012 04:57, Jonathan M Davis wrote:
On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:
On 27/12/2012 13:52, Jonathan M Davis wrote:
We're not supporting anything older than XP, but we're still
supporting XP, so whatever is done with the bindings needs to be in
line with th
On 28/12/2012 19:20, Stewart Gordon wrote:
On 28/12/2012 18:54, Phil Lavoie wrote:
Additional Question: Is there a reason why you use MingW's headers
instead of VC? I am just wild guessing here, but aren't VC's most likely
to be up to date?
Copyright. The MinGW headers are public domain.
O
On 28/12/2012 18:54, Phil Lavoie wrote:
Additional Question: Is there a reason why you use MingW's headers
instead of VC? I am just wild guessing here, but aren't VC's most likely
to be up to date?
Copyright. The MinGW headers are public domain.
Stewart.
On Friday, 28 December 2012 at 18:54:40 UTC, Phil Lavoie wrote:
Yeah, sure, it's not a big problem, it's not even a problem.
It's really just a matter of emulating the macro better, though
using std.algorithm's might actually give the correct answer
when the macro does not. I was just mentionin
Yeah, sure, it's not a big problem, it's not even a problem. It's
really just a matter of emulating the macro better, though using
std.algorithm's might actually give the correct answer when the
macro does not. I was just mentioning this as an example of
possible things that could be discussed
On 28/12/2012 13:38, Phil Lavoie wrote:
Hi,
Sorry for the duplicate the forum did not seem to have processed my post
so I made another one. I'm sorry I didn't mean TYPE INFERENCE did not
work I meant that this:
int x
uint y;
min( x, y ) will not compile, you would have to rewrite it to min( x,
c
Hi,
Sorry for the duplicate the forum did not seem to have processed
my post so I made another one. I'm sorry I didn't mean TYPE
INFERENCE did not work I meant that this:
int x
uint y;
min( x, y ) will not compile, you would have to rewrite it to
min( x, cast( int )y ) for example, or min!int
On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:
> On 27/12/2012 13:52, Jonathan M Davis wrote:
>
>
> > No. There was ifdef stuff of some kind, but I don't recall the
> > details. You'd probably know more about that sort of stuff than I
> > would. I'm just recalling stuff from previo
On 27/12/2012 18:41, Phil Lavoie wrote:
Hi,
I am currently using the win32 api bindings project and things went
rather smoothly in migrating my (not so big) code (so far). I love that
pragmas are everywhere to make the compiler link to proper libraries.
Also, the windows lib included in the dis
Hi,
I am currently using the win32 api bindings project and the
transition went smoothly. However, the "version" import library
is not included in dmd's windows' libs, so we should have to keep
that in mind, in order to provide a full out-of-the-box working
installation.
I am willing to hel
Hi,
I am currently using the win32 api bindings project and things
went rather smoothly in migrating my (not so big) code (so far).
I love that pragmas are everywhere to make the compiler link to
proper libraries.
Also, the windows lib included in the distribution of dmd lacks
the "version"
On 27/12/2012 13:52, Jonathan M Davis wrote:
No. There was ifdef stuff of some kind, but I don't recall the
details. You'd probably know more about that sort of stuff than I
would. I'm just recalling stuff from previous discussions and not
necessarily all that accurately.
So you mean ifdefs fr
On Thursday, December 27, 2012 13:20:14 Stewart Gordon wrote:
> On 27/12/2012 11:40, Jonathan M Davis wrote:
>
>
> > Transition is one issue, but as I understand it, there are issues
> > with regards to versioning, since druntime tends assume that
> > there's only one OS version instead of asking
On 27/12/2012 11:40, Jonathan M Davis wrote:
Transition is one issue, but as I understand it, there are issues
with regards to versioning, since druntime tends assume that
there's only one OS version instead of asking you which version
you're building for,
Are you talking about issues like thi
On Thursday, December 27, 2012 11:14:15 Stewart Gordon wrote:
> On 27/12/2012 04:04, Jonathan M Davis wrote:
>
>
> > And if I understand correctly, that's what the Windows API
> >
> > project does, which should make the transition easier. But there's still
> > the issue of figuring out how to d
On 27/12/2012 04:04, Jonathan M Davis wrote:
And if I understand correctly, that's what the Windows API
project does, which should make the transition easier. But there's still the
issue of figuring out how to do that transition (like figuring out how to deal
with versions and the like), and so
On Thursday, December 27, 2012 01:52:02 Stewart Gordon wrote:
> It seems common to bundle full Windows API headers with C(++) compilers
> - indeed, even DMC seems to (though they seem to be very out of date).
> So why not D compilers just as well?
The Windows headers should definitely be part of d
On 26/12/2012 18:35, Andrej Mitrovic wrote:
On 12/26/12, Phil Lavoie wrote:
I believe everything was moved to the core.sys.windows.windows header.
No, that module existed for a long time but it was lacking a lot of
functionality, so a couple of devs created the WindowsAPI project
instead.
I
On 26/12/2012 20:22, Andrej Mitrovic wrote:
On 12/26/12, Phil Lavoie wrote:
Makes sense, do you know of any plans to merge those with the dmd
distributables?
It was discussed many times. I don't know if the Phobos team is
willing to merge the dsource.org WinAPI in its current layout.
WinAPI h
On 26/12/2012 20:36, Phil Lavoie wrote:
Of my own but I can see this is exactly what has been done so I am
thrilled. One last question: do you know if people are planning to
maintain this for windows 8 and following?
The plan has always been to try and keep it up ot date with the latest
versi
12/27/2012 12:36 AM, Phil Lavoie пишет:
You know what, I have browsed it a little bit and I think the choice to
make aliases to A and W versions was the right one. I was thinking of
adding a
version( Unicode ) {
aliases here...
}
Somewhat OT.
But IMHO almost any use of *A version is either a
On Wednesday, 26 December 2012 at 21:56:31 UTC, Phil Lavoie wrote:
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib
through this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it
using,implib /noi /system version.li
On Wednesday, 26 December 2012 at 21:56:31 UTC, Phil Lavoie wrote:
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib
through this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it
using,implib /noi /system version.li
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib through
this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it
using,implib /noi /system version.lib ...\System32\version.dll
then moved it to the dmd\windows\lib fol
You know what, I have browsed it a little bit and I think the
choice to make aliases to A and W versions was the right one. I
was thinking of adding a
version( Unicode ) {
aliases here...
}
Of my own but I can see this is exactly what has been done so I
am thrilled. One last question: do you
On 12/26/12, Phil Lavoie wrote:
> Makes sense, do you know of any plans to merge those with the dmd
> distributables?
It was discussed many times. I don't know if the Phobos team is
willing to merge the dsource.org WinAPI in its current layout. WinAPI
has aliases to Ascii/Unicode versions of func
On Wednesday, 26 December 2012 at 18:35:56 UTC, Andrej Mitrovic
wrote:
On 12/26/12, Phil Lavoie wrote:
I believe everything was moved to the core.sys.windows.windows
header.
No, that module existed for a long time but it was lacking a
lot of
functionality, so a couple of devs created the Win
On 12/26/12, Phil Lavoie wrote:
> I believe everything was moved to the core.sys.windows.windows header.
No, that module existed for a long time but it was lacking a lot of
functionality, so a couple of devs created the WindowsAPI project
instead.
On Wednesday, 26 December 2012 at 17:52:02 UTC, Martin wrote:
http://www.dsource.org/projects/bindings/wiki/WindowsApi
KK cool, I will browse them. However, this is a 1 to 1
correlation between windows headers and D versions, which is
cool. I was hoping more for a direct replacement of
core.
Holà,
I am currently reading Programming Windows and coding his
examples + my own initiatives. I know I am not the first one to
do this and Andrej Mitrovic directed me to his code samples. I
could not help but notice that those directives:
import win32.SOME_MODULE;
were used and are not suppo
64 matches
Mail list logo
