On 24 November 2012 23:18, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 11/24/12, Walter Bright <newshound2@digitalmars.com> wrote:
> > I'd forget about the unicode macro, and call the A or W versions explicitly.
>
> People already use WindowsAPI (http://dsource.org/projects/bindings/wiki/WindowsApi) and Derelict for many projects, and introducing a new API that isn't compatible with this is going to create compatibility issues.


What new API? How is it incompatible?
There's nothing 'new' about WINAPI.

Not to mention
> newbies which will be utterly confused as to what to use now, the new std.c.windows.windows (which will be what, a single module spanning 100000 lines?) or the WindowsAPI bindings.
>

windows.h (and friends) is gigantic, nothing D can (or should) do about
that...

The WinAPI project has been used and maintained for years (compared to
> the poorly maintainted std.c.windows.windows where people arbitrarily add stuff to it when they feel the need to).
>

Sure, I'd suggest that one of the mature bindings should be pulled into druntime in place of what's there now, better than new code for sure. No real point druntime offering an incomplete binding.

Here we have a guy (Gor) who doesn't even know what declspec is, or
> what a def file is, or what an import libarary is, who thinks he can use regex to create bindings, and who refuses to use STABLE bindings that were maintained for years. And we're going to allow him to create new backward-incompatible bindings that will supposedly work out of the box (they most certainly won't)?
>

I don't care who does it or where the code comes from, I was just supporting the notion that druntime's windows bindings are very incomplete, and that alone should be addressed one way or another.

I used to be *for* putting WinAPI bindings into druntime/phobos. But
> seeing how some pull requests take months to be merged, and Walter's ultra stance on not adding any aliases that help with code readability (A vs W functions), and the obsessive requirement for Phobos to be composed out of massive single modules, I'm beginning to think that keeping the API out of Phobos might actually be a good idea.
>

I'm sure it would be merged. And aren't the windows bindings in druntime? WINAPI is decades old, it will never change, it will never need revision after being done properly. I think it's safe to have in the std library (and it's already there, it's just incomplete).

The A/W matter... I really think the version should be respected and the
aliases maintained.
You can't make a change like that after decades because you think you know
better... Win32 is effectively a legacy API, and people have decades of
experience, and existing code written with it.

Here's a crazy thought: if WinAPI is needed by Phobos functions why
> not just distribute WinAPI with the zipped distribution? You could put it in a special subfolder, e.g.:
>
> dmd2/src/dmd
> dmd2/src/druntime
> dmd2/src/phobos
> dmd2/src/bindings <-- put it in here
>
> And then in sc.ini or dmd.conf add an import to the bindings folder, and distribute a precompiled static library of the bindings alongside phobos.lib. The -version switches might have to be sorted out, but that has to be a simpler problem than rewriting bindings from scratch.
>

They're already in core.sys.windows, that's a perfectly good place for it.

On 24 November 2012 23:36, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:

> On Saturday, 24 November 2012 at 18:49:02 UTC, Manu wrote:
>
>> Hear hear! I agree, it should just be cloned verbatim.
>> I for one have 15+ years of expectation about WINAPI, I don't want to look
>> in any manual/reference to relearn how to use it again.
>>
>
> This sentiment is overexaggerated and unhelpful. Please provide an example of what sorts of "relearning" you'd have to do.
>

I'm simply stating my sentiment that ANY change to WIN32 is a very very bad
idea.
It invalidates existing code, and existing learning/reference material. Not
to mention how many programmers don't even know what unicode is (ie, the
A/W alias argument).

'Relearning' in this instance might refer to learning/remembering what changes have been made.

On Saturday, 24 November 2012 at 23:11:35 UTC, Manu wrote:
> On 24 November 2012 23:36, Vladimir Panteleev
> <vladimir@thecybershadow.net>wrote:
>
>> On Saturday, 24 November 2012 at 18:49:02 UTC, Manu wrote:
>>
>>> Hear hear! I agree, it should just be cloned verbatim.
>>> I for one have 15+ years of expectation about WINAPI, I don't want to look
>>> in any manual/reference to relearn how to use it again.
>>>
>>
>> This sentiment is overexaggerated and unhelpful. Please provide an example
>> of what sorts of "relearning" you'd have to do.
>>
>
> I'm simply stating my sentiment that ANY change to WIN32 is a very very bad idea.

Reasoning in absolutes is not constructive.

> It invalidates existing code, and existing learning/reference material.

Please provide a concrete example.

