mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Brian Dessent wrote:

> B) The .exe uses LoadLibrary and GetProcAddress to load and access
> the .dll (such as in the case of a plugin that can be dynamically
> added/removed as necessary) and the .dll links directly against the
> .exe without using GetProcAddress.  This is just the converse of the
> above, except that now creating the .exe does not depend on the .dll
> existing at all.

> gcc main.o -o main.exe -Wl,--out-implib,libmain.a
> gcc -shared foo.o -o foo.dll -lmain

Are you sure this works like you describe it? The man page of "ld" says
that --out-implib only works when linking a DLL (i.e. -shared). And in
fact, the version of gcc that I have here seems to agree: --out-implib
is simply ignored when linking an executable.

-- 
Stefan Bellon

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3406365
By: infidel

Please post some code that demonstrates the problem, because there is obviously
some bug that leads you to believe that MENU_EVENT is not 9

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Luke Dunstan wrote:

>
> Is the COM DLL small enough to post the source code here? If not, 
> could you place it on a web server somewhere and post a link to this 
> mailing list?
>
> Luke
>
> ----- Original Message ----- From: "Steve Higham" <st...@sj...>
> To: <min...@li...>
> Sent: Sunday, October 30, 2005 6:30 AM
> Subject: [Mingw-users] COM Help please
>
>
>> Hi,
>>
>> I'm trying to port some Delphi COM code to C++.
>>
>> My client (exe) is working fine. It can create a Delphi COM object 
>> and destroy it.
>>
>> However my COM DLL is not working. I suspect I may be missing a 
>> required compiler flag or something similar.
>>
>> On my laptop (Windows XP Pro x64) I'm getting a "Class not 
>> registered" error. Registry details look fine to me.
>>
>> On my PC (Windows 2000 Pro) I'm getting a crash after the DLL has 
>> loaded.
>>
>> Does anyone have a working COM client that they could email me 
>> (including makefile) - preferably in C++ but C would be OK.
>>
>> Many Thanks,
>>
>> Steve
>> -- 
>>
>> Steve Higham
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
Hi Luke,

I will create a cut down version of my component and client and post 
them with a makefile.

It will probably be several days before I get this completed.

Kind Regards,

Steve

-- 

Steve Higham

› st...@sj... <mailto:st...@sj...>

Stefan Bellon wrote:

> Yes, I pretty much understand all of that. But in your example you
> assume the DLL "foo.dll" to exist. My question is: How do I _create_

There are three scenarios that I can think of.

A) The .exe links directly against the .dll, and the .dll uses
GetProcAddress to access the symbols in the .exe.  From the standpoint
of the linker this is bog standard - creating the .dll does not depend
on the .exe at all.

gcc -shared foo.o -o foo.dll -Wl,--out-implib,libfoo.dll.a
gcc main.o -o main.exe -lfoo

B) The .exe uses LoadLibrary and GetProcAddress to load and access the
.dll (such as in the case of a plugin that can be dynamically
added/removed as necessary) and the .dll links directly against the .exe
without using GetProcAddress.  This is just the converse of the above,
except that now creating the .exe does not depend on the .dll existing
at all.

gcc main.o -o main.exe -Wl,--out-implib,libmain.a
gcc -shared foo.o -o foo.dll -lmain

C) Both the .exe and the .dll link directly against each other; neither
uses GetProcAddress.  Here there is a circular dependency that you have
to break by creating a .def file by hand and then using dlltool to turn
that into an import library.  You can create the .def file for either
the .exe or the .dll - it really just depends on which has the more
complex set of exports, and how your build is structured.  Let's assume
for the example you choose to write the .exe's .def file by hand, but
you can just as well do it the opposite way.

# create main.def
dlltool --input-def main.def --output-lib libmain.a --dllname main.exe
gcc -shared foo.o -o foo.dll -lmain -Wl,--out-implib,libfoo.dll.a
gcc main.o -o main.exe -lfoo

