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

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.

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.


On Sat, Nov 24, 2012 at 7:32 PM, Jakob Ovrum <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.

On 24 November 2012 01:08, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Friday, November 23, 2012 15:15:41 Gor Gyolchanyan wrote:
> > As we all know, the WinAPI binding in druntime as well as the static libraries of WinAPI, which come with DMD are in horrendous state.
>
> I am not all that well acquainted with all of the issues involved with the
> Win32 API, so I'm probably not the best qualified to chime in on how they
> should be handled. However, I would point out that given that the Win32
> API is
> effectively the system layer API for Windows, it should be fully supported
> in
> druntime (just like glibc should be fully supported for Linux by druntime),
> and as Walter points out, such a layer should be thin rather than trying
> to fix
> anything (that's the job of Phobos or other wrapper libraries). And since
> we're about to have 64-bit Windows support, druntime should be updated with
> whatever C prototypes are in the 64-bit Windows API (and I really don't
> know
> how those relate to the Win32 API other than the fact that as I understand
> it,
> 64-bit Windows still uses some version of the Win32 API).
>
> So, I would hope that the various Windows Gurus around here could come to
> an
> agreement on how the Windows API bindings should be put into druntime and
> then
> someone (or several someones) would take the time to implement that. I
> don't
> think that we should continue with the approach that anyone doing anything
> serious with the Win32 API has to use a 3rd party project to do it.
> OS-level
> functions should be part of druntime for every OS that we support, and it's
> worthy of a bug report every time that we find an OS-level function that
> is not
> in druntime.
>

I'm regularly annoyed by the quality of the druntime windows bindigs. I use
this one: http://www.dsource.org/projects/bindings/wiki/WindowsApi
It's better.

I don't think there's really any room for opinion on the topic, the windows
bindings should simply be complete, and correct.
It's a flat C api, I can't imagine anything in there that doesn't translate
to D well.

As said before, the only details that might require some discussion are the
handling of the windows version macro, and the unicode macro.
I would personally just expect to use them exactly as they are in C, and
expect the user to supply the appropriate versions to D when compiling.

On 24 November 2012 09:23, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/23/2012 5:06 PM, Vladimir Panteleev wrote:
>
>> On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
>>
>>> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>>>
>>>> There might be some incompatibilities, for example due to how the
>>>> HANDLE type is
>>>> declared. In C, you can use either 0 or NULL as a parameter to a
>>>> function
>>>> accepting an integer or pointer. In D, you cannot. IIRC, some types were
>>>> declared differently in Druntime's modules and in the win32 bindings.
>>>>
>>>> If breaking code were not an issue, the best solution would be to make
>>>> HANDLE a
>>>> unique, opaque type (like a struct wrapping an intptr_t or void*) -
>>>> which is
>>>> exactly how it should be treated. It would need to support
>>>> assignment/creation
>>>> from "null" though.
>>>>
>>>
>>> This is why I don't approve of attempts to "fix" Windows APIs. It winds
>>> up
>>> being incompatible here and there, and breaks things.
>>>
>>
>> I don't think I follow the logic of this argument.
>>
>
> Because if we take on the task of "fixing" Windows APIs, then we also take on the task of documenting them, supporting them, educating people about them, and invalidating the river of documentation that already exists on how to program via the Windows APIs.
>

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.

On 24 November 2012 19:34, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>wrote:

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


There already exists a library to do what you're talking about, it's called
glew. And if I were you I'd port that to D aswell, and leave it named as it
is.
People already know what glew does and have lots of existing code written
to use it. It's perfectly good how it is.

How about GLES? That's pretty important these days. I haven't seen a binding for that yet.

On Sat, Nov 24, 2012 at 7:32 PM, Jakob Ovrum <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.
>>
>

On Saturday, 24 November 2012 at 18:53:27 UTC, Manu wrote:
> There already exists a library to do what you're talking about, it's called
> glew. And if I were you I'd port that to D aswell, and leave it named as it
> is.
> People already know what glew does and have lots of existing code written
> to use it. It's perfectly good how it is.
>
> How about GLES? That's pretty important these days. I haven't seen a
> binding for that yet.

DerelictGL does exactly what GLEW does, it's pretty much the whole point of Derelict. I think the other Derelict libraries were added later to take advantage of the runtime linking infrastructure put in place for OpenGL.

I've done git svn clone -s http://svn.dsource.org/projects/bindings
Now I have everything that the dsource WinAPI bindings need (sources, libs,
defs, ...)
I'll fork off Druntime, replace the WinAPI and send a pull request. This
won't take too long. I just need clarification on a few issues:

1. There is a number of version flags that are expected to be specified to the compiler, which specifies the Windows version, Internet Explorer version, winsock version and a bunch of other stuff. I suppose these will go into the sc.ini under Windows, because those won't change too often and are equivalent to linking with phobos (not necessary, but provided as a default).

2. There are some static libraries, which are pragma(lib, ...) -ed inside those modules, so those libraries will have to be included to the DMD distribution.

3. They include MinGW copyright and header comments, which I don't know if can be submitted to druntime as is and if they can be removed either.

4. They contain a special WindowsUnitTests version, which could probably be replaced with a regular unittests or removed from the DMD distribution.

5. They look dangerously awesome! :-D

Walter, Andrei and all others who maintain Druntime: I need you to tell me if these five conditions are OK and if I should change something before sending a pull request.

-- 
Bye,
Gor Gyolchanyan.

On 11/24/2012 10:45 AM, Manu wrote:
> I'm regularly annoyed by the quality of the druntime windows bindigs. I use this
> one: http://www.dsource.org/projects/bindings/wiki/WindowsApi
> It's better.
>
> I don't think there's really any room for opinion on the topic, the windows
> bindings should simply be complete, and correct.
> It's a flat C api, I can't imagine anything in there that doesn't translate to D
> well.

You can always simply add the ones you need to druntime, and issue a pull request.

> As said before, the only details that might require some discussion are the
> handling of the windows version macro, and the unicode macro.
> I would personally just expect to use them exactly as they are in C, and expect
> the user to supply the appropriate versions to D when compiling.

I'd forget about the unicode macro, and call the A or W versions explicitly.

Also, exactly what package should I put them?
I suppose core.sys.windows.*
Although the core.sys.windows contains some D-specific modules, which
wouldn't be nice to mix with the native modules (and there are tons of
those).


