Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Win9x build/support of CB

<< < (6/7) > >>

duncanka:

--- Quote from: killerbot on January 05, 2006, 07:17:23 am ---so what's left to decide is (since GDB no issue ):

1) CB as seperate ansi, or CB as libunicows (or no CB for win9x)
2) as much support as possible for it in the cbp/make files, so very little needs to be changed by hand if you want to build them both !!!

--- End quote ---

I'm not familiar with MSLU and whatnot, but if it would be a pain to maintain the framework for an ANSI version, might it be easier to provide a non-Unicode build that just uses unicows?  In other words, still a second build, but without most of the project/makefile adjustments (though it would still be more compile time, certainly).

Ceniza:
Well, if the choices are "Unicode + ANSI" and "Unicode + libunicows", I vote "Unicode + ANSI".

duncanka:

--- Quote from: Ceniza on January 05, 2006, 07:49:31 am ---Well, if the choices are "Unicode + ANSI" and "Unicode + libunicows", I vote "Unicode + ANSI".

--- End quote ---
OK :)  Just wondering out loud.

thomas:

--- Quote from: Ceniza on January 05, 2006, 07:39:31 am ---Someone with access to the project files in SVN should add those libraries to target SDK. Those won't hurt the current Unicode build but will help 9x builds.
--- End quote ---
That is not so certain. Adding the libraries to the project already means applying the hack.

I am very much against using this stuff. It tampers during startup and you don't really know what happens (ok, you do know what generally happens, but you know what I mean). This does not necessarily add to stability. Also, the documentation states that it requires a certain link order (before any other MS libraries), so I am not sure if it is possible to simply add it to the sdk target at all. Since wxWidgets links with MS libraries, you very likely have no other choice than to build wxWidgets with it.

It loads shared libraries at runtime which might otherwise have been subject to prefetching. I don't know if prefetching makes a big difference, but you'd think that they don't build such a feature if it isn't good for anything. True enough, Code::Blocks loads its plugins at runtime too, but in this case, we cannot avoid it.

Lastly, we need a proprietary MS dll in addition which has licensing terms that are very obviously not GPL compatible and has many other issues which are no trifles.
I am not even certain if redistributing the unicows runtime is legal for us at all (not under the conditions which apply for us).
I know that I am being pedantic here, but it is not me who writes perverse licenses...

killerbot:
@Thomas, very good arguments, but even if we want to have a seperate ansi build, 2 more libs need to be added, and probably these can always be added (even for unicode build), it's shfolder (and maybe the shell ) lib. So that does not even have to do with unicows.

One thing can (all cbp files) be made geenral enough so you can build an ansi and an unicode with it, and not having conflicts where they put their obj's and deliverables ? Same might apply to the normal build, and maybe optimized builds ? Because now no opt ?, debug info which gets stripped off in the update process.

Lieven

Navigation

[0] Message Index

[#] Next page

[*] Previous page