www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Programming Windows D Examples are now Online!

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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*
Jun 20 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Jun 20 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 20 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Jun 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 21 2011
parent reply Trass3r <un known.com> writes:
Am 21.06.2011, 20:32 Uhr, schrieb Andrej Mitrovic  
<andrej.mitrovich gmail.com>:

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


That is indeed long overdue!
Jun 21 2011
parent Jimmy Cao <jcao219 gmail.com> writes:
On Tue, Jun 21, 2011 at 4:29 PM, Trass3r <un known.com> wrote:


 Am 21.06.2011, 20:32 Uhr, schrieb Andrej Mitrovic <
 andrej.mitrovich gmail.com>:

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


 That is indeed long overdue!


I feel like I cannot express how immensely helpful such an addition would
be.
Jun 21 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jun 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 21 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Jun 21 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jun 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, bearophile <bearophileHUGS lycos.com> wrote:

 After translating so much code have you seen some recurring patterns in your
 code conversion bugs?


A lot of C code is missing default labels. I've used the github 2.054
clone to compile all examples in order to catch missing labels at
compile time. I've missed many of them before this feature became
available.

Float/Doubles are initialized to NaN in D, however I don't know what
they're initialized to in C. But it seems none of the examples had
floating point variables initialized. This causes halts/exceptions in
D, and without ddbg it's really hard to track down what went wrong. I
don't think the stack traces helped me in this regard. Generally
forgetting to initialize floats seems to be common in other C code as
well.

C struct initializer syntax is used for static arrays of structs in
the C code. I think this could easily be a source of bugs if you add
or remove fields from a struct. I'm not sure if that syntax works in D
but I've used explicit ctor calls instead, such as:

struct Foo { int x, y; }
Foo[5] foo = [Foo(1, 2), Foo(1, 2), Foo(1, 2), Foo(1, 2), Foo(1, 2)];

It's verbose but it's safer.

In some code a variable would be defined as an int, and returned as a
short. There are other cases where it's defined as an int, and then
casted to a ubyte (BYTE is an alias for ubyte there). I have to fix
some of these.

I did notice an annoying thing with D, for example:
ubyte val = min(0, 128);
Error: cannot implicitly convert expression (min(0,128)) of type int to ubyte

The problem with this is I have to add a cast or a safer to!() call.
to!() can only do a runtime check:
ubyte val = to!ubyte(min(1024, 2048));  // overflow exception at runtime

And a cast is completely unsafe:
ubyte val = cast(ubyte)(min(1024, 2048));  // no error, bugs introduced!

Of course the compiler doesn't know what min does, only that it
returns an int, so I don't know whether it could ever figure out that
a function would never return a value that overflows the assignment
variable (maybe this feature could be implemented for pure
functions..).

C Globals become an instant source of bugs as soon as you fire up a
new thread. This is due to D's thread-local storage by default
feature. I like D's approach, and C globals should be replaced with
messaging or some other technique. I've used __gshared in various
modules to make the examples compile and work properly, but this
should be replaced.
This isn't unique to these examples. I've seen globals used everywhere
for messaging purposes in C code, e.g. some audio processing examples
in a different library.

A weird thing I've seen in the examples was a pointer to a static
variable was passed to a newly spawned thread's function. And via this
static variable the original thread and the work thread communicated
together. How this can work is beyond me, but it can't work in D.
Luckily D's spawn() function does offer protection for this kind of
code.

These examples used implicit fallbacks a lot, with only a comment
explicitly mentioning that there is a fallback in play. I think it's
good that we've abandoned implicit fallbacks, they could easily cause
bugs.
But, on the other hand someone might get an error about an implicit
fallback and think they forgot to add a "break" when porting C code.
So they add that, but now they've introduced a bug because the
fallback was actually necessary. I had this happen to me in one
example because the fallback wasn't explicitly mentioned.

There are issues with calling format() and writef(). This is not just
for this translation project. Most C code uses some form of
printf/wsprintf to either store a string to a variable or print it
out. But the format specifiers often do not translate into D. I think
what is probably causing this is that C types are not the same as D
types, so when you see this in C code:
printf("Note Count %ld, (long) notescount);

This might not translate into D and you could easily get an exception
at runtime (a pity that this doesn't get caught at compile-time). The
root of the problem is that the format specifiers explicitly name the
type, while you inadvertently change the actual type in D (maybe you
were fixing a conversion bug), and then you randomly get an exception
thrown at runtime.


whatsoever. You just get back "Invalid format specifier" or something
like that. This is of no help, and I always have to fire up ddbg or
manually hunt down each format specifier and replace it with D's safe
"%s", which works great.
The exceptions with no error line problem is common for most Phobos
functions, I absolutely hate getting back an error message such as:
std.exception.ErrnoException std\stdio.d(286): Cannot open file
`blablabla' in mode `r' (No such file or directory)

No stack trace, no error line except the error line in Phobos. I
*don't care* about error lines in Phobos, the error is in my code not
in Phobos, and I really think this needs to improve.

Many functions assume ASCII or USC2, both of which are wrong to assume
these days. I have some examples I still have to fix, because I've
used code like:
    string buffer;
    TextOut(buffer.toUTF16z, buffer.length);
This is incorrect code. TextOut takes the number of characters, not
code units when issuing the call. The code will compile and run fine
for the majority of cases because most characters will fit into
wchar's code point, and you will have a 1to1 code-point to code-unit
ratio. But add a Japanese character and you will see garbage being
printed out to the screen. The correct workaround for this is to
either:
1) Store everything as a dchar[]:
    dstring buffer;
    TextOut(buffer.toUTF16z, buffer.length);  // correct as long as
UTF never has more than 4 code units
2) Use some Phobos code-point counting function
    string buffer;
    TextOut(buffer.toUTF16z, std.utf.count(buffer));

The second option might cause performance issues, while using UTF32
dchars might cause excessive use of memory. Other solutions might be
to wrap strings and cache the count of code points. It's a balancing
act between memory and performance.

Some API functions take char* as a parameter when expecting some
pointer to a data buffer which can but doesn't necessarily store text.
I don't know why char* is used instead of void*, perhaps char* are
more often used with these functions so they've decided to type it
like that.

There are many cases of implicit 0 to void* casts, but D catches this
at compile time.

A big issue with porting is that D's character arrays are always
initialized to invalid values. This wreaks havoc in code, in
particular with static arrays. For example:

    char[100] buffer;
    APIWriteToBuffer(buffer.ptr);
    myDStringFunction(buffer[]);  // <- buggy code

The problem is twofold. First, the API call might not work because it
could easily expect a null terminator to be present as a first
character:
    char[100] buffer;
    APIWriteToBuffer(buffer.ptr);  // Might not work!

So I've had to do this:
    char[100] buffer;
    buffer[] = '\0';  // or buffer[0] = '\0', depending on the function
    APIWriteToBuffer(buffer.ptr);

Second, after the call you will have a buffer that has some valid text
stored into it, and then either null terminators to the length of the
array (if you did buffer[] = '\0'), OR you will have a null terminator
followed by a series of char.init invalid UTF values.

So when you finally call a D function with such a static array, it
could print out garbage or throw an exception:
    char[100] buffer;
    APIWriteToBuffer(buffer.ptr);
    myDStringFunction(buffer[]);  // what will this function do when
stumbles on '\0' or char.init?

Behind the scense that D function might in turn call a C function, so
continued from the last example:
    char[100] buffer;
    APIWriteToBuffer(buffer.ptr);
    myDStringFunction(buffer[]);

    void myDStringFunction(char[] buffer)
    {
        // huge mess, the API function might write nonsense like ['f',
'o', 'o', '\0', char.init, char.init..]
        APIPrintToScreen(buffer.ptr, buffer.length);
    }