> Not to mention how many programmers don't even know what unicode is (ie, the A/W alias argument).

I don't understand how this is relevant to this discussion.

> 'Relearning' in this instance might refer to learning/remembering what
> changes have been made.

Part of the goal is to minimize required changes in correct code. Even in those cases (assuming they will even exist), the compiler will produce a helpful error message (e.g expected type void*, got HGLOBAL). The code can be easily fixed in a backwards-compatible way by adding a cast.

On 25 November 2012 01:24, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:

> On Saturday, 24 November 2012 at 23:11:35 UTC, Manu wrote:
>
>> On 24 November 2012 23:36, Vladimir Panteleev <vladimir@thecybershadow.net>**wrote:
>>
>>  On Saturday, 24 November 2012 at 18:49:02 UTC, Manu wrote:
>>>
>>>  Hear hear! I agree, it should just be cloned verbatim.
>>>> I for one have 15+ years of expectation about WINAPI, I don't want to
>>>> look
>>>> in any manual/reference to relearn how to use it again.
>>>>
>>>>
>>> This sentiment is overexaggerated and unhelpful. Please provide an
>>> example
>>> of what sorts of "relearning" you'd have to do.
>>>
>>>
>> I'm simply stating my sentiment that ANY change to WIN32 is a very very bad idea.
>>
>
> Reasoning in absolutes is not constructive.
>
>
>  It invalidates existing code, and existing learning/reference material.
>>
>
> Please provide a concrete example.


The only 2 significant changes I'm aware of are the HANDLE question, and the A/W aliases.

A/W aliases for reasons I've states in numerous places elsewhere, and the
HANDLE ones I don't have such a strong opinion on, but it would be a shame
to see errors appearing in code that compiles in C, anyone referencing that
material might wonder what's going on.
Enforcing strict type-safety on handle types is not something WIN32 does,
and therefore not something D should attempt to do either. It's just an
alias for void* in C, and I see no problem with that.

 Not to mention how many programmers don't even know what unicode is (ie,
>> the A/W alias argument).
>>
>
> I don't understand how this is relevant to this discussion.


Well it's one of the changes in the existing implementation which I totally disagree with, for the reasons stated.

 'Relearning' in this instance might refer to learning/remembering what
>> changes have been made.
>>
>
> Part of the goal is to minimize required changes in correct code. Even in those cases (assuming they will even exist), the compiler will produce a helpful error message (e.g expected type void*, got HGLOBAL). The code can be easily fixed in a backwards-compatible way by adding a cast.
>

WIN32 has a heap of these HSOMETHING types, and they're all implicitly convertible to HANDLE and should remain that way. Many functions receive HANDLE's which it expects may be of any type. The Wait* suite of functions for instance wait on basically anything.

I'd be interested to hear arguments why you think any changes of any sort should be made to a well established API that's decades old?

Am 24.11.2012 23:54, schrieb Manu:
> On 24 November 2012 22:30, Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>> wrote:
>
>     On Saturday, November 24, 2012 20:48:54 Manu wrote:
>      > I for one have 15+ years of expectation about WINAPI
>
>     My condolences. :)
>
>
> See: I *really* don't want to look in any manual to learn how to use it
> again... ever! ;)
>

Already moved into .NET then ? :)

--
Paulo

On Saturday, 24 November 2012 at 23:47:26 UTC, Manu wrote:
> Well it's one of the changes in the existing implementation which I totally
> disagree with, for the reasons stated.

Could you be more specific? Is it that the Unicode version is not set by default? Considering that Druntime does not support Windows 9x, the default should probably be changed to use the Unicode APIs in the Druntime bindings.

> WIN32 has a heap of these HSOMETHING types, and they're all implicitly
> convertible to HANDLE and should remain that way. Many functions receive
> HANDLE's which it expects may be of any type. The Wait* suite of functions
> for instance wait on basically anything.

Yes, all those should be aliases. Same with anything CloseHandle accepts.

> I'd be interested to hear arguments why you think any changes of any sort
> should be made to a well established API that's decades old?

We have the opportunity to make nearly unilateral improvements to the experience of programming in Win32 in D. It does not need to involve "relearning" (I am no fool, of course I think breaking valid C code would be bad), however you seem to be categorically against it without even looking into it, based on principle. Such an approach to software development, or anything, is not constructive. We need to look and compare actual advantages and disadvantages.