Note that in B) and C) you hardcode the name of the .exe into the .dll,
so it can only ever be used with that .exe and not as a general purpose
library.  In all three cases you need __declspec(dllexport) on the
symbols in main.

Brian

Brian Dessent wrote:
> Stefan Bellon wrote:

> > Ok, I see. However, this doesn't work if the foo.exe itself depends
> > on the DLL. So, circular dependencies are impossible, correct?

[snip]

Thanks, this is _very_ valuable information.

> > > 2) Look up the symbol at runtime. Read up on GetProcAddress() and
> > > GetModuleHandle().
> > 
> > And how would I link the DLL itself using this second approach?

> If you use GetProcAddress then you are doing run-time (sometimes
> called dynamic) linking - the analogy to dlopen()/dlsym() on *nix. 
> This means that all calls to imported routines go through function
> pointers and there are no symbols to resolve at link-time, because
> the linker has no knowledge of what you're doing.

Yes, I pretty much understand all of that. But in your example you
assume the DLL "foo.dll" to exist. My question is: How do I _create_
this foo.dll? At present I cannot build the DLL because of undefined
references back into the main program. So, even with this second
approach originally mentioned I do have to create an import library for
the main .exe in order to build that DLL at all. Right?

-- 
Stefan Bellon

> > 1) you can create an import library for the foo.exe using a foo.def
> > file like this:
[snip]
> > Then link the DLL with libfoo.a.

>Ok, I see. However, this doesn't work if the foo.exe itself depends on
>the DLL. So, circular dependencies are impossible, correct?

I don't know.

> > 2) Look up the symbol at runtime. Read up on GetProcAddress() and
> > GetModuleHandle().
>
>And how would I link the DLL itself using this second approach?
>

Use your normal command line to generate the DLL. In the DLL, you will use 
the function pointer returned by GetProcAddress to call the functions that 
live in foo.exe.

Stefan Bellon wrote:

> > Then link the DLL with libfoo.a.
> 
> Ok, I see. However, this doesn't work if the foo.exe itself depends on
> the DLL. So, circular dependencies are impossible, correct?

Actually it's the other way around.  If the .exe does not import from
the .dll (like for example, the .dll is a plug-in of some sort and is
dynamically loaded at runtime) then you can just link the .exe normally
and use -Wl,-out-implib,libfoo.a during link to just create the import
library for the .exe without the need to create a .def file.

It's only in the case that there is a circular dependency at link-time
that you have to create the .def file.  So you create the import library
for the .exe, then you link the .dll against that import library (and
use -Wl,-out-implib to generate the import library for the .dll) and
then you link the .exe using the .dll's import library.

The key point here, as pointed out in the earlier reply, is that if you
do this the name of the .exe is hard-coded into the .dll, and so the
.dll ceases to be a general purpose library and can only ever be used
with that .exe.  This is analogous to saying that when you link an .exe
that imports from a given .dll, it hard-codes the name of that .dll into
the .exe, which will refuse to run if the .dll cannot be located.  But
that's the behavior everyone expects, not so much the reverse.

For this reason it's somewhat considered bad design on Windows to import
from the .exe in a .dll.  It will work, but it's not a very pretty
situation.  The way it's supposed to work is that you factor out
everything in the .exe that needs to be accessed from both the .exe and
from the .dll, and make that into its own .dll.  Then both the .exe and
the original .dll import from this .dll.  Or, do run-time linking
instead.

> > 2) Look up the symbol at runtime. Read up on GetProcAddress() and
> > GetModuleHandle().
> 
> And how would I link the DLL itself using this second approach?

If you use GetProcAddress then you are doing run-time (sometimes called
dynamic) linking - the analogy to dlopen()/dlsym() on *nix.  This means
that all calls to imported routines go through function pointers and
there are no symbols to resolve at link-time, because the linker has no
knowledge of what you're doing.  Example (without any error checking):

