Port QApplication

[Dmitry A. Kuminov]

Provide the OS/2 version of the QApplication class.

[Dmitry A. Kuminov]

Aha, in order to build the QtGui? module we need uic. Will try to build it... OK, it builds and seems to work, good.

[Dmitry A. Kuminov]

Unsurprisingly, QApplication and QWidget have huge dependencies on other platform-specific parts such as QPaintDevice and QFontEngine.

As opposed to the strategy used when porting Qt3 where I commented out in dependants to temporarily break such dependencies (until the relevant components are ready), I will now provide dummy implementations of all components to make the QtGui? DLL build and be able to test stuff on practice.

Afterwards, I will continue to work on individual parts as usual.

[Dmitry A. Kuminov]

In r, I added OS/2 stubs for platform-specific parts of all key GUI classes. (and disabled non-key classes with QT_NO_ defines).

The QtGui4 DLL can be compiled now, however the link stage fails at the very last step with the following message:

ILink : fatal error LNK1041: resident-name table overflow 

According to the Visual Age C++ documentation (kindly maintaned online at warpspeed, ​http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..\html\book\IBMVACPP\CPPUG.INF+3797), this has the following meaning:

LNK1041 resident-name table overflow

Explanation: The total length of all your resident-names, together with an overhead of 3 bytes for each name, is greater than the ILINK limit. The internal ILINK limit is 65,534 for ILINK versions prior to 2.01.012 and is 1,048,576 for ILINK version 2.01.012 and later versions.

Action: Reduce the number or the length of your resident names.

I suspect that this is due to heavy template usage (especially in the debug build with no optimization, where all known template instantiations are real functions).

I will think on what options we have. One of them is simply split the QtGui? DLL to two DLLs. Not nice, but it may turn out to be the only solution.

[Dmitry A. Kuminov]

Ok, the release version of QtGui? DLL builds fine which confirms my suggestion.

But we absolutely need the debug build too. I will have to change the .pro files (and probably the GNUMAKE qmake backend) to support splitting the target DLL into two (or more).

[Silvan Scherrer]

what about using wlink. with QT3 we also used wlink afair. i use wlink for all my gcc programms (samba included), as it seems more stable.

[Dmitry A. Kuminov]

No, we "oficially" used the same special ILINK 4 build (from the Mozilla team afair) with Qt3 as well -- "normal" ILINK 3 crashed when there were many exports. Though I can try wlink of course, but it may turn out to be a system limitation. And I recall there were problems with the debug info generated by wlink; I don't remember if Knut fixed them or not.

[Dmitry A. Kuminov]

Pity, I can't find the Qt3-wlink build I did back then nor the Knut's wlink itself. ​ftp://ftp.netlabs.org/pub/gcc/wl-hll-r1.zip must be it.

[Silvan Scherrer]

thats exactly the wlink i use. afaik this patch is also included in the watcom compiler > 1.6x

[Dmitry A. Kuminov]

OK, I apparently mixed the bits up, but things are clear now. First, I've been actually using ILINK 3.08 (e.g. from the VAC 3.08 package), not ILINK 4 or whatever.

Second, the one I was referring to as ILINK 4 is actually ILINK 5. I tried it and it doesn't have such a limitation on the resident table size as ILINK 3.08 has (at least it doesn't report any error). But it has some other serious problem: this giant QtGui4 DLL it builds (60 something megs) cannot be processed by the OS/2 loader when starting the application that imports from this DLL, it bails with some error "program cannot be started" or such during startup. The debugger shows that it happens somewhere in the system DLL before calling main(). I recall something similar with the Qt3 DLL and it explains why this ILINK 5 is NOT used with Qt3 by default.

Third, I've tried WLINK from the link above and it works. It means that it can successfully build the DEBUG QtGui4 DLL and this DLL seems to work well and even HLL debug info seems to present so that it is accessible under the debugger. Good.

There are two problems with WLINK though. First, It doesn't seem to do any packing so that EXEs and DLLs it builds are 40% bigger than ones by ILINK 3.08 (and 50% bigger than by ILINK 5). Not a problem per se since LXLITE can pack everything very well (on a separate pass). The second problem is more significant: WLINK is about two times slower than its ILINK counterparts... I don't think that there is a simple way to speed it up.

Anyway, I'll switch to WLINK and see if I can live with this slowness (after all, it's only the DEBUG version of QtGui4.dll that makes problems for ILINK 3.08 so far) -- if I get tired of that I'll provide a QMAKE variable to switch the linker (between ILINK and WLINK) on the target-specific basis.

[Dmitry A. Kuminov]

WLINK is terribly slow: building the debug version of the QtGui? DLL takes about 1 min 30 sec. Another problem with WLINK is that the debug info is still not complete: you cannot access expressions (e.g. see what is the value of the given variable) in the debug session.

For these two reasons, I will split the debug version of QtGui? to two DLLs.

[Dmitry A. Kuminov]

...And switch back to ILINK 3.08.

[Dmitry A. Kuminov]

Neither ILINK 3.08, nor 5.0 work in split mode (~30 MB each of the DLL), what a crap! WLINK still works in split mode.

[Dmitry A. Kuminov]

Splitting into three DLLs also doesn't work :( ILINK 3.0 spits this

General Protection Fault exception occurred at EIP = 1D9CABD2 on thread 0001.

Exception occurred in C Library routine called from EIP = 00013EB1.

Register Dump at point of exception:

EAX = 000D0000    EBX = 00000003  ECX = 00000200    EDX = 006454EC

EBP = 000949EC    EDI = 00645540  ESI = 000719A4    ESP = 000949A0

ÿCS =     005B  CSLIM = FFFFFFFF   DS =     0053  DSLIM = FFFFFFFF

ÿES =     0053  ESLIM = FFFFFFFF   FS =     150B  FSLIM = 00000030

ÿGS =     0000  GSLIM = 00000000   SS =     0053  SSLIM = FFFFFFFF

But I want to have the debug info...

[Dmitry A. Kuminov]

Just for the record. We will have to stick with WLINK (= incomplete debug info, call symbols only w/o variables etc) since I didn't find a way to build a usable debug version of QtGui? with either of the ILINK versions: the application linked to the DLLs they generate always spits with SYS2070 to POPUPLOG.OS2 which refers to the QtGui? DLL (SYS0193). SYS0193 means that the DLL is corrupt and cannot be properly loaded by the OS/2 loader for some reason.

I suspect that the reason is that extended debug information that normally allows to watch variables and structure members is broken in these DLLs (probably some internal ILINK limits are unexpectedly exceeded and it generates a corrupt DLL).

Though, I still decided to split the debug version of the QtGui? DLL into several DLLs (three, to be exact) -- to reduce the time it takes for WLINK takes to link after the source change.

[Dmitry A. Kuminov]

Other than that, the progress is going on: I can now create simple widgets (with empty contents yet and no font support). So the primary tasks for the beta are getting initial versions of the painting and font engines to work.

[Dmitry A. Kuminov]

This task is basically done. There is a number of @todo still in the code, but these will be done as individual tasks later.