So you have to do conversion and duplication all the time. You have to do:

    char[100] buffer;
    APIWriteToBuffer(buffer.ptr);  // buffer might now be ['f', 'o',
'o', '\0', char.init, char.init..];
    myDStringFunction(to!string(buffer.ptr.toStringz));

How it works: First, you need to treat the buffer as a C
null-terminated char array, hence using .ptr. Then, you have to call a
Phobos function so it can retrieve a string until the first null
terminator.

But it gets worse when UTF is in play because in v2.043 conv.to
doesn't know how to convert wchar*'s. I've made a request on github
and I think this feature will be incorporated, but for now you can't
do this:

    wchar[100] buffer;
    APIWriteToBuffer(buffer.ptr);
    myDStringFunction(to!string(buffer.ptr));  // error, to!() can't
convert wchar*

So I've had to create my own function which converts a wchar* to
wchar[], which can then be used for whatever purpose:

    wchar[100] buffer;
    APIWriteToBuffer(buffer.ptr);
    myDStringFunction(to!string(fromWStringz(buffer.ptr)));

So generally static arrays of characters and string handling between C
and D can be painful.
Jun 21 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 12:35 PM, Andrej Mitrovic wrote:

 [...]


This is interesting and valuable information. Please add it to your repository 
as a readme, or even as a blog post!
Jun 21 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 12:35 PM, Andrej Mitrovic wrote:

 Float/Doubles are initialized to NaN in D, however I don't know what
 they're initialized to in C.


In C they're initialized to 0 for globals, and garbage for locals and allocated 
data.



 A big issue with porting is that D's character arrays are always
 initialized to invalid values. This wreaks havoc in code, in
 particular with static arrays. For example:

      char[100] buffer;
      APIWriteToBuffer(buffer.ptr);
      myDStringFunction(buffer[]);  //<- buggy code


In C buffer is not initialized to 0, if it is not global, it is initialized to 
garbage.


 The problem is twofold. First, the API call might not work because it
 could easily expect a null terminator to be present as a first
 character:
      char[100] buffer;
      APIWriteToBuffer(buffer.ptr);  // Might not work!


Fix:

        char[100] buffer = 0;


 So when you finally call a D function with such a static array, it
 could print out garbage or throw an exception:
      char[100] buffer;
      APIWriteToBuffer(buffer.ptr);
      myDStringFunction(buffer[]);  // what will this function do when
 stumbles on '\0' or char.init?


Fix:
	char[100] buffer;
	APIWriteToBuffer(buffer.ptr);
         auto p = buffer[0 .. strlen(buffer.ptr)];
	myDStringFunction(p);
Jun 21 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Walter Bright <newshound2 digitalmars.com> wrote:

 Fix:

         char[100] buffer = 0;


I didn't know about this syntax! I've been under a rock apparently.


 Fix:
 	char[100] buffer;
 	APIWriteToBuffer(buffer.ptr);
          auto p = buffer[0 .. strlen(buffer.ptr)];
 	myDStringFunction(p);


Yeah I was going to suggest that. My only problem was I didn't know
where to look for an strlen equivalent for UTF, but I found it in
std.utf and it's called stride().

I'll fix these examples soon. I'll give a thought or two about that
blogging idea as well, thanks.
Jun 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 1:46 PM, Andrej Mitrovic wrote:

 	char[100] buffer;
 	APIWriteToBuffer(buffer.ptr);
           auto p = buffer[0 .. strlen(buffer.ptr)];
 	myDStringFunction(p);


 Yeah I was going to suggest that. My only problem was I didn't know
 where to look for an strlen equivalent for UTF, but I found it in
 std.utf and it's called stride().


I think there's a misunderstanding somewhere. strlen() works just fine on UTF-8 
code.
Jun 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/22/11, Walter Bright <newshound2 digitalmars.com> wrote:

 I think there's a misunderstanding somewhere. strlen() works just fine on
 UTF-8
 code.


