Frage zu C Defines in iowkit.h

[methusalem]

Moin zusammen,

ich hab mal ne Frage zu den ganzen Datentypen in der Headerdatei.

Hier tauchen ja haufenweise Datentypen auf, die meiner Meinung nach alles Defines sein müssten. So z.B. DWORD, BYTE, PWCHAR, BOOLEAN usw.

Mir ist eigentlich schon klar, was hinter den einzelnen Datentypen steckt. Mir ist nur nicht klar, wo diese definiert sind. Es scheint so, als wenn diese Defines unter Windows über window.h in die Sourcen kommen.

Wie ihr merkt, bin ich in C nicht ganz so sattelfest. Daher würde ich mich freuen, wenn mir jemand auf die Sprünge hilft.

[wayoda]

Diese Datentypen gibt es zwar unter Windows, aber z.B. nicht unter Linux. Daher sind auch die typedefs im else-Zweig des Präprozessor-Makro #ifdef _WIN32 definiert. Also nur auf _nicht_ Windows Systemen.

Den Unterschied zwischen typedef und #define würde ich mal in einem beliebigen "C"-Buch nachschlagen.

Das ist hier auf jeden Fall richtig typedefs zu verwenden.
Eberhard

[methusalem]

Hallo,

Diese Datentypen gibt es zwar unter Windows, aber z.B. nicht unter Linux. Daher sind auch die typedefs im else-Zweig des Präprozessor-Makro #ifdef _WIN32 definiert. Also nur auf _nicht_ Windows Systemen.
...

OK, da hatte ich mich unglücklich ausgedrückt. Ich meinte tatsächlich auch typedefs.

Und das es falsch ist die zu benutzen, hab ich ja nie behauptet :-)

Hast du noch einen Tip, wo ich zu dem Thema "Datentypen/Betriebssystem/typedef" mehr Infos nachschlagen kann? Da ich mein Programm mit dem QT Bibliotheken schreiben werde, möchte ich nämlich im restlichen Code auch plattformunabhängig bleiben.

Da sehr OT meinetwegen auch als PN.

[wayoda]

Hast du noch einen Tip, wo ich zu dem Thema "Datentypen/Betriebssystem/typedef" mehr Infos nachschlagen kann? Da ich mein Programm mit dem QT Bibliotheken schreiben werde, möchte ich nämlich im restlichen Code auch plattformunabhängig bleiben.

Unter
http://www.pronix.de
gibt es einen Menüpunkt Openbooks -> C von A-Z
mit der Online-Version eines kompletten Buches über C.

Es würde mich persönlich allerdings jetzt auch mal interessieren, ob die Windows-Version von QT die Datentypen ULONG,PCHAR usw. kennt. Falls Du da was herausfindest wäre es nett, wenn Du das hier posten könntest. Danke.

Eberhard

[methusalem]

Unter http://www.pronix.de gibt es einen Menüpunkt Openbooks -> C von A-Z mit der Online-Version eines kompletten Buches über C.

Es würde mich persönlich allerdings jetzt auch mal interessieren, ob die Windows-Version von QT die Datentypen ULONG,PCHAR usw. kennt. Falls Du da was herausfindest wäre es nett, wenn Du das hier posten könntest.

Vielen Dank für den Link!

Zu QT. Ich bin mir ziemlich sicher, das diese Datentypen nicht bekannt sind. Ich meine, das ich explizit windows.h includiert habe, um damit arbeiten zu können.

Ich werde der Sache aber heute noch einmal genauer auf den Grund gehen und das Ergebnis hier posten!

[Robert Marquardt]

Die Datentypen, die Windows im Win32 API verwendet sind sehr gut ausgedacht. MS macht da eine sehr feine Untergliederung.
Das ist ausnahmsweise vorbildlich.

Fuer Microsoft hat sich das schon zweimal bewaehrt. Beim Uebergang von Windows 3.1 (16 Bit) auf Win 95 (32 Bit) und dann wieder beim Uebergang auf XP 64 (64 Bit). Programme, die immer den korrekten Typ verwendeten, liessen sich durch Neukompilation portieren.

[methusalem]

Nabend zusammen,

Diese Datentypen gibt es zwar unter Windows, aber z.B. nicht unter Linux. Daher sind auch die typedefs im else-Zweig des Präprozessor-Makro #ifdef _WIN32 definiert. Also nur auf _nicht_ Windows Systemen.

Die Datentypen, die Windows im Win32 API verwendet sind sehr gut ausgedacht. MS macht da eine sehr feine Untergliederung. Das ist ausnahmsweise vorbildlich.

Zur Sicherheit! Nur damit ich es richtig verstehe. WCHAR und BOOLEAN beispielsweise sind Datentypen von Windows. Damit diese unter Linux nutzbar sind werden diese per typedef für Linux definiert. OK, soweit hab ich das begriffen.

Standartmäßig sind diese Datentypen aber auch nicht auf Windowssystemen verfügbar. Erst wenn ich windows.h includiere, kennt mein mingw Compiler diese Datentypen. In windows.h selbst werden diese Datentypen aber auch nicht definiert - oder ich habs überlesen. Also in irgend einem weiteren Include. Weiß zufällig jemand wo? Oder finde ich das im MSDN? Wo wird die Win32 API dokumentiert, das ich sowas mal nachlesen kann?

Wie sieht das nun mit der Linux Variante von iowkit.h aus? Es gibt doch nur eine iowkit.h für beide Plattformen, oder sehe ich das falsch? Also müssen Linux diese Datentypen irgendwie bekannt gemacht werden. Das geschieht ja dann wohl über iowwintypes.h, richtig?

Wenn ich nun eine Source für den IOW schreiben möchte, die sowohl unter Linux als auch unter Windows zu kompilieren ist - und genau dafür ist QT gemacht -, dann muss ich mich selbst mit #ifdef darum kümmern, welche Header eingebunden werden, richtig? Im Falle von Linux iowwintypes.h und bei Windows wäre es dann windows.h

Schwere Geburt. Aber ich glaube nun hab ich es ... Oder mach ich noch einen Gedankenfehler?

[Robert Marquardt]

C kennt erst mal nur ein paar Datentypen die Teil der Sprache sind (char, int, long int usw).
Alle anderen Deklarationen sind nicht Teil der Sprache sondern Teil eines APIs. Windows hat da das Win32 API das zu einem guten Teil in Windows.h deklariert ist. Windows.h besteht selbst hauptsaechlich aus weiteren include-Files. Die Gesamtgroesse duerfte locker die Megabyte-Grenze sprengen.

So jetzt aber genug. Dies ist das Support-Forum fuer IO-Warrior und nicht eine C-Schule.

[wayoda]

Standartmäßig sind diese Datentypen aber auch nicht auf Windowssystemen verfügbar. Erst wenn ich windows.h includiere, kennt mein mingw Compiler diese Datentypen.
...
Wie sieht das nun mit der Linux Variante von iowkit.h aus? Es gibt doch nur eine iowkit.h für beide Plattformen, oder sehe ich das falsch? Also müssen Linux diese Datentypen irgendwie bekannt gemacht werden. Das geschieht ja dann wohl über iowwintypes.h, richtig?

Die Frage ist schon berechtigt. Nicht jeder benutzt _WIN32. Der richtige Platz für die typedefs, ist die Header-Datei iowkit.h. Dies wird auch in der Beta-Version der Iowkit 1.5 Version so gemacht. Es ist nur eine kleine Änderung an der iowkit.h aus dem aktuellen SDK nötig um dies zu bewirken.

Indem man die folgenden Codezeilen am Anfang der Datei iowkit.h:
Code:

Code: Select all

 #ifdef _WIN32 
#define IOWKIT_API __stdcall 
#else 
#define IOWKIT_API 
#endif // _WIN32 

durch die folgenden ersetzt.

Code:

Code: Select all

 #ifdef _WIN32 
#define IOWKIT_API __stdcall 
#else 
#define IOWKIT_API 
/* 
 * Windows specific types and defines 
 */ 
typedef unsigned int     ULONG; 
typedef unsigned short   USHORT; 
typedef unsigned short   WORD; 
typedef unsigned char    UCHAR; 
typedef unsigned char    BYTE; 
typedef char *           PCHAR; 
typedef unsigned short * PWCHAR; 
typedef int              BOOL;
typedef unsigned char    BOOLEAN; 
typedef unsigned int     DWORD; 
typedef DWORD *          PDWORD; 
typedef void *           PVOID; 
typedef DWORD            HANDLE; 
 
#define FALSE 0 
#define TRUE 1 
 
#endif // _WIN32 

Damit sollten auch QT bzw. mingw die Datentypen kennen ohne windows.h includieren zu müssen.
Unter Linux wird damit iowwintypes.h überflüssig und für beide Betriebssysteme kann die gleiche Header-Datei verwendet werden.

Eberhard

[methusalem]

Moin,

erstmal vielen Dank für Eure Hilfe. Ich weiß, das dies für viele hier OT ist. Aber wenn jemand platformunabhängig programmieren möchte, wird in Eurer Doku da kein Stück drauf eingegangen, das es unterschiedliche iowkit.h gibt (bzw. unterschiedliche includes nötig sind).

So jetzt aber genug. Dies ist das Support-Forum fuer IO-Warrior und nicht eine C-Schule.

Ein Tip: Schreibt in zwei Sätzen in die Doku, wie die Leute mit der iowkit.h umgehen müssen, wenn Sie platformunabhängig bleiben wollen und erklärt kurz, warum Ihr diese Datentypen nehmt. Schon hätte sich dieser Thread nicht ergeben. Und so viel Aufwand ist das ja nicht.

Das gleiche gilt meiner Meinung nach für die iowclass.h. Nehmt Sie aus dem SDK heraus, oder schreibt klar rein, das die Beta Status hat.

Die elleganteste Lösung wäre ein Ordner mit Samples im SDK welche völlig plattformunabhängig ist.

Allen die mir bis hierher geholfen haben: Danke!