11/25/2012 3:05 AM, Manu пишет:
> On 24 November 2012 23:18, Andrej Mitrovic <andrej.mitrovich@gmail.com
> <mailto:andrej.mitrovich@gmail.com>> wrote:
>
>     I used to be *for* putting WinAPI bindings into druntime/phobos. But
>     seeing how some pull requests take months to be merged, and Walter's
>     ultra stance on not adding any aliases that help with code readability
>     (A vs W functions), and the obsessive requirement for Phobos to be
>     composed out of massive single modules, I'm beginning to think that
>     keeping the API out of Phobos might actually be a good idea.
>
>
> I'm sure it would be merged. And aren't the windows bindings in druntime?
> WINAPI is decades old, it will never change, it will never need revision
> after being done properly. I think it's safe to have in the std library
> (and it's already there, it's just incomplete).

WINAPI is growing constantly. Take a look:
http://msdn.microsoft.com/en-us/library/hh920508(v=vs.85).aspx

That's only the ones starting on W added in Vista vs XP:
http://msdn.microsoft.com/en-us/library/hh920517(v=vs.85).aspx

So you can't sync once and forget.
More importantly one can't hope to test them all properly after translation. (I mean as in mapped properly not for their functionality that's M$ job).
Basically it's a constant job for someone motivated. If we put it in druntime we need to keep an unconstrained flow of fixes/updates from authors.

>
> The A/W matter... I really think the version should be respected and the
> aliases maintained.
> You can't make a change like that after decades because you think you
> know better... Win32 is effectively a legacy API, and people have
> decades of experience, and existing code written with it.
>

Just make sure *-W is the default alias as UTF-16 is what the kernel uses internally anyway. (or a lame subset of UTF-16)

>     Here's a crazy thought: if WinAPI is needed by Phobos functions why
>     not just distribute WinAPI with the zipped distribution? You could put
>     it in a special subfolder, e.g.:
>
>     dmd2/src/dmd
>     dmd2/src/druntime
>     dmd2/src/phobos
>     dmd2/src/bindings <-- put it in here
>
>     And then in sc.ini or dmd.conf add an import to the bindings folder,
>     and distribute a precompiled static library of the bindings alongside
>     phobos.lib. The -version switches might have to be sorted out, but
>     that has to be a simpler problem than rewriting bindings from scratch.
>
>
> They're already in core.sys.windows, that's a perfectly good place for it.
+1
Looking a WINAPI bindings project I couldn't help but wonder why it's not pulled into druntime or is a part of druntime. Guess that must be license issues?

-- 
Dmitry Olshansky

