[Gelöst] - Qt44 unter Win98 mit VC60 installieren

[mabralume]

Hallo erstmal. Bin jetzt hier zwar schon einige Zeit Mitglied, habe aber bisher noch nichts zum besten gegeben - Also ich arbeite bei einer IT-Firma in Siegen (siehe Profil) und entwickle seit ca 4 Jahren mit Qt. Hab da auch so einige "Höhen und Tiefen" mit der Bibliothek durch - kann aber im Vergleich zur Konkurrenz (MFC,Kylix,wxWidgets usw.) sagen das dies die beste grafische Bibliothek ist um professionelle Anwendungen/Oberflächen unter Windows,Unix etc. zu entwickeln (naja, ein bischen schleimen ) -

Ok, nun hab ich aber ein paar Probleme. Da QT ja PLATTFORMUNABHÄNGIG ist, entwickle ich auch noch unter Win98 (manche Betriebe die wir beliefern haben sogar nur ao alte Laptops damit) mit VC6.0 - bei der Installation traten folgende Probleme auf :

(Habe die Installation über die zwei verschiedenen Modi durchgeführt, zum ersten die Verwendung der .exe und dann das Übersetzen der Sources lokal unter Windows.)

A - Installation der Bin-Version (.exe)
* im neuen Assistenten lassen sich die .qch - Dateien nicht laden ( FEHLERMELDUNG : "Dies ist keine gültige qt-Hilfedatei" ), der alte Assistent funzt aber
* der Designer will ständig zwischenspeichern, kann es aber aus unerfindlichen Gründen nicht (FEHLERMELDUNG : "... Datei konnte nicht geschrieben werden") , wo kann man den Unsinn abschalten ??
* wenn man den Designer beendet, gibt es ein Segmentation Fault, ebenso beim neuen Assistenten
* sämtliche plugins (imageplugin z.B.) funktionieren wieder nicht, ich verwende GifAnimationen um Kopiervorgänge darzustellen, dazu die QMovie - Klasse. Animationen
werden aber nicht angezeigt (wurde der Pfad wieder geändert ??)

B - Installation über Neukompilierung der Sources
* größtes Hindernis ist die Unfähigkeit der command.com verkettete Befehle abzuarbeiten, ein "cd /verzeichnis && make" schlägt fehl wegen dem && Operator. Die generierten Makefiles sind also nur bedingt Plattformunabhängig - Abhilfe schafft eine andere Shell, z.B. "4Dos"
* Obwohl QTDIR auf das Qt-Installationsverzeichnis gesetzt ist, wird als QMAKESPEC der Bin-Pfad genommen ! z.B. "QTDIR = c:\compiler\qt" und "QMAKESPEC=win32-msvc" dann wird der Pfad in den generierten Makefiles auf "c:\compiler\qt\bin\mkspecs\win32-msvc" gesetzt - Warum ???
* über den Lizenzmechanismus wird eine qconfig.h mit den Lizenzangaben erzeugt, eingebunden wird aber eine qconfig.cpp
* die Namen der erzeugten LICENSEE-Bezeichnungen stimmen mit den generierten Namen in der qtconfig.h nicht überein
* dann gab es noch eine Fehlermeldung bei der Erzeugung der .moc für die Klasse QBuffer, in der .moc-Datei wurde auf die Klasse QBufferPrivate auf die Funktion _q_emitSignals zugegriffen, OHNE das QBufferPrivate definiert war ...

Hat hier jmnd. ähnl. Probleme bei der Installation gehabt ? Also ich bin auf Qt44 gewechselt, weil dort das WebKit drin ist. Oder gibt es ne Möglichkeit das WbKit separat zu bauen und dann zu verwenden, da Qt435 bei mir eigentlich schon gut funktioniert hatte ...

Vielen Dank schon mal im vorraus

mfg
MB

[Christian81]

Ich würde mal sagen - Pech gehabt
http://trolltech.com/developer/resource ... _platforms

Win98 wird noch unterstützt, aber schon lange nicht mehr als Build-Platform. Mit 4.5 wird es definitiv nicht mehr unterstützt - d.h. es werden keine Fehler dafür mehr akzeptiert. Mit MSVC6 ist es genauso (glücklicherweise).

Also unter w2k/xp/vista kompilieren und unter w98 testen.