I need a UTF16 strlen function for wchar*.
Jun 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 5:41 PM, Andrej Mitrovic wrote:

 I need a UTF16 strlen function for wchar*.


wcslen()
Jun 21 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/22/11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 6/21/2011 5:41 PM, Andrej Mitrovic wrote:

 I need a UTF16 strlen function for wchar*.


 wcslen()


You, sir, are a gentleman and a scholar.
Jun 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 6:08 PM, Andrej Mitrovic wrote:

 You, sir, are a gentleman and a scholar.


I've been called worse :-)
Jun 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Now on YC too: http://news.ycombinator.com/item?id=2681216
Jun 21 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-06-21 13:46, Andrej Mitrovic wrote:

 On 6/21/11, Walter Bright <newshound2 digitalmars.com> wrote:

 Fix:
 char[100] buffer = 0;


 
 I didn't know about this syntax! I've been under a rock apparently.
 

 Fix:
 char[100] buffer;
 APIWriteToBuffer(buffer.ptr);
 
 auto p = buffer[0 .. strlen(buffer.ptr)];
 
 myDStringFunction(p);


 
 Yeah I was going to suggest that. My only problem was I didn't know
 where to look for an strlen equivalent for UTF, but I found it in
 std.utf and it's called stride().


stride isn't a UTF version of strlen. stride returns how many code units it is 
to the beginning of the next code point. You can use it to get the number of 
characters in a string by calling it in a loop, but it isn't a UTF version of 
strlen.

- Jonathan M Davis
Jun 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 stride isn't a UTF version of strlen.


Brain misshap, I meant std.utf.count.
Jun 21 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Walter, would it be possible to make .map file generation follow the
-od flag? It's odd when a  build script fills a directory with map
files while executables and object files are properly in their own
directories as specified via -od and -of flags.

Btw, I have just pushed a changeset and made the build script
parallel. I turned this:
foreach (dir; dirs)

into this:
foreach (dir; taskPool.parallel(dirs, 1))

And added other small cosmetic changes, but the above is the only real change.

Here's my timings:
Serial build: 1min, 3sec
Parallel build: 22sec
Jun 21 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 21/06/2011 22:24, Andrej Mitrovic wrote:

 Walter, would it be possible to make .map file generation follow the
 -od flag? It's odd when a  build script fills a directory with map
 files while executables and object files are properly in their own
 directories as specified via -od and -of flags.

 Btw, I have just pushed a changeset and made the build script
 parallel. I turned this:
 foreach (dir; dirs)

 into this:
 foreach (dir; taskPool.parallel(dirs, 1))

 And added other small cosmetic changes, but the above is the only real change.

 Here's my timings:
 Serial build: 1min, 3sec
 Parallel build: 22sec


I use D as a build script for my project too, it's awesome how easy it 
is to make the build parallel, and how much compilation time it saves!

Side note: parallel() works as an alias for taskPool.parallel, saves you 
some characters and looks nicer!

-- 
Robert
http://octarineparrot.com/
Jun 21 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Robert Clipsham <robert octarineparrot.com> wrote:

 I use D as a build script for my project too, it's awesome how easy it
 is to make the build parallel, and how much compilation time it saves!


Yeah, true words right there. RDMD is what makes everything run so
smooth, it feels like coding in Python.


 Side note: parallel() works as an alias for taskPool.parallel, saves you
 some characters and looks nicer!


Right you are. Fixed!

I can't believe how easy it is to just fix and push something online.
It's quite exciting.
Jun 21 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok I've made most of the examples unicode safe now by using
std.utf.count instead of .length. The changesets are online.
Jun 21 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 2:24 PM, Andrej Mitrovic wrote:

 Walter, would it be possible to make .map file generation follow the
 -od flag? It's odd when a  build script fills a directory with map
 files while executables and object files are properly in their own
 directories as specified via -od and -of flags.


I think it's a good idea. Please post to bugzilla!


 Btw, I have just pushed a changeset and made the build script
 parallel. I turned this:
 foreach (dir; dirs)

 into this:
 foreach (dir; taskPool.parallel(dirs, 1))

 And added other small cosmetic changes, but the above is the only real change.

 Here's my timings:
 Serial build: 1min, 3sec
 Parallel build: 22sec


Awesome!
Jun 21 2011
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 6/21/2011 2:24 PM, Andrej Mitrovic wrote:

 Walter, would it be possible to make .map file generation follow the
 -od flag? It's odd when a  build script fills a directory with map
 files while executables and object files are properly in their own
 directories as specified via -od and -of flags.
 
 Btw, I have just pushed a changeset and made the build script
 parallel. I turned this:
 foreach (dir; dirs)
 
 into this:
 foreach (dir; taskPool.parallel(dirs, 1))
 
 And added other small cosmetic changes, but the above is the only real change.
 
 Here's my timings:
 Serial build: 1min, 3sec
 Parallel build: 22sec


Fixed in 2.053.  See also bug 4833.
Jun 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Brad Roberts <braddr puremagic.com> wrote:

 Fixed in 2.053.  See also bug 4833.


Well that's odd because the script still generates map files in the
root directory of the script file even though I'm using -od and -of,
and I'm using 2.053. I've added a cleanup call after each sample is
built so every map file is deleted from the root dir.
Jun 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Wait, I'm using 2.054 from github. This might be a regression. I'll investigate.
Jun 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
No I've tested with 2.053 and it still generates a map file. I'll
reopen that report.
Jun 21 2011
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 6/21/2011 2:45 PM, Andrej Mitrovic wrote:

 Wait, I'm using 2.054 from github. This might be a regression. I'll
investigate.


I just checked the source for dmd's link.c (where the changes were) and it
hasn't changed.  I just ran some quick tests
on linux and it appears to be working correctly still.  Testing on windows is a
tad more painful for me, so I haven't
re-tested it there.  Take a look at the pull request listed in the ticket for
the test cases that were run.

Something you're doing is different than the test cases (which were tested on
win32 as well as linux at the time).
Jun 21 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 6/21/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 stride isn't a UTF version of strlen.


 Brain misshap, I meant std.utf.count.


Double brain misshap. I wasn't looking for code-point count of a D
string, but of a zero-terminated wchar*.
Jun 21 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2011 4:17 PM, Andrej Mitrovic wrote:

 On 6/21/11, Andrej Mitrovic<andrej.mitrovich gmail.com>  wrote:

 On 6/21/11, Jonathan M Davis<jmdavisProg gmx.com>  wrote:

 stride isn't a UTF version of strlen.


 Brain misshap, I meant std.utf.count.


 Double brain misshap. I wasn't looking for code-point count of a D
 string, but of a zero-terminated wchar*.


wcslen()
Jun 21 2011
prev sibling next sibling parent zsxxsz <zhengshuxin gmail.com> writes:
Excellent! I've build and run it all ok.
Jun 21 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/20/11 11: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*


Now on reddit:

http://www.reddit.com/r/programming/comments/i5m0c/petzolds_windows_programming_5th_ed_code_samples/


Andrei
Jun 21 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/21/11 4:28 PM, Andrei Alexandrescu wrote:

 On 6/20/11 11: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*


 Now on reddit:

 http://www.reddit.com/r/programming/comments/i5m0c/petzolds_windows_programming_5th_ed_code_samples/


And now approved.

Andrei
Jun 21 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 21.06.2011 06:14, schrieb Andrej Mitrovic:

 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*


The README mentions 2.043 instead of 2.053.

Cheers,
- Daniel
Jun 21 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/21/11, Daniel Gibson <metalcaedes gmail.com> wrote:

 The README mentions 2.043 instead of 2.053.


Fixed, thanks.
Jun 21 2011