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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]