On Sat, Nov 24, 2012 at 11:28 PM, Gor Gyolchanyan < gor.f.gyolchanyan@gmail.com> wrote:

> I've done git svn clone -s http://svn.dsource.org/projects/bindings
> Now I have everything that the dsource WinAPI bindings need (sources,
> libs, defs, ...)
> I'll fork off Druntime, replace the WinAPI and send a pull request. This
> won't take too long. I just need clarification on a few issues:
>
> 1. There is a number of version flags that are expected to be specified to the compiler, which specifies the Windows version, Internet Explorer version, winsock version and a bunch of other stuff. I suppose these will go into the sc.ini under Windows, because those won't change too often and are equivalent to linking with phobos (not necessary, but provided as a default).
>
> 2. There are some static libraries, which are pragma(lib, ...) -ed inside those modules, so those libraries will have to be included to the DMD distribution.
>
> 3. They include MinGW copyright and header comments, which I don't know if can be submitted to druntime as is and if they can be removed either.
>
> 4. They contain a special WindowsUnitTests version, which could probably be replaced with a regular unittests or removed from the DMD distribution.
>
> 5. They look dangerously awesome! :-D
>
> Walter, Andrei and all others who maintain Druntime: I need you to tell me if these five conditions are OK and if I should change something before sending a pull request.
>
> --
> Bye,
> Gor Gyolchanyan.
>



-- 
Bye,
Gor Gyolchanyan.

On 24 November 2012 21:32, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/24/2012 10:45 AM, Manu wrote:
>
>> I'm regularly annoyed by the quality of the druntime windows bindigs. I
>> use this
>> one: http://www.dsource.org/**projects/bindings/wiki/**WindowsApi<http://www.dsource.org/projects/bindings/wiki/WindowsApi>
>> It's better.
>>
>> I don't think there's really any room for opinion on the topic, the
>> windows
>> bindings should simply be complete, and correct.
>> It's a flat C api, I can't imagine anything in there that doesn't
>> translate to D
>> well.
>>
>
> You can always simply add the ones you need to druntime, and issue a pull request.


Sure, but that's rather time consuming, and the other library I linked is
pretty decent.
I'm just supporting the case that more thorough support in druntime would
be warmly welcomed :)


As said before, the only details that might require some discussion are the
>> handling of the windows version macro, and the unicode macro.
>> I would personally just expect to use them exactly as they are in C, and
>> expect
>> the user to supply the appropriate versions to D when compiling.
>>
>
> I'd forget about the unicode macro, and call the A or W versions explicitly.
>

This causes rather annoying issues while porting, and tutorials becomes
obscured. Many novice programmers don't understand that most functions are
an alias of *A/*U, will be confused by the errors, and I even know many
programmers who don't understand what unicode is, therefore don't
understand the decision they are making.
I think the aliases are important, they allow tutorials and novice users to
continue to work effectively.