Win9x build/support of CB

[killerbot]

Facts :
 - official CB : unicode
 - Win9X : no unicode

MS solution :
 - MSLU allows Unicode programs to run on Win9x
 - tipically : only for MSVC

Open Souce Solution : http://libunicows.sourceforge.net/

--> License trouble might be happening ? ok or not ok ?

Usage
=======

1) Add the unicows import library BEFORE other win32 libraries on your command
line. For example, if your command line for Mingw32 was

    c++ foo.o bar.o -o foo -lkernel32 -luser32 -lgdi32 -lcomdlg32

change it to

    c++ foo.o bar.o -o foo -lunicows -lkernel32 -luser32 -lgdi32 -lcomdlg32

No other change is neccessary, you don't have to include any special headers in
your source files.


2) Download Unicows runtime from

    http://www.microsoft.com/downloads/release.asp?releaseid=30039
   
or
   
    http://download.microsoft.com/download/platformsdk/Redist/1.0/W9XMe/EN-US/unicows.exe
   
Extract unicows.dll from the package and distribute it with your application.
Do *not* install it to Windows system directory, always copy the DLL to your
application's directory! (Nobody wants any more of DLL hell...).
 
If your application uses Common Controls DLL (very likely) or Rich Edit control,
make sure the installer installs new enough versions that fully support Unicode
(Common Controls DLL version 5.80 and RichEdit 4.0).

Next make sure wx is ok for this libunicows :

// Set wxUSE_UNICODE_MSLU to 1 if you're compiling wxWidgets in Unicode mode
// and want to run your programs under Windows 9x and not only NT/2000/XP.
// This setting enables use of unicows.dll from MSLU (MS Layer for Unicode, see
// http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx). Note
// that you will have to modify the makefiles to include unicows.lib import
// library as the first library (see installation instructions in install.txt
// to learn how to do it when building the library or samples).
//
// If your compiler doesn't have unicows.lib, you can get a version of it at
// http://libunicows.sourceforge.net

I am not sure on how to interpret this : do I have to set this in projects using wx and/or on the command line where I issue the instructions to build the wx dll ??

Next :
 - add 1 or 2 libs to the sdk target : libshfolder.a and libshell32.a


So we need to settle this once and for all, and make these things part of the official builds.


Or not ?

Lieven

[thomas]

Personally, am not fond of yet another hack... what's wrong with building Windows98 binaries in ANSI?

[Ceniza]

For sure you'll have to compile wxWidgets with that macro set to 1 and modify the Makefile too so it'll link against that library as the first one, before issuing make.

You'll need to test if you also need to link against it in the Code::Blocks project file.

Adding or not libshell32.a could be checked quickly. Just delete codeblocks.dll from devel, add only libshfolder.a to sdk, compile sdk only (so it'll just re-link) and try in 9x.

thomas: the idea is to provide just one build that works in both 9x and NT, and that is also UNICODE.

[tiwag]

... what's wrong with building Windows98 binaries in ANSI?

nothing - it's common practice for a lot of applications nowadays

[Michael]

thomas: the idea is to provide just one build that works in both 9x and NT, and that is also UNICODE.

IMHO, there will be debug issues as C::B uses GDB 6.3.

Michael
 

[killerbot]

the project files to build ansi are gone also from svn !!
Yiannis said it is unicode now.

That's why I want to raise this in this topic, to figure out how and if ...

[tiwag]

the project files to build ansi are gone also from svn ...

it's not - just edit  WX_SUFFIX custom variable

[thomas]

Umm...? The current project is the former UNI project, so you can very well build an ANSI version with that one, it was made for that purpose...


Personally, I think (and I may be wrong of course) that people using Windows 98 are rather a minority, and they know that they are using an outdated OS, and thus they have to expect (and are expecting) some drawback when it comes to new technologies. Unicode is one such issue, and gdb 6.3 is another.
I mean seriously, you (almost) cannot buy a PC without buying XP for several years now.

My point is that to make it half-way work for a few people, we have to add yet another hack for everybody. This means increased download size, possibly reduced stability, and increased load times for everybody.
So it may be worth a consideration if you maybe just have to accept that Windows98 and Unicode don't do together (at least not easily).

[killerbot]

the project files to build ansi are gone also from svn ...

it's not - just edit  WX_SUFFIX custom variable

And probably the global var "wx" ? Since it will need to link with other libs and include another setup.h, (if so, feasible and cumbersome),  can someone acknowledge this or tell me otherwise ?
[EDIT] : is probably ok

So I see suggestion to keep providing an ansi build for the win9x product line.

[thomas]

No, just WX_SUFFIX will do (and define undefine wxUSE_UNICODE of course).

[Michael]

My point is that to make it half-way work for a few people, we have to add yet another hack for everybody. This means increased download size, possibly reduced stability, and increased load times for everybody.
So it may be worth a consideration if you maybe just have to accept that Windows98 and Unicode don't do together (at least not easily).

May be a poll could be useful to get an idea (for inaccurate it would be) of how many users are using C::B and then decide what to do next.

@killerbot: An ANSI build will still have GDB issue. And I am not sure if you can solve this (anyway I hope to be wrong .

Michael

[killerbot]

could wx project , build for ansi and unicode coexist without renaming dirs ?

- some objects files go into gcc_mswudll (unicode) and gcc_mswdll(ansi) : ok here,
and then in <wx>\lib\gcc_dll we have some files in the subdir mswu(unicode) and mws (ansi), also ok.
and some files in some lib files in <wx>\lib\gcc_dll :
libwxexpot.a
libwxjpeg.a
libwxpng.a
libwxtiff.a
libwxzlib.a
------------------
libwxmsw26u.a
libwxregexu.a
wxmsw26u_gcc_cb.dll
------------------
libwxmsw26.aµ
libwxregex.a
wxmsw26_gcc_cb.dll

So if :
libwxexpot.a
libwxjpeg.a
libwxpng.a
libwxtiff.a
libwxzlib.a
don't provide conflicts when linked from ansi CB or unicode CB, things should be fine. Who knows the answer to this one ??

Because then I am also more in favour for building ansi and unicode as seperate builds.

Lieven

[killerbot]

PS : all this to started out for fixing a bug for file associations ;-) ;-)