int (*funcpointer) (void);
HMODULE hm = LoadLibrary ("foo.dll");
funcpointer = GetProcAddress (hm, "some_func");
int result = funcpointer ();

In this example the linker has no idea that you are importing
some_func() from foo.dll, so there is no need for an import library or
even for foo.dll to exist.

In the case of importing from an .exe, you don't need to use
LoadLibrary() since the .exe is already loaded, and the HMODULE has to
be that of the .exe, which you get from GetModuleHandle (NULL). [I
think...]

Brian

Tor Lillqvist wrote:
> > 2) On GNU/Linux, I have one project where one shared object refers
> > back to symbols of the main application. [...] Now, when trying to
> > build the same on Windows (using gcc -shared as well), the DLL
> > doesn't even build but throws errors of "undefined references". I
> > want those to get resolved when linking against the main
> > application. Is such a set-up not possible on Windows?

> It is possible, but it is not as flexible as on ELF-based systems like
> Linux. Firstly, you must mark the function in the main .exe that you
> want to access from a DLL for export using
> __declspec(dllexport). Then, there are two possibilities how to
> actually access the functions from the DLL:

> 1) you can create an import library for the foo.exe using a foo.def
> file like this:

[snip]

>     dlltool --input-def foo.def --output-lib libfoo.a --dllname
>     foo.exe

> Then link the DLL with libfoo.a.

Ok, I see. However, this doesn't work if the foo.exe itself depends on
the DLL. So, circular dependencies are impossible, correct?

> 2) Look up the symbol at runtime. Read up on GetProcAddress() and
> GetModuleHandle().

And how would I link the DLL itself using this second approach?

-- 
Stefan Bellon

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3405187
By: random_poultry

Forgot to mention, before adding these, MENU_WINDOW was 7 and MENU_EVENT and
MENU_MAX were 8. MENU_MAX is now 9 as it should be, but MENU_EVENT refuses to
change somehow.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3405185
By: random_poultry

I've been using this for a while:
#define MENU_LINKS 		6		//Submenu of Map
		#define MLINK_TOP			0
		#define MLINK_BOTTOM		1
		#define MLINK_LEFT			2
		#define MLINK_RIGHT			3

#define MENU_ADDEVENT	7		//Submenu of Map
		#define MADD_SPRITE			0
		#define MADD_WARP			1
		#define MADD_SIGN			2
		#define MADD_TRIG			3

#define MENU_WINDOW		8
	#define MWIN_TILESEL		0
	#define MWIN_TILEARR		1
	#define MWIN_MAPINFO		2 //Map Properties
	//Separator
	#define MWIN_ABOUT			4

#define MENU_EVENT		9	//Event right-click menu
	#define MEVT_EDITSCRIPT		1 //This has to be 1, because 0 means cancel
	#define MEVT_GOTO			2 //Go To This Map
	#define MEVT_DELETE			3
#define MENU_MAX		9

It worked fine before I added MENU_ADDEVENT and MADD_*. After adding them, MENU_EVENT
is always 8, no matter what I define it as.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Is the COM DLL small enough to post the source code here? If not, could you 
place it on a web server somewhere and post a link to this mailing list?

Luke

----- Original Message ----- 
From: "Steve Higham" <st...@sj...>
To: <min...@li...>
Sent: Sunday, October 30, 2005 6:30 AM
Subject: [Mingw-users] COM Help please


> Hi,
>
> I'm trying to port some Delphi COM code to C++.
>
> My client (exe) is working fine. It can create a Delphi COM object and 
> destroy it.
>
> However my COM DLL is not working. I suspect I may be missing a required 
> compiler flag or something similar.
>
> On my laptop (Windows XP Pro x64) I'm getting a "Class not registered" 
> error. Registry details look fine to me.
>
> On my PC (Windows 2000 Pro) I'm getting a crash after the DLL has loaded.
>
> Does anyone have a working COM client that they could email me (including 
> makefile) - preferably in C++ but C would be OK.
>
> Many Thanks,
>
> Steve
> -- 
>
> Steve Higham

> 2) On GNU/Linux, I have one project where one shared object refers
> back to symbols of the main application. [...] Now, when trying to
> build the same on Windows (using gcc -shared as well), the DLL
> doesn't even build but throws errors of "undefined references". I
> want those to get resolved when linking against the main
> application. Is such a set-up not possible on Windows?

It is possible, but it is not as flexible as on ELF-based systems like
Linux. Firstly, you must mark the function in the main .exe that you
want to access from a DLL for export using
__declspec(dllexport). Then, there are two possibilities how to
actually access the functions from the DLL:

1) you can create an import library for the foo.exe using a foo.def
file like this:

EXPORTS
	some_function_in_main

and dlltool: 

    dlltool --input-def foo.def --output-lib libfoo.a --dllname foo.exe

Then link the DLL with libfoo.a.

This has the disadvantage that the .exe really has to be called
*exactly* foo.exe. This might be a disadvantage.

2) Look up the symbol at runtime. Read up on GetProcAddress() and
GetModuleHandle().

--tml

Hay,
Can I get a copy of this? I have been having problems, but I think thats
just my programming skills. lol
Later,
Tyler Littlefield.
Check out our website:
http://tysplace.the-leetest.net
check out my blog:
livejournal.com/~tylerrl
[my programs don't have bugs, just randomly added features]

----- Original Message -----
From: "Steve Higham" <st...@sj...>
To: <min...@li...>
Sent: Saturday, October 29, 2005 3:30 PM
Subject: [Mingw-users] COM Help please


> Hi,
>
> I'm trying to port some Delphi COM code to C++.
>
> My client (exe) is working fine. It can create a Delphi COM object and
> destroy it.
>
> However my COM DLL is not working. I suspect I may be missing a required
> compiler flag or something similar.
>
> On my laptop (Windows XP Pro x64) I'm getting a "Class not registered"
> error. Registry details look fine to me.
>
> On my PC (Windows 2000 Pro) I'm getting a crash after the DLL has loaded.
>
> Does anyone have a working COM client that they could email me
> (including makefile) - preferably in C++ but C would be OK.
>
> Many Thanks,
>
> Steve
> --
>
> Steve Higham
>
> › st...@sj... <mailto:st...@sj...>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users

Hi,

I'm trying to port some Delphi COM code to C++.

My client (exe) is working fine. It can create a Delphi COM object and 
destroy it.

However my COM DLL is not working. I suspect I may be missing a required 
compiler flag or something similar.

On my laptop (Windows XP Pro x64) I'm getting a "Class not registered" 
error. Registry details look fine to me.

On my PC (Windows 2000 Pro) I'm getting a crash after the DLL has loaded.

Does anyone have a working COM client that they could email me 
(including makefile) - preferably in C++ but C would be OK.

Many Thanks,

Steve
-- 

Steve Higham

› st...@sj... <mailto:st...@sj...>

On 2005-10-26 13:57 UTC, Foster, Gareth wrote:
> 
> I am wondering about these values, they tell you things about memory in for
> program in win32/vc++ programs.
> 
> 0xcdcdcdcd
> 0xcccccccc
> 
> Are these values also to be found in mingw/gcc/cygwin/linux environments?

Not to my knowledge. But you can find libraries that do similar
things (and much more), for example:

 - mpatrol's ALLOCBYTE, FREEBYTE, and OFLOWBYTE options

 - mudflap (not sure anyone's made that work with MinGW yet)

 - valgrind if you're using GNU/Linux

Hi list !

To those of you running a MinGW xcompiler unerder GNU/Linux and
who are trying to use the newly released mingw-runtime-3.9:
Beware the files in the tarball all have DOS-lineendings.

This may result in your buildscripts failing.

The simple solution is to apply dos2unix to all executable
files in the tarball (but beware that dos2unix removes the
execution bit...).

I've been trying to update the script in the wiki to contain a fix
but I can't get it saved -- will be trying again later.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@te...
 GPG-keys available on request or at public keyserver

> 1) If I have global variables in a DLL (ie. the DLL is not stateless)
>    and several applications make use of the DLL simultaneously, do they
>    operate on the same data or has each application an own instance of
>    the DLL's global data? I hope the latter is the case.

Each application has it's own local copy. You have to use shared
memory if you wish to share data among applications (or whatever
other means you prefer).

> 2) On GNU/Linux, I have one project where one shared object refers back
>    to symbols of the main application. When linking that .so file with
>    gcc -shared, that's no problem. When linking the main application,
>    the library is given on the command line with the -L/-l switches and
>    linking works. The undefined references from the .so are resolved
>    using the main application.
>=20
>    Now, when trying to build the same on Windows (using gcc -shared as
>    well), the DLL doesn't even build but throws errors of "undefined
>    references". I want those to get resolved when linking against the
>    main application. Is such a set-up not possible on Windows?

