www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Operaror 'new' inside WinMain crashes at runtime

reply Serg Kovrov <kovrov no.spam> writes:
Consider this sample:

 import std.c.windows.windows;
 
 class Test {}
 
 extern (Windows)
 int WinMain(HINSTANCE instance, HINSTANCE prevInstance, LPSTR cmdLine, int
cmdShow)
 {
 	new Test(); // <-- here
 	return 0;
 }


When running executable got a runtime error. There is some info/dump on 
the error, but I can't save/copy it. This is part of it: Exception 
Information - code: 0xc0000005; Flags: 0x00000000; record: 
0x0000000000000000; Address: 0x0000000000402be5; and some system 
information, followed lots of modules information...

This only occurs within WinMain program. eg console
application (with 'main()' entry) did not reproduce this error.

Compiled with: `dmd test.d gdi32.lib test.def`
test.def is standard windows def:

 EXETYPE NT
 SUBSYSTEM WINDOWS


Can anyone confirm this?

-- 
serg.
Aug 08 2006
next sibling parent Serg Kovrov <kovrov no.spam> writes:
Forget to mention - DMD Compiler v0.163

-- 
serg.
Aug 08 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 09 Aug 2006 03:12:47 +0300, Serg Kovrov wrote:


 Consider this sample:

 import std.c.windows.windows;
 
 class Test {}
 
 extern (Windows)
 int WinMain(HINSTANCE instance, HINSTANCE prevInstance, LPSTR cmdLine, int
cmdShow)
 {
 	new Test(); // <-- here
 	return 0;
 }


 
 When running executable got a runtime error. There is some info/dump on 
 the error, but I can't save/copy it. This is part of it: Exception 
 Information - code: 0xc0000005; Flags: 0x00000000; record: 
 0x0000000000000000; Address: 0x0000000000402be5; and some system 
 information, followed lots of modules information...
 
 This only occurs within WinMain program. eg console
 application (with 'main()' entry) did not reproduce this error.
 
 Compiled with: `dmd test.d gdi32.lib test.def`
 test.def is standard windows def:

 EXETYPE NT
 SUBSYSTEM WINDOWS


 
 Can anyone confirm this?


Confirmed. However this is not the way to write Windows apps. You missed
out all the GC stuff. The code should look like this ...

import std.c.windows.windows;

extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _minit();
extern (C) void _moduleCtor();
extern (C) void _moduleDtor();
extern (C) void _moduleUnitTests();

extern (Windows)
int WinMain(HINSTANCE instance, HINSTANCE prevInstance, LPSTR cmdLine, int
cmdShow)
{
    int result;

    gc_init();          // initialize garbage collector
    _minit();           // initialize module constructor table

    try
    {
        _moduleCtor();      // call module constructors
        _moduleUnitTests(); // run unit tests (optional)

        result = mymain(instance, prevInstance, cmdLine, cmdShow);

        _moduleDtor();      // call module destructors
    }

    catch (Object o)        // catch any uncaught exceptions
    {
        MessageBoxA(null, cast(char *)o.toString(), "Error",
            MB_OK | MB_ICONEXCLAMATION);
        result = 0;     // failed
    }

    gc_term();          // run finalizers; terminate garbage collector
    return result;
}

class Test {}
int mymain(HINSTANCE instance, HINSTANCE prevInstance, LPSTR cmdLine, int
cmdShow)
{
    auto x = new Test();
    return 0;
}


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
9/08/2006 10:22:22 AM
Aug 08 2006
parent reply Serg Kovrov <kovrov no.spam> writes:
* Derek Parnell:

 Confirmed. However this is not the way to write Windows apps. You missed
 out all the GC stuff. The code should look like this ...


Thanks for pointing that, Derek. It is silly of me that I forgot about 
that =)

But isn't it tedious to type/copy this for every new windows program one 
start to write?

And appears to me, this is some inner GC stuff that might me changed at 
some point. If so, maybe this should not be used directly by application 
programmer? I believe it is better to have compiler/standard library to 
do it instead. Just like it does for main() function.

Even better, if application programmer do always write main(), but if in 
.def there is 'SUBSYSTEM WINDOWS' string, compiler/standard library 
substitutes it with proper entry point with proper inners stuff 
initialization.

Or even better than better, is to omit .def files and have some pragmas 
in source file instead? Resulting programs could be more 
portable/deployable then...
Aug 10 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
On Thu, 10 Aug 2006 11:28:08 +0300, Serg Kovrov wrote:


 But isn't it tedious to type/copy this for every new windows program one 
 start to write?


Yes, that's why I've got that code in a module so all I have to do is ...

  import util.winstart;

Build handles the connections and .DEF file generation for me.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 10 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Serg Kovrov wrote:

 * Derek Parnell:

 Confirmed. However this is not the way to write Windows apps. You missed
 out all the GC stuff. The code should look like this ...


 
 Thanks for pointing that, Derek. It is silly of me that I forgot about 
 that =)
 
 But isn't it tedious to type/copy this for every new windows program one 
 start to write?
 
 And appears to me, this is some inner GC stuff that might me changed at 
 some point. If so, maybe this should not be used directly by application 
 programmer? I believe it is better to have compiler/standard library to 
 do it instead. Just like it does for main() function.
 
 Even better, if application programmer do always write main(), but if in 
 .def there is 'SUBSYSTEM WINDOWS' string, compiler/standard library 
 substitutes it with proper entry point with proper inners stuff 
 initialization.
 
 Or even better than better, is to omit .def files and have some pragmas 
 in source file instead? Resulting programs could be more 
 portable/deployable then...


What I did for a while was to call C main from WinMain, as that's where 
the D startup code lives.  However, someone told me that it's possible 
to have C main as the entry point for a Win app so I got rid of the 
module that I used to use.  I don't suppose anyone can confirm this or 
say how to do it?  It seems it would be far cleaner than linking against 
a WinMain module manually, even if the administrative bits are 
abstracted out.


Sean
Aug 10 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:

 Serg Kovrov wrote:

 * Derek Parnell:

 Confirmed. However this is not the way to write Windows apps. You missed
 out all the GC stuff. The code should look like this ...


 Thanks for pointing that, Derek. It is silly of me that I forgot about 
 that =)

 But isn't it tedious to type/copy this for every new windows program 
 one start to write?

 And appears to me, this is some inner GC stuff that might me changed 
 at some point. If so, maybe this should not be used directly by 
 application programmer? I believe it is better to have 
 compiler/standard library to do it instead. Just like it does for 
 main() function.

 Even better, if application programmer do always write main(), but if 
 in .def there is 'SUBSYSTEM WINDOWS' string, compiler/standard library 
 substitutes it with proper entry point with proper inners stuff 
 initialization.

 Or even better than better, is to omit .def files and have some 
 pragmas in source file instead? Resulting programs could be more 
 portable/deployable then...


 
 What I did for a while was to call C main from WinMain, as that's where 
 the D startup code lives.  However, someone told me that it's possible 
 to have C main as the entry point for a Win app so I got rid of the 
 module that I used to use.  I don't suppose anyone can confirm this or 
 say how to do it?  It seems it would be far cleaner than linking against 
 a WinMain module manually, even if the administrative bits are 
 abstracted out.
 
 
 Sean


Yes, just link a C main program with a def file with:
   EXETYPE NT
   SUBSYSTEM WINDOWS
and a program without the console window will be created. That's what 
the dbuild option "-gui" does as well. (now that I think about it, that 
option seems a bit misnamed, maybe it should be "-win"? :) )

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 11 2006