[mabralume]

Uff - da war ich wohl nicht mehr auf dem Laufenden - was die Plattformunterstützung angeht ... **schulterzuck**

Ok, das erklärt die Fehler beim Assistenten ... Warum nun aber falsche Pfade und Lizenznamen erzeugt werden ... ??? Weiß der Geier.

Werd also dann auf 434 unter Win98 stehenbleiben Nuja, kann man nicht ändern. Kann ja auf FreeBSD mit GCC ausweichen . Der MinGW funktioniert nicht unter 1GB Arbeitspeicher, das hab ich schon probiert, außerdem ist der GDB gegenüber dem integrierten Windowsdebugger der VS-Reihe deutlich unterlegen (mMn) ...

Also unter w2k/xp/vista kompilieren und unter w98 testen.

... das kannste getrost vergessen. Das scheitert an den Systemdll's der jeweiligen Windowsversion. WinXP und 2000 sind Kompatibel. Unter Win2000 übersetzete Programme laufen aber nicht mehr unter 98 und drunter. Unter 98 kompilierte Progs funzen überall - Außer Vista, das hab ich noch nicht getestet und werds mir (hoffentlich) ersparen.

Vielen Dank für die schnelle Hilfe

mfg
MB

edit:
Nur falls Ihr Euch fragt, warum so alte Systeme ... Also wie gesagt, die Betriebe besitzen meistens ältere Laptops, weil die noch mit entsprechenden Schnittstellen (seriell, parallel) ausgestattet sind (haben neuere vrmtl. auch, aber das ist eine Kostenfrage die sich manche Betriebe eben nicht stellen wollen). Die haben gegenüber den zugekauften (USB auf Seriell, Paralleladapter etc.) den Vorteil, daß sie halt im industriellen Bereich zu allem kompatibel sind und immer funktionieren. - Nur mal so am Rande ...

[Christian81]

Ein unter w2k kompiliertes Programm läuft auch unter w98 wenn man die richtige WINVER benutzt denke ich.

[mabralume]

Ähm, nein ...

mfg
MB

edit:
Also ich sprech jetzt von lokal übersetztem qt. Damit funktioniert es definitiv nicht. In den qt-Grundbibliotheken ist ja dann das jeweilig Windowssystem reinkompiliert . Vlcht. würde es bei einer binären Installation gehen. Da früher aber bei dem binären qt einige wichtige Biblitheken und Plugins weggelassen wurden (vrmtl. Lizenzrechtliche Gründe - gif) war ich gezwungen es immer lokal zu übersetzen. Hab aber nun gesehen, daß bei 434 z.B. die imageplugins komplett im Binärpaket vorhanden waren ... Hmmm, ok, könntest vrmtl. doch recht haben - das muß ich erstmal eroieren -

Ist aber alles irrelevant, werde für die alten Betriebe nun eine extra Version machen und mit dem Webkit unter FreeBSD entwickeln. Muß halt eben doch verschiedene Versionen installieren ..

Also Qt44 unter Win98 mit VC60 geht NICHT - siehe obigen geposteten Link !

Bis denne
mfg
MB

[Christian81]

In den qt-Grundbibliotheken ist ja dann das jeweilig Windowssystem reinkompiliert

Da ist nichts reinkompiliert - vor jeden WinAPI-Aufruf gibts ne schöne Ansi und Unicode-Version (siehe Code), also geht ein unter w2k kompiliertes Qt auch unter w9x

[mabralume]

Hmmm, wenn ich mein unter Win2k übersetztes Programm versuche unter Win98 zu starten, kommt z.B. die Fehlermeldung das der Prozedureinsprungspung xy in der z.B. User32.dll nicht gefunden werden konnte ...

