Fun-Soft - Programmierforum

Autor

Thread - Seiten: > 1 < [ 2 ]

000
21.11.2008, 02:21 Uhr
chriscrown

Hallo liebe C++-Experten!

Ich habe vor geraumer Zeit für eine Firma ein kleines Programm geschrieben, dass Barcodes einliest und mit anderen Daten in eine Datei schreibt. Das Programm läuft auf Handhelds, die mit einem Barcodescanner ausgestattet sind (HHP Dolphin 7200). Da mittlerweile mal ein paar Änderungen anstehen, soll das Programm etwas überarbeitet werden.

Nun zum eigentlichen Problem:
Ich bekomme meine Entwicklungsumgebungen (Eclipse, Borland Turbo C++ 6, Borland Tubo C++ 3 (uralt)) nicht dazu mir das Projekt zu builden. Es wird immer die vom Hersteller mitgelieferte Headerdatei beanstandet. Ich bekomme z.B. Fehlermeldungen wie:

Code:

[C++ Fehler] dolphin.h(69): E2293 ) erwartet

in Zeile 69 steht dann:

Code:

void DAPI capture_text(char far * buffer, unsigned col, unsigned row, unsigned width, unsigned height);

Dieses "far" macht da irgendwie Probleme, ich weiß aber nicht was...

Wie gesagt: Es ist die orginale Headerdatei vom Hersteller, mit der ich schon hundertfach das Projekt in meiner alten Entwicklungsumgebung (die leider nicht zur Verfügung steht) gebuildet habe.

Fehlt da vielleicht irgendwas in den Projekteinstellungen?? Habe ich vielleicht die zugehörige Lib nicht richtig eingebunden?? Es gibt unterschiedliche Libs für verschiedene "Models" (small, medium, large usw.). In dem alten Turbo C++ 3 gab es dafür eine Einstellmöglichkeit beim Compiler, im neueren Turbo C++ hab ich das nicht gefunden.

Es wäre super wenn mir da jemand helfen könnte, weil das Projekt nächsten Freitag laufen soll... :-)

Vielen Dank schon einmal und viele Grüße,
Chris

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

001
21.11.2008, 12:40 Uhr
~soisses
Gast

near and far are platform specific and on some systems just will not compile. On 16 bit Windows a near pointer was 16 bits and could only point into the programs data segment, a far pointer was 32 bit and could point at any piece of allocated memory

Also raus damit?!

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

002
21.11.2008, 16:25 Uhr
chriscrown

Alles klar, ich werde das mal raushauen und dann berichten!

Kann das vielleicht daran liegen, dass ich jetzt ein System mit zwei Prozessoren hab?? Damals hab ich immer auf ner Ein-Prozessor-Maschine entwickelt...

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

003
21.11.2008, 16:52 Uhr
0xdeadbeef
Gott
(Operator)

Hmm...sowas ist mir ja schon lange nicht mehr untergekommen. Mit den Prozessoren hat das nichts zu tun, jedenfalls nicht mehr, seit es keine 16-Bit-Maschinen mehr gibt - es geht hier um Speicheradressierung. Der near/far-Kram ist ein äußerst unangenehmes Relikt aus DOS-Zeiten - die Maschine hatte 16 bit pro Register, um aber 1 Megabyte RAM ansprechen zu können, wurden 20 bit für einen Zeiger benötigt. Der Speicher wurde dann segmentiert, und ein Far-Zeiger setzte sich zusammen aus der Segmentnummer und einem Near-Zeiger, der in das Segment zeigte.

Dass das ganze nicht kompiliert, liegt jedenfalls am Compiler, der far nicht als Schlüsselwort erkennt - üblicher ist eigentlich auch __far. Welche alte Entwicklungsumgebung hast du denn damals benutzt, und für welche Plattform hast du das damals kompiliert? Wenn es sich hier um eine 16-bit-Bibliothek handelt, die wirst du an ein 32-bit-Programm mit aller Wahrscheinlichkeit nicht ranlinken können, und für ein 16-bit-Programm brauchst du den far/near-Kram.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

004
21.11.2008, 17:04 Uhr
chriscrown

Okay, ich habe den ganzen far-Kram mal testweise rausgenommen, aber es funktioniert auch nicht. Ich bekomme dann im Borland Turbo C++ Builder 6

Code:

[C++ Warnung] conio.h(183): W8058 Präcompilierter Header: Code im Header kann nicht erzeugt werden
[Linker Fataler Fehler] Fatal: Nicht unterstützte 16-Bit Segment(e) in Modul laseracq.c

was wohl auf genau dieses 16-Bit-Problem hindeutet.

