On Saturday, 24 November 2012 at 21:18:33 UTC, Andrej Mitrovic wrote:
> 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)?


Gor's rush makes me feel a little uneasy...


On Friday, 23 November 2012 at 14:08:05 UTC, Gor Gyolchanyan wrote:
> Can someone please explain to me what "_declspec(dllimport)",
> "__declspec(dllexport)" (both of which are just "export" in D) are for,

On Sunday, November 25, 2012 14:39:31 Dmitry Olshansky wrote:
> 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)

I'd actually be halfway tempted to explicitly omit the A versions simply because you basically should _never_ use them unless you're supporting Win9x, which we're not.

- Jonathna M Davis

On Sunday, 25 November 2012 at 10:49:20 UTC, Gor Gyolchanyan wrote:
> 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.
>

No, that's just wrong. DerelictGL3.load() loads the DLL into memory along with the 1.1 interface. Then after you create a context, DerelictGL3.reload() will use wglGetProcAddress to load the rest of OpenGL up to the highest supported version. Do you really think that people would have been using Derelict for the past 8+ years if it didn't give them access to hardware-accelerated OpenGL?

On 25 November 2012 14:30, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

>
> I'd actually be halfway tempted to explicitly omit the A versions simply
> because you basically should _never_ use them unless you're supporting
> Win9x,
> which we're not.
>

Except that they're the default, basically all tutorial code and much existing code is written to use 8-bit strings. It's really lame there is no utf-8 api.

On Sunday, 25 November 2012 at 22:09:53 UTC, Manu wrote:
> On 25 November 2012 14:30, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>>
>> I'd actually be halfway tempted to explicitly omit the A versions simply
>> because you basically should _never_ use them unless you're supporting
>> Win9x,
>> which we're not.
>>
>
> Except that they're the default, basically all tutorial code and much
> existing code is written to use 8-bit strings. It's really lame there is no
> utf-8 api.

I agree with Jonathan. The Ansi is not quite the default anymore, maybe for some old documentation or old code. Unicode is the default encoding when you create a new project in Visual Studio, in samples they use a lot the TCHAR/LPTSTR-Macros (sometimes the wstring). And is clear that you _should_ use the W APIs (directly or through UNICODE define) or you are later in trouble.

On Sun, 25 Nov 2012 08:13:23 -0000, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

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

In the Win32 headers the ASCII version is the default and -DUNICODE selects the UNICODE version.  e.g.

#ifdef UNICODE
#define CreateFile  CreateFileW
#else
#define CreateFile  CreateFileA
#endif // !UNICODE

But, this was for backward compatibility reasons primarily.

I believe it's more efficient to call the UNICODE versions on the more modern windows operating systems.  So, based on the platform selected (using _WIN32_WINNT or similar) we should default to the most appropriate version.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/