Hör mal, Du kannst es mir ruhig glauben, mach doch selber mal den Versuch und erstelle z.B. unter win2k deine qt-Bibliothek (z.B. eben 434). Dann schreibst Du Dein Programm, machst da nen Dialog, ein paar Qmessages und einen Fileauswahldialog. Jetzt nimmst Du das Programm mit all seinen Abhängigkeiten (VisualStudio dll's msvcrt,qtcore/gui usw.) und packst das auf einen Win98 SE - Rechner. Und siehe da es geht eben nicht. Is ja auch logisch. Also, Du hast mir doch mit Deinem Link schon geholfen, las gut sein

mfg
MB

Wart mal, ich glaub wir reden aneinander vorbei. Ich beziehe mich auf mein fertiges Programm, nicht auf die Bibliothek. Wenn ich mein Programm auf einem 2000er System übersetze wo ich auch die Bibliotheken übersetzt habe dann ist das Programm so mit den Bibliotheken NICHT auf 98 portierbar. Wenn ich das Programm nun aber als Code nehme und auf einem 98'er System mit rüberkopierten Qt-Bibliotheken nochmal neu übersetze, daß soll dann gehen ??? Das hab ich noch nicht probiert .

Hier schau Dir mal die Abhängigkeiten der Core Bib an :



... allein die Kernel32.dll ist ja nun nicht einfach so portierbar - newahr

[myme]

Christian hat ja schon mal WINVER erwähnt, hier näheres dazu:
http://msdn.microsoft.com/en-us/library/6sehtctf.aspx

[mabralume]

Jepp, bedingte Compilierung, na und, aber was soll mir das helfen ? Wenn ich meine Anwendung unter 2000 übersetze, dann läuft die trotzdem nicht unter 98. Ich muß die ANWENDUNG unter 98 NEU übersetzen.

Ein unter w2k kompiliertes Programm läuft auch unter w98 wenn man die richtige WINVER benutzt denke ich.

... wenn mit Programm die Qt-Bibliothek gemeint ist, kann ja sein, hab ich noch nicht ausprobiert. Aber für das Endprogramm gilt das nicht. Ich kann hier an meinen WinVer sonstwas rumdrehen wie ich will, aber die Application, sofern unter 2000 übersetzt läuft definitiv nicht unter 98. Probierts doch selber mal aus. Kann ja auch gar nicht, ist doch von den Funktionen der User Kernel und GDi nicht möglich. Dann müßt ich die user, gdi oder kernel von 2000 kopieren

Die Bibo haben wir doch auch durch, unter 98 hab ich nur den VC6 Compiler, da wird das WebKit nit laufen also lass ich das. Für den Hinweis auf die unterstützen Plattformen hab ich mich doch schon bedankt.

p.s.:
Dieses Winver "bescheißt" nur die Überprüfung des Programms beim ersten Prozeßerzeugen, mehr nicht. Wenn man z.B. die SOCKET2.0 Klasse von 2000 benutzt, dann guckt man unter 98 in die Röhre oder nem blauen bildschirm oder sonstwas. Habt Ihr auch mal gelesen, für was fürn Compiler das gilt ? Also nochmal, wenn ich ne Application unter 2000 schreibe, dort übersetze dann läuft die NICHT unter 98. Sie ist allenfalls Startbar , wenn man WINVER ändert, das wars aber auch schon !!

Also 98 ist ja eben auch nur ein DosAufsatz. Alle Operationen, gerade was auch den Speicher betrifft oder die angeschlossenen Geräte, das geht auf den Doskernel (der letzte war glaub ich 7.0 ) zurück. Die Verwaltung unter 2000 ist nunmal anders. Bestes Beispiel die FAT und NTFS.
Also, wenn ich WINVER ändere, dann kann ich Programme unter 2000 schreiben, die auch unter 98 laufen, weil ich die Versionsüberprüfung bei Programmstart behumse. Und wißt Ihr was, das wußte ich schon vorher und war eigentlich auch hier nicht die Frage. Das Problem ist dabei, daß das Programm was man schreibt allenfalls für ein paar klicks auf bunte Bildchen gut ist und wenn es zur Sache geht, wird es sich zu 98% verabschieden . Mein damals unter 2000 geschriebenes Programm hatte sich noch anständig mit eben jener obigen erwähnten Fehlermeldung "... konnte Prozedureinsprungspunkt xy in der User32.dll nicht finden ..." verabschiedet. Es war damals eben auch startbar aber man konnte mit dem Programm halt nichts machen. Also für mich ist STARTBAR nicht gleich LAUFFÄHIG. Diese Aussage ist wie "Mein Programm ließ sich übersetzen, also läufts auch" (so ganz ohne Test )

Ich denk mal wir können die Sache hier abhaken und ich werd mich dann mal verabschieden ...

mfg
MB