[thomas]

You will have to move the output folder before building the second time, but the wx libraries can very well be under the same common root. I have it that way on my system, works without any kind of problems.

[thomas]

You will have to move the output folder before building the second time, but the wx libraries can very well be under the same common root. I have it that way on my system, works without any kind of problems.

EDIT:
Of course it would be a snap to add WX_PREFIX to the output directory too, then you don't have *anything* to consider.

[killerbot]

but then we also have to adjust the CB cbp files/makefiles.
This is also part of my point, it should be possible to build both with very little changes, either you have 2 different directories where you have wx-ansi and wx-unicode, but then you need to change the cbp/make files. Or am I missing something, I feel my brain is giving up on me.

[killerbot]

I am starting to think, that both ansi and unicode builds of WX can happen in the same wx project tree without renaming them, I suspect those import libs mentioned above that don't have an extra 'u' in their name to be unicode independent (no string manipulation).

Will try to build an ansi version and see what happens, crash boom bang or shaky da hippiediehop ?

[thomas]

I can tell you what happens... it works just fine. I am doing that regularly.

[killerbot]

I can tell you what happens... it works just fine. I am doing that regularly.

hah, finally a good answer ;-)

I was just scared when I have read the wiki several weeks ago.

So for now, I will skip testing an unicode build on win98 (since I don't have it, and had to bother someone else), I will also create ansi builds and try to test the bugfix with that (well have someone do it for me ;-)  ).

Nevertheless, we should  make up our minds how we are going to officialy provide the win9x customer base ...

[duncanka]

Sigh...us poor 98 users...left in the dust, all alone with our sad, crippled machines...
Personally, I think that if C::B is really meant to be as cross-platform as possible, it only makes sense to have a build available for older versions of Windows, whether that be via libunicows or a separate ANSI build.  But then, I'm biased.

I will skip testing an unicode build on win98 (since I don't have it, and had to bother someone else), I will also create ansi builds and try to test the bugfix with that (well have someone do it for me ;-)  ).

Incidentally, Lieven and everyone else, I'm still happy to test stuff on 98, and help make sure that CB is in fact compatible with it.

[Ceniza]

I wonder if someone was interested in seeing this:



Really, this time it'sn't me playing with MS Paint (well, I cut the screenshot using it, nothing else)

Really, believe it, it's GDB 6.3 running on Windows 98, and it no longer depends on that NT-only DLL.

Anyone interested in the url?

[Edit by Rick: Fixed the broken url.]

[Ceniza]

[edit]
Rick: Thanks for fixing the link
[/edit]

Please report how it works. Those using any Windows NT (NT4/2k/XP/2k3/Vista) are free to update to that version too, I did already, but haven't tried yet.

[duncanka]

If you'ven't noticed, the link is there, but since the idea is to help, here's again: gdb.

Please report how it works. Those using any Windows NT (NT4/2k/XP/2k3/Vista) are free to update to that version too, I did already, but haven't tried yet.

:shock: :shock: It works!!! HOORAY!! (Using Win98SE)
Thank you so much for pointing this out!

[killerbot]

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 !!!


Lieven

[Ceniza]

Rick told me there's a bug when debugging with a Unicode version of Code::Blocks, so it should be ANSI in the meanwhile.

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.

After that, dunno, providing Unicode and ANSI is twice the work, twice the time. Only ANSI wouldn't be a problem, but they relly want us to convert to Unicode. And, at the end, using libunicows seems to be a hack.

[duncanka]

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 !!!

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]

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

OK   Just wondering out loud.

[thomas]

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.

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

[tiwag]

for this we have global variables - we can move the WX_SUFFIX and the wxUSE_UNICODE
for example to #CB_BOPT  (C::B build options ) and use in all contrib project files ...

[Ceniza]

thomas: what I meant was to add libshfolder.a and libshell32.a to the sdk target. It has nothing to do with libunicows.

If that's also a hack for you then don't do it, we'll do it every time we build an ANSI version of Code::Blocks that works with 9x.

[thomas]

thomas: what I meant was to add libshfolder.a and libshell32.a to the sdk target. It has nothing to do with libunicows.

Ooops, did not read properly there, as it seems
I guess we have no choice but to use these, since we use SHGetFolderPath. So if it should be able to run on Windows98 at all...