11/24/2012 9:34 PM, Gor Gyolchanyan пишет:
> I disagree. One is free to (and I'm going to) make a module which
> implements the functions automatically and has them wglGetProcAddress.
> This makes using OpenGL a lot easier.


Well, last time I checked that was Derelict. We'd better advertise it as a go-to project for OpenGL.
>
>
> On Sat, Nov 24, 2012 at 7:32 PM, Jakob Ovrum <jakobovrum@gmail.com
> <mailto:jakobovrum@gmail.com>> wrote:
>
>     On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote:
>
>         On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>
>             I hope the deimos folks make a repo soon, so that people can
>             use those modules
>             as soon as possible, because I'll finish translating them today.
>
>
>         https://github.com/D-__Programming-Deimos/OpenGL
>         <https://github.com/D-Programming-Deimos/OpenGL>
>
>
>     This repo is a poor idea. Statically linking OpenGL is not the
>     recommended way of linking OpenGL in a given application.
>
>     Then again, Deimos is a poor idea to begin with, the only benefit is
>     the unified source package name "deimos", which doesn't warrant the
>     D-Programming-Deimos Github organization at all. A list of links to
>     repositories following the Deimos guidelines would not only be
>     sufficient, but much more efficient.
>
>
>
>
> --
> Bye,
> Gor Gyolchanyan.


-- 
Dmitry Olshansky

DerelictGL is flawed. It uses OpenGL32.dll, which is deliberately nerfed by Microsoft. the wglGetProcAddress gets the functions pointers, which are unavailable from OpenGL32.dll and Derelict doesn't use it.


On Sun, Nov 25, 2012 at 2:43 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> 11/24/2012 9:34 PM, Gor Gyolchanyan пишет:
>
>  I disagree. One is free to (and I'm going to) make a module which
>> implements the functions automatically and has them wglGetProcAddress. This makes using OpenGL a lot easier.
>>
>
>
> Well, last time I checked that was Derelict. We'd better advertise it as a go-to project for OpenGL.
>
>>
>>
>> On Sat, Nov 24, 2012 at 7:32 PM, Jakob Ovrum <jakobovrum@gmail.com <mailto:jakobovrum@gmail.com>> wrote:
>>
>>     On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright wrote:
>>
>>         On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>>
>>             I hope the deimos folks make a repo soon, so that people can
>>             use those modules
>>             as soon as possible, because I'll finish translating them
>> today.
>>
>>
>>         https://github.com/D-__**Programming-Deimos/OpenGL<https://github.com/D-__Programming-Deimos/OpenGL>
>>
>>         <https://github.com/D-**Programming-Deimos/OpenGL<https://github.com/D-Programming-Deimos/OpenGL>
>> >
>>
>>
>>     This repo is a poor idea. Statically linking OpenGL is not the
>>     recommended way of linking OpenGL in a given application.
>>
>>     Then again, Deimos is a poor idea to begin with, the only benefit is
>>     the unified source package name "deimos", which doesn't warrant the
>>     D-Programming-Deimos Github organization at all. A list of links to
>>     repositories following the Deimos guidelines would not only be
>>     sufficient, but much more efficient.
>>
>>
>>
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
>
> --
> Dmitry Olshansky
>



-- 
Bye,
Gor Gyolchanyan.

11/25/2012 2:48 PM, Gor Gyolchanyan пишет:
> DerelictGL is flawed. It uses OpenGL32.dll, which is deliberately nerfed
> by Microsoft.

Old tale back when OpenGL was often just software rendered in part or as a whole.

> the wglGetProcAddress gets the functions pointers, which
> are unavailable from OpenGL32.dll and Derelict doesn't use it.
>

Not sure how you've come to this conclusion. Did you try it at all?
For one thing - it does pick up extensions (via wglGetProcAddress) from your vendor's specific opengl driver. There is no such thing as getting extensions 'from OpenGL32.dll'.

wglGetProcAddress
is present in OpenGL32.dll
http://msdn.microsoft.com/en-us/library/windows/desktop/dd374386(v=vs.85).aspx

I've used extensions like GL_EXT_* with Derelict just fine.

HINT: opengl32.dll's description OpenGL CLIENT DLL. Implied host is inside the video driver your vendor provides.

>
> On Sun, Nov 25, 2012 at 2:43 PM, Dmitry Olshansky <dmitry.olsh@gmail.com
> <mailto:dmitry.olsh@gmail.com>> wrote:
>
>     11/24/2012 9:34 PM, Gor Gyolchanyan пишет:
>
>         I disagree. One is free to (and I'm going to) make a module which
>         implements the functions automatically and has them
>         wglGetProcAddress.
>         This makes using OpenGL a lot easier.
>
>
>
>     Well, last time I checked that was Derelict. We'd better advertise
>     it as a go-to project for OpenGL.
>
>
>
>         On Sat, Nov 24, 2012 at 7:32 PM, Jakob Ovrum
>         <jakobovrum@gmail.com <mailto:jakobovrum@gmail.com>
>         <mailto:jakobovrum@gmail.com <mailto:jakobovrum@gmail.com>>> wrote:
>
>              On Friday, 23 November 2012 at 21:15:00 UTC, Walter Bright
>         wrote:
>
>                  On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>
>                      I hope the deimos folks make a repo soon, so that
>         people can
>                      use those modules
>                      as soon as possible, because I'll finish
>         translating them today.
>
>
>         https://github.com/D-____Programming-Deimos/OpenGL
>         <https://github.com/D-__Programming-Deimos/OpenGL>
>
>                  <https://github.com/D-__Programming-Deimos/OpenGL
>         <https://github.com/D-Programming-Deimos/OpenGL>>
>
>
>              This repo is a poor idea. Statically linking OpenGL is not the
>              recommended way of linking OpenGL in a given application.
>
>              Then again, Deimos is a poor idea to begin with, the only
>         benefit is
>              the unified source package name "deimos", which doesn't
>         warrant the
>              D-Programming-Deimos Github organization at all. A list of
>         links to
>              repositories following the Deimos guidelines would not only be
>              sufficient, but much more efficient.
>
>
>
>
>         --
>         Bye,
>         Gor Gyolchanyan.
>
>
>
>     --
>     Dmitry Olshansky
>
>
>
>
> --
> Bye,
> Gor Gyolchanyan.


-- 
Dmitry Olshansky