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.