This is a translation project of Charles Petzold's Programming Windows (5th edition) book code samples.

Currently over 120 code samples have been translated into D, with only a few modules remaining.

Everything else you need to know is in the Readme file: https://github.com/AndrejMitrovic/DWindowsProgramming

The examples were tested on fresh installs of XP and Win7 with the only dependency being DMD v2.053 and an NT operating system. I hope everyone will be able to build these examples without too much trouble. *crosses fingers*

On 6/20/2011 9:14 PM, Andrej Mitrovic wrote:
> This is a translation project of Charles Petzold's Programming Windows
> (5th edition) book code samples.
>
> Currently over 120 code samples have been translated into D, with only
> a few modules remaining.
>
> Everything else you need to know is in the Readme file:
> https://github.com/AndrejMitrovic/DWindowsProgramming
>
> The examples were tested on fresh installs of XP and Win7 with the
> only dependency being DMD v2.053 and an NT operating system. I hope
> everyone will be able to build these examples without too much
> trouble. *crosses fingers*

This is nice work. When you're done, let's post a link on Reddit!

On 6/21/11, Walter Bright <newshound2@digitalmars.com> wrote:
> This is nice work. When you're done, let's post a link on Reddit!

Let's shake the bees nest? :p

I'll have to make some kind of workaround for D DLLs for a few examples. I'll see about doing this these days. There's a few audio examples I'll finish tomorrow (I just need to plug my guitar to see if it records anything), and then I'm almost done with making all examples compile. After that some polishing can be done gradually.

Btw, would it be good idea to link this somewhere on the homepage? Maybe a page like this: http://d-programming-language.org/windows.html

I've already linked it from the dwiki.

Andrej Mitrovic:

> Everything else you need to know is in the Readme file: https://github.com/AndrejMitrovic/DWindowsProgramming

It looks like a lot of work!
I have not tried to compile the code yet.

I am not asking you to modify the code, but D with() was designed to reduce noise in code like:

    wndclass.style = CS_HREDRAW | CS_VREDRAW;
    wndclass.lpfnWndProc = &WndProc;
    wndclass.cbClsExtra = 0;
    wndclass.cbWndExtra = 0;
    wndclass.hInstance = hInstance;
    wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
    wndclass.hbrBackground = cast(HBRUSH) GetStockObject(WHITE_BRUSH);
    wndclass.lpszMenuName = appName.toUTF16z;
    wndclass.lpszClassName = appName.toUTF16z;


The code in those examples is generally very noisy (I presume about as much as the original code). I have mixed feelings about it.

Sometimes final switches are not easy to retrofit.

Bye,
bearophile

Excellent! I've build and run it all ok.

On 6/21/11, bearophile <bearophileHUGS@lycos.com> wrote:
> I am not asking you to modify the code, but D with() was designed to reduce
> noise in code like:
>
>     wndclass.style = CS_HREDRAW | CS_VREDRAW;
>     wndclass.lpfnWndProc = &WndProc;
>     wndclass.cbClsExtra = 0;
>     wndclass.cbWndExtra = 0;
>     wndclass.hInstance = hInstance;
>     wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
>     wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
>     wndclass.hbrBackground = cast(HBRUSH) GetStockObject(WHITE_BRUSH);
>     wndclass.lpszMenuName = appName.toUTF16z;
>     wndclass.lpszClassName = appName.toUTF16z;

Yes, the original code is quite noisy, especially considering that a lot of code uses pointers and state variables for strcpy calls and things like that.

>
> The code in those examples is generally very noisy (I presume about as much as the original code). I have mixed feelings about it.

Yes, it's noisy because of a couple of things:

1. I haven't worked a lot on actually using D idioms. My main concern was making the examples compile and work in the exact way as the original examples. Having a 1-to-1 translation helps in catching bugs (and I've had quite a few of those).

2. Generally calling into GDI is going to be much more noisy than using some 3rd party GUI library, the same goes for various other WinAPI functions as well. You have to manually acquire and release GDI resources so this complicates things.

3. I've added some excessive noise in some code since I've used a lot of to!string() and duplication workarounds to get the examples compiling. This will be replaced with better code.

The examples will be continued to be improved and refactored, but I had to start hosting them otherwise I'd never finish the project.

On 6/20/2011 10:11 PM, Andrej Mitrovic wrote:
> Btw, would it be good idea to link this somewhere on the homepage?

Sure! Wanna generate a pull request?

On 6/21/2011 8:58 AM, Andrej Mitrovic wrote:
> The examples will be continued to be improved and refactored, but I
> had to start hosting them otherwise I'd never finish the project.

I'm glad you decided to host them on github. Github has been a great boon for D in crowdsourcing improvements!

Andrej Mitrovic:

> Having a 1-to-1 translation helps in catching bugs
> (and I've had quite a few of those).

After translating so much code have you seen some recurring patterns in your code conversion bugs?
Time ago I have suggested a -cstyle compiler switch to DMD that activates some C-isms like C-style array declarations, and activates warnings useful to catch common conversion bugs, like a warning against passing by value large fixed-static arrays, having large static arrays of floating point values (that are initialized with NaN, so they cause quite large binaries), and so on.


> 2. Generally calling into GDI is going to be much more noisy than using some 3rd party GUI library,

Right. I'd like the standard D distribution to have a little graphics module like simplegraphics, that I use now and then (not written by me) :-)

Bye,
bearophile

On 6/21/11, Walter Bright <newshound2@digitalmars.com> wrote:
> On 6/20/2011 10:11 PM, Andrej Mitrovic wrote:
>> Btw, would it be good idea to link this somewhere on the homepage?
>
> Sure! Wanna generate a pull request?
>

Yeah I'll cook something up and make a pull.

Btw, std.c.windows.windows and the WindowsAPI bindings clash when used together. The root of the problem is type definitions like these:

typedef void* HINSTANCE;

The problem is that both bindings create this typedef, and the compiler treats them as separate types. From what I recall I've tried to compile something like this before (this is just a snippet):

import win32.windef;
import core.sys.windows.dll;

extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
    switch (ulReason)
    {
        case DLL_PROCESS_ATTACH:
            g_hInst = hInstance;
            dll_process_attach( hInstance, true );
            break;

        case DLL_PROCESS_DETACH:
            dll_process_detach( hInstance, true );
            break;

        case DLL_THREAD_ATTACH:
            dll_thread_attach( true, true );
            break;

        case DLL_THREAD_DETACH:
            dll_thread_detach( true, true );
            break;

        default:
    }

    return true;
}

However this won't work. dll_process_attach() can't be called with the `hInstance` argument because it's defined as a typedef in `win32.windef`, while dll_process_attach has the parameter defined as a typedef somewhere in `core.windows` or a similar module.

I don't know whether it is planned to incorporate the WinAPI bindings into Phobos/Druntime, there's at least 2.5 megs of code in prototypes and I'm not sure about the license (it's based on the MinGW headers).

std.c.windows.windows is already growing as people need to call more API functions (just recently a bunch of prototypes were added for std.registry). It seems odd having to waste time writing function prototypes when this was already done long ago in the WinAPI bindings.