Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

[Kean Johnston <kean johnston gmail com>]

> AFAIK, VC can use gccs .a files directly, but the other way around isn't
> possible (since the .lib files don't contain something that gcc/ld needs).
Thanks for teh data point, I will certainly look into this.

> As for Windows programmers preferring VS, this may be true, but is it also
> true when taking in account developers that are likely to use GTK+? Also,
A fair point, and the truth is I don't have evidence to back up my opinion, 
but I have my own experience to go by. I personally started trying to get 
GTK to work exactly becuase I did NOT want to use the GNU toolchain. I use 
that all day every day in my day job and wanted something different to 
expand my skill set, and therefore wanted to get more familiar with MSVC. 
However, I think the real answer depends entirely on the target audience. 
If you are targeting UNIX developers who want to make a Windows port of the 
app, I'd say they will be using MinGW because its the most familiar 
environment. However, if you are targeting Windows developers and trying to 
make it more attractive for them to use GTK for their UI so they have one 
less hurdle to jump over in porting their app to UNIX, then I'd say they'll 
be using MSVC. I think the second audience is far larger, and far more 
important to target.

> does it even make sense to use the DDK compiler then, given that most VS
> users won't, which'll introduce CRT problems again?
Actually, using the DDK is a win even for users using MSVC. Remember the 
DDK will only be used to compile GTK itself, not the user's app. Even if 
they are using MSVC 2010 (and thus msvcrt100.dll) there is still very 
little of the CRT madness they have to contend with. Since they should be 
using things like g_malloc() and g_free() etc, and all of the stuff in the 
GTK chain uses the same CRT, they're in reasonably good shape. The only 
thing they can't do is use malloc() and then pass that pointer to g_free(). 
Which they shouldn't be doing anyway. The advantage that using the DDK 
gives you is that by targeting GTK and all related DLL's against 
msvcrt.dll, that's one less thing they have to worry about shipping DLL's 
for. Maybe they have to ship the MSVC CRT for their own apps purposes but 
not because of anything that GTK introduced. Its therefore the "lightest 
touch" approach.

> So, instead of every program packing it's private copy of GTK+ stack, you
> instead propose the common GTK+ stack to include every micro-version of the
No I wasn't proposing it at all, I was just saying what was POSSIBLE as a 
means of combating the question posed. What i *ACTUALLY* propose is an 
easily installable set of DLL's that register themselves properly and will 
not let an older version overwrite a newer one, and rely on backwards 
compatibility among the minor releases. Thus, I do propose the library be 
named libglib-2.0.dll *as long as* the installation mechanism ensures that 
an installation of 2.26.x cant overwrite an installation of 2.28.x.

Kean