It is possible.

I no longer remember the details but earlier this year there had
been a discussion on dynamic linking which also dealt with this
very problem (and presented a solution).

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@te...
 GPG-keys available on request or at public keyserver

Coming from the GNU/Linux side and now having to port my application
across to Windows, I have two fundamental questions in understanding
DLLs opposed to shared objects (.so) under GNU/Linux.

1) If I have global variables in a DLL (ie. the DLL is not stateless)
   and several applications make use of the DLL simultaneously, do they
   operate on the same data or has each application an own instance of
   the DLL's global data? I hope the latter is the case.

2) On GNU/Linux, I have one project where one shared object refers back
   to symbols of the main application. When linking that .so file with
   gcc -shared, that's no problem. When linking the main application,
   the library is given on the command line with the -L/-l switches and
   linking works. The undefined references from the .so are resolved
   using the main application.

   Now, when trying to build the same on Windows (using gcc -shared as
   well), the DLL doesn't even build but throws errors of "undefined
   references". I want those to get resolved when linking against the
   main application. Is such a set-up not possible on Windows? Can't
   symbols in a DLL refer back to the main application? (And yes, I
   know that I can have a register function and let the DLL know the
   functions of the main applications via callbacks, but that's not
   what I want.)

-- 
Stefan Bellon

Thank you very much for your advise.
It worked.
And it's clear now.

Manvel Avetisian wrote:

> 'tag' constant is declared this way:
> class Spatial::Hull {
> ...
> private:
>         static const u32 tag = 0x06060606;
> ...
> };
> 
> So I'm wondering what can cause such errors, because there are several
> other
> constants from other classes that are declared in such way, but that
> constants
> are linked perfectly.

The error is a missing Spatial::Shape::tag but you're defining
Spatial::Hull::tag.  Is the latter derived from the former?

Assuming that's not the problem, it looks like you've only declared
these static data members, but not defined them.  You need something
like "const u32 Spatial::Hull::tag;" in one (and only one) .cpp file.

Now it's true that "static const int" is a special case that is treated
like a #define if you initialize it in the class, and the variable isn't
actually instantiated -- so the definition shouldn't be necessary. 
However, the fact that the linker is trying to find this symbol implies
that 'tag' was used in a way such that the compiler was not able to
simply substitute 0x06060606.  For example, if you inadvertently used
Spatial::Hull::tag in an expression that required an address (e.g.
"&tag"), then gcc would have to actually instantiate a variable for the
constant, and so the "one definition rule" becomes relevent again. 
Since it seems to only be happening with this one symbol, then such an
inadvertant expression could very well be what happened.

> Another strange thing is that if I change order in which my local libraries
> are listed, then I get some very strange errors:

That is expected behavior.  The order that you specify link objects
matters.  If object A references a symbol in object B then object A has
to come before B in the order.  This generally means that -lfoo must be
specified after any bar.o that uses some symbol in -lfoo.

Brian

Hi,

My project consists of several libraries and one executable. I'm compiling  
them separately
and linking together using:

g++.exe  -L"C:/Program Files/Microsoft DirectX 9.0 SDK (April  
2005)/Lib/x86" -L"
C:/Program Files/msys/lib" -mwindows ./build/debug/A1/main.o
./build/debug/A1/PlaneActor.o ./build/debug/A1/PlanePlayer.o
./lib/libuniverse_d.a ./lib/libphysics_d.a ./lib/libspatial_d.a  
./lib/libinput_d.a
./lib/libgraphics_d.a ./lib/libmath_d.a ./lib/libmeta_d.a  
./lib/libsystem_d.a -l gdi32
-l d3d9 -l d3dx9d_25 -l dinput8 -l dxguid -l dxerr9 -o bin/A1_d.exe

And I get following error:
./lib/libspatial_d.a(Shape.o): In function `ZNK7Spatial5Shape5WriteEPSo':
C:/home/engine/./src/spatial/Shape.c:123: undefined reference to  
`Spatial::Shape
::tag'
collect2: ld returned 1 exit status
make: *** [bin/A1_d.exe] Error 1


'tag' constant is declared this way:
class Spatial::Hull {
...
private:
	static const u32 tag = 0x06060606;
...
};

So I'm wondering what can cause such errors, because there are several  
other
constants from other classes that are declared in such way, but that  
constants
are linked perfectly.

Another strange thing is that if I change order in which my local libraries
are listed, then I get some very strange errors:
./lib/libuniverse_d.a(Machine.o): In function  
`ZN8Universe7Machine4LoadEPKc':
C:/home/engine/./src/universe/Machine.c:235: undefined reference to  
`Spatial::Sh
ape::Construct(meta::ptr<Graphics::Mesh, meta::refcounted_pylon>)'
C:/home/engine/./src/universe/Machine.c:238: undefined reference to  
`Spatial::Sh
ape::Read(char const*)'
C:/home/engine/./src/universe/Machine.c:242: undefined reference to  
`Spatial::Sh
ape::Construct(meta::ptr<Graphics::Mesh, meta::refcounted_pylon>)'
C:/home/engine/./src/universe/Machine.c:243: undefined reference to  
`Spatial::Sh
ape::Write(char const*) const'
collect2: ld returned 1 exit status
make: *** [bin/A1_d.exe] Error 1

Can anyone help me please?

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3403669
By: poochner

You can use an extraordinary text editor, such as emacs :-)  There's a reason
its icon is an overflowing kitchen sink.  Until I starting doing almost all
Java and little C and Fortran, I used emacs exclusively as my ide (and mail
reader, etc.).

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3403432
By: branot

Any hints for a good IDE for the project with mixed C and Fortran code, dominated
mainly by Fortran part.
I'm currently using ordinary text editor with hightlighting for both C and Fortran
files, which works fine, but it would be nice to have something more versatile
in the future. Any suggestions?

Thanks, Brano

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Gareth Foster wrote, quoting me:
>> Shame you didn't choose a tool kit which would allow you to
>> `Open Source' it.
>
> That is what I was thinking, a little more constructive, shame you
> didn't use GTKmm, then maybe there could have been an option in the
> official installer for mingw, msys and an 'official' ide. Could have
> been an interesting combination.

Hmm.  If there is to be an "official" IDE for MinGW, shouldn't we
rather promote Visual-MinGW -- a project which lists our own Earnie as
an administrator?  Sadly, there doesn't seem to be much evidence of
continued development in that area, though, since an 0.56-alpha in
March 2004.

Regards,
Keith.

> Shame you didn't choose a tool kit which would allow you to
> `Open Source' it.
> 

That is what I was thinking, a little more constructive, shame you didn't
use GTKmm, then maybe there could have been an option in the official
installer for mingw, msys and an 'official' ide. Could have been an
interesting combination.

Gaz