Ich habe mittlerweile wieder die alte Entwicklungsumgebung "Borland Turbo C++ 1.0" am Start mit der ich auch andere Fehler bekomme:

Bei der Deklaration einer einfachen clrscr-Funktion in der Headerdatei sagt er mir:

Code:

void DAPI clrscr(void);

Declaration syntax error

Das setzt sich dann do weiter fort.

Gibt es vielleicht irgendeine Möglichkeit den alten Compiler in eine neue Entwicklungsumgebung einzubinden, z.B. in Eclipse?? Nur in der Dos-Box zu programmieren ist ja alles andere als spaßig...

Danke auf jeden Fall schon einmal!!
Chris

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

005
21.11.2008, 17:49 Uhr
0xdeadbeef
Gott
(Operator)

Ich vermute, dass DAPI ein Makro der Bibliothek ist, die du da benutzt, und dementsprechend erst bekannt ist, nachdem ihr Header eingebunden wurde - wahrscheinlich wird da __stdcall, __fastcall, __cdecl oder __pascal draus, oder etwas in der Art. Für deine eigenen Funktionen brauchst du das im Zweifel nicht.

Übrigens, der far-Kram muss da jetzt wieder hin, das ist klar, oder?
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 21.11.2008 um 17:50 Uhr von 0xdeadbeef editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

006
22.11.2008, 02:09 Uhr
chriscrown

Ich hab die Headerdatei gecheckt und da steht

Code:

#define DAPI __cdecl

oberhalb der Funktion die beim Compilieren angemahnt wird. Von daher sollte das doch eigentlich hinhauen. Muss ich jetzt meinen Compiler noch irgendwas sagen, damit er damit klarkommt??

Ich habe übrigens nochmal ein komplett leeres Projekt erstellt und nur versucht meine Headerdatei (im Original Lieferzustand) einzubinden, auch dann gibt mir der Compiler schon diese Fehler raus. Irgendwie scheint er also von Haus aus die Headerdatei noch nicht zu mögen... Vielleicht wird auch die Lib nicht richtig eingebunden (obwohl die in meiner Projektübersicht schön auftaucht und auch von mir geöffnet werden kann).

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

007
22.11.2008, 02:24 Uhr
chriscrown

ENTWARNUNG!!

Ich habs hinbekommen! Ich hab mir noch ne andere Version des alten Turbo C++ Compilers gezogen (Version 3.0) uns siehe da: Es funktioniert auf Anhieb!!

Kann mir vielleicht jemand erklären wie ich den Turbo Compiler dazu bekomme mit Eclipse zusammen zu arbeiten?? Man müsste das Ding ja auch manuell über die Kommandozeile compilieren können, genau das müsste ja auch über Eclipse gehandled werden können, oder??

Ich entwickle sonst fast ausschließlich in Java und bin daher etwas Eclipse-abhängig... Falls ihr mir ne andere IDE (oder wenigstens Notepad++) an Start bringen könnt wäre ich Euch SEHR DANKBAR :-)

Viele Grüße,
Chris

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

008
22.11.2008, 07:21 Uhr
0xdeadbeef
Gott
(Operator)

Ich habe ernsthafte Zweifel daran, dass Eclipse darauf ausgelegt ist, mit Turbo C++ 3.0 zusammenzuarbeiten - immerhin handelt es sich dabei um einen uralten Compiler aus Zeiten bevor die Standards, auf die Eclipse/CDT sich aller Wahrscheinlichkeit verlässt (mindestens bei den praktischeren Features) überhaupt existierten.

Du kannst es natürlich versuchen, allerdings würde ich mich mit der Anfrage eher an die Eclipse/CDT-Mailingliste wenden (Ich gehe jetzt einfach mal davon aus, dass das Projekt sowas hat). Die werden wahrscheinlich ziemlich überrascht sein, dass jemand auf so eine Idee kommen könnte, aber im Zweifel deutlich bessere Hinweise darauf geben können, ob und wie so etwas umzusetzen sein könnte.

Aber...war bei Turbo C++ seinerzeit nicht eine IDE dabei? Oder zumindest, was damals als IDE durchging.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

009
22.11.2008, 09:26 Uhr
~f.-th.
Gast

Borland c/c++ 1.0 stammen noch aus den 80er Jahren und waren die ersten "Gehversuche"
dann gabs noch eine 1.5 Variante
Ab den c/c++ 2.0 wurde der Quellcode den heutigen C/C++ ähnlicher
die 3.0 oder 3.1er Versionen waren weit verbreitet und hatten schon eine mausbedienbare
IDE. Dafür ( 3.x ) müsste noch viel Quelltext verfügbar sein.

MfG f.-th.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: > 1 < [ 2 ] [ C / C++ (WinAPI, Konsole) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: