Win9x build/support of CB

[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