I really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.

On Saturday, January 28, 2012 09:41:21 Andrej Mitrovic wrote:
> I really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.

It will definitely be more organized than that. I would think that it would be organized along the lines of how the win32 API itself is organized, but I don't know. It probably also depends on what the current bindings project does. A giant windows.d would definitely be rejected though.

- Jonathan M Davis

On Friday, 27 January 2012 at 20:37:04 UTC, Vladimir Panteleev wrote:
> The files in the Windows API bindings project are translations from the MinGW headers, which were created based on the documentation (which explains the occasional errors). The MinGW headers are public domain. Considering that MinGW is not an obscure project, I think we're on safe legal ground here.

Things like CRITICAL_SECTION are documented as opaque structures.
http://social.msdn.microsoft.com/Forums/en-US/winembplatdev/thread/3856c437-9a7e-4315-a954-fc50e25a12f2

I also remember MinGW folks were asked about this, but they don't know, where the headers came from.

On Saturday, 28 January 2012 at 09:22:33 UTC, Jonathan M Davis wrote:
> On Saturday, January 28, 2012 09:41:21 Andrej Mitrovic wrote:
>> I really hope druntime doesn't get one gigantic windows.d file. I
>> don't want to wait seconds for syntax highlighting to kick in because
>> a file is huge.
>
> It will definitely be more organized than that. I would think that it would be organized along the lines of how the win32 API itself is organized, but I don't know. It probably also depends on what the current bindings project does. A giant windows.d would definitely be rejected though.

http://www.dsource.org/projects/bindings/browser/trunk/win32/windows.d

On 1/28/12, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> http://www.dsource.org/projects/bindings/browser/trunk/win32/windows.d

Well sheeeit, somehow I never noticed that file being there.

Am 28.01.2012, 11:22 Uhr, schrieb Kagamin <spam@here.lot>:

> I also remember MinGW folks were asked about this, but they don't know, where the headers came from.

I understand that Microsoft prefers Visual Studio to be used with one of their compilers, but you can't honestly sue anyone nowadays for copying headers to interface with the OS. It is Windows, the most used OS on consumer PCs. Who's gain was it if a major part of open source software was locked out because they couldn't port the application due to missing OS headers. If you always looked only on the legal side of things, you would be allowed and disallowed absurd things:
http://www.guardian.co.uk/politics/2007/nov/07/uk.queensspeech20072
The other ingredient is common sense. - So you don't buy Visual Studio, which may be a loss for MS, if those OSS developers would have switched to Windows, bought VS etc... in the other case, Windows loses popularity as a platform, because a lot of software wont be ported. With the background of the legal debate about making IE4 a part of the operating system I'd assume that some degree of freedom and choice of software is today considered almost as valuable as a formal copyright in a header file.
It would be different if WINE somehow got the Windows source code and was only through this event becoming an alternative that made Windows obsolete. But I think we had the header/interface discussion here already :)

Am 28.01.2012, 09:41 Uhr, schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> I really hope druntime doesn't get one gigantic windows.d file. I
> don't want to wait seconds for syntax highlighting to kick in because
> a file is huge.

No, it should be done like everywhere else where the IDEs have no problem dealing with the Windows headers. C++, Delphi, ... . I think COM and WinSock are usually separate, whereas user32 and kernel32 are commonly imported through one file. I may be wrong. If a particular IDE/editor is slow it must be fixed :)