[C]DLL meecompilen en wat kleine vraagjes

[Gonadan]

Hallo allemaal,
ik ben een beetje aan het vastlopen.

Ik ben bezig met een opdracht in C, nou heb ik niet veel ervaring met C, wel met Java en C# maar dat is toch anders. Ik compile met gcc.

Nu heb ik de code (.c) van een testprogramma'tje en ook de .exe daarvan. De .exe werkt maar ik kan de .c code niet eens compilen. Nu weet ik dat de code via een DLL moet werken. Maar als ik compile zonder extra opties gaat hij over z'n plaat op een aantal regels.

bv.

code:

typedef char FAR*    LPSTR;

Het is me wel gelukt om zelf de functies aan te roepen van de .dll dmv. LoadLibrary en GetProcAddress maar dan kan ik de resultaten niet lezen (misschien weet ik wel niet hoe ).

Ik heb dus het gevoel dat hij meteen meegecompiled is ofzo, omdat die .exe wel gewoon werkt.
Het zou dus moeten kunnen.

Kan iemand mij helpen? (Google iig niet )

En dan vroeg ik me nog wat af, wat doet dit precies:

code:

LPBYTE far pascal GetCount(void);

Alvast bedankt.

[TheBlasphemer]

Die typedef regel zou prima moeten werken, zie niet wat daar mis mee kan zijn.
Verder compile je nooit de DLL zelf mee, maar een .lib (library) file. Deze bevat informatie over de functies en procedures in de DLL, of bevat een aantal functies die je kan gebruiken (static library).
Zoek dus even de .lib op.

Misschien als je ons wat meer informatie kan geven, bijv welk programma het om gaat, en welke dll, kunnen we je beter helpen

[Gonadan]

TheBlasphemer schreef op woensdag 08 februari 2006 @ 08:40:
Die typedef regel zou prima moeten werken, zie niet wat daar mis mee kan zijn.
Verder compile je nooit de DLL zelf mee, maar een .lib (library) file. Deze bevat informatie over de functies en procedures in de DLL, of bevat een aantal functies die je kan gebruiken (static library).
Zoek dus even de .lib op.

Als ik er vanuit mag gaan dat de .lib dezelfde naam heeft als de .dll dan heb ik hem gevonden.

Hoe kan ik deze dan meecompilen?

Misschien als je ons wat meer informatie kan geven, bijv welk programma het om gaat, en welke dll, kunnen we je beter helpen

Het is geen bekend programma, ik werk voor een bedrijf


EDIT: Ik vond het al zo vreemd dat in het test programma de aanroepen normaal waren terwijl ik het via de .dll met _ en @0 en dergelijke moest doen.

[ Voor 13% gewijzigd door Gonadan op 08-02-2006 08:48 ]

[TheBlasphemer]

Ja, de .lib heeft meestal zelfde naam als de DLL.
Meecompilen ligt eraan welke compiler je gebruikt, meestal staat het wel vermeld in de manual of de output als je "-h" doet
Bij VC2005 kun je libraries instellen bij Project properties -> Linker -> Input -> Additional Depencies

Laat even weten of het gelukt is

[Gonadan]

Ik probeer nu te compilen door:

code:

gcc -static test.c -L. -ltestlibrary -o test

maar al meteen op de regels

code:

typedef char FAR*       LPSTR;
typedef BYTE FAR*       LPBYTE;
LPBYTE far pascal GetCount(void);

krijg ik de fouten

code:

error: syntax error before '*' token
warning: data definition has no type or storage class

error: syntax error before '*' token
warning: data definition has no type or storage class

error: syntax error before "far"
warning: data definition has no type or storage class

En daarna nog een stapel fouten die hier gevolg van zijn.

Kan ik hem wel statisch linken als de code op zich al niet wil compileren?

[H!GHGuY]

die BYTE, FAR, LPBYTE zijn afaik windows typedefs.

zoek deze even op en declareer ze zelf

[Gonadan]

HIGHGuY schreef op woensdag 08 februari 2006 @ 10:15:
die BYTE, FAR, LPBYTE zijn afaik windows typedefs.

zoek deze even op en declareer ze zelf

Buiten het feit dat ik hier weinig mee kan:
volgens de manual van de library is LPBYTE de MS-DOS versie en HANDLE de windows versie

[igmar]

Om te beginnen : Welk (target) platform hebben we het hier over ? far pointers stammen nog uit het real-mode tijdperk, en waren vereist voor het adressen van absolute adressen (vide geheugen), en voor het aanroepen van BIOS interrupts.

Indien je probeert te compilen voor een huidig system (linux, bsd, unix, NT, 2k, XP) : da's een flat memory model, en dan zijn far pointers zowiezo vrij nutteloos.

[Gonadan]

igmar schreef op woensdag 08 februari 2006 @ 11:07:
Om te beginnen : Welk (target) platform hebben we het hier over ? far pointers stammen nog uit het real-mode tijdperk, en waren vereist voor het adressen van absolute adressen (vide geheugen), en voor het aanroepen van BIOS interrupts.

Indien je probeert te compilen voor een huidig system (linux, bsd, unix, NT, 2k, XP) : da's een flat memory model, en dan zijn far pointers zowiezo vrij nutteloos.

Ik wil het uiteindelijk op 2K laten draaien. Maar het testprogramma'tje gebruikt ze wel in de broncode.
Alleen kan ik dat niet compilen. Hij gaat daar steeds over z'n nek. Ik hoop dat ik gewoon de verkeerde compile opties gebruik. Al heb ik al erg veel geprobeerd.

Op ben ik aan het proberen om de dll zelf in te laden mbv windows.h. Dat lukt, en ik kan de functies aanroepen. Alleen het resultaat van zo'n functie staat volgens de beschrijving dan in een gedefinieerde struct. Maar zodra ik die meuk probeer uit te lezen krijg ik alleen smileys en ruitjes e.d.

[TheBlasphemer]

Even een rare vraag, maar heb je zelf enige ervaring met C?
Als ik dit zo zie zul je flink wat aanpassingen moeten doen, en zal het echt niet zo simpel zijn als gewoon functies aanroepen uit een dll
En het is zoieso een erg slecht idee om binary data (zoals structs) zomaar opt scherm te printen, dan krijg je smileys

[Gonadan]

TheBlasphemer schreef op woensdag 08 februari 2006 @ 12:15:
Even een rare vraag, maar heb je zelf enige ervaring met C?

niet bijster veel

Als ik dit zo zie zul je flink wat aanpassingen moeten doen, en zal het echt niet zo simpel zijn als gewoon functies aanroepen uit een dll
En het is zoieso een erg slecht idee om binary data (zoals structs) zomaar opt scherm te printen, dan krijg je smileys

Ik heb uitgevonden dat ik 24 bytes terug krijg als ik zo'n functie aanroep. En dat zouden er 50 moeten zijn. Ik heb alleen het gevoel dat die far en pascal er iets mee te maken hebben.

Het punt is: ik begrijp niet dat die source code niet wil compilen terwijl de .exe ernaast staat. Het is dus ooit wel gecompiled, alleen weten ze hier niet hoe.

[TheBlasphemer]

Waarschijnlijk met een andere compiler voor een ander platform
Anyway, heb toch niks te doen, dus heb je MSN die in je profiel staat even toegevoegd, Als je mij even de files stuurt kan ik wel even voor je proberen
Ik vermoed namelijk dat dit niet zomaar compiled, maar dat je wat dingen moet gaan porten, en dat vergt meestal wel wat meer werk dan alleen compilen met andere opties

EDIT:
Na gesprek op MSN blijft dus dat de libraries voor Borland en MSVC beschikbaar zijn, echter wil hij compilen met GCC.
Als leesvoer dit opgegeven:
http://www.inonit.com/cygwin/jni/invocationApi/archive.html
http://www.emmestech.com/...torial/tools/dlltool.html
http://wiki.tcl.tk/2435

Hopelijk zo iedereen op de hoogte, en misschien nog nuttig voor anderen die dit probleem ondervinden

[ Voor 35% gewijzigd door TheBlasphemer op 08-02-2006 13:08 ]

[igmar]

Gonadan schreef op woensdag 08 februari 2006 @ 11:14:
Ik wil het uiteindelijk op 2K laten draaien.

Da's nog steeds geen antwoord op de vraag. Ik vermoed dat dit oude libs zijn, uit de DOS tijd. En die werken echt niet op een modern OS.

Op ben ik aan het proberen om de dll zelf in te laden mbv windows.h. Dat lukt, en ik kan de functies aanroepen. Alleen het resultaat van zo'n functie staat volgens de beschrijving dan in een gedefinieerde struct. Maar zodra ik die meuk probeer uit te lezen krijg ik alleen smileys en ruitjes e.d.

En je weet zeker dat deze libs voor het flat memory model zijn ? Ik vermoed van niet namelijk

[Gonadan]

Het is origineel gecompileerd met Borland 2.0 large model en Microsoft C 8.0 large model.

Voor DOS dus

Ik heb van de .lib nu een .a lib gemaakt, en probeer die FAR pointers om te zetten naar normale.
Ik hoop dat het dan nog wel met de dll kan werken.

[Gonadan]

Ok, ik ben met hulp van TheBlasphemer een stuk verder gekomen.

Ik zit nu alleen nog met 1 fout die ik niet snap. Namelijk deze:

C:

[Linker error] undefined reference to `Z8STB_InitPc@4'

en dat terwijl in de .def file

code:

_STB_Init@4

staat in de c code heet hij dan ook

code:

STB_Init(var)

dit gebeurd bij elke functie die in de library zit

heeft iemand een idee?

[Soultaker]

Die Z8STB_InitPc is een gedecoreerde naam zoals die door een C++-compiler gegenereerd wordt. Als de oorspronkelijke DLL in C geschreven was en je schrijft een programma in C++, dan moet je C-linkage declareren voor de door jouw gebruikte functies:

C++:

extern "C" int STB_Init(char *var);

Of als je een meerdere declaraties hebt:

C++:

extern "C" {
#include "headertje.h"
}

Als je programma gewoon in C geschreven is, kun je die natuurlijk gewoon door een C compiler halen i.p.v. een C++-compiler.

Als ik het goed begrijp heb je trouwens al een werkende DLL en import library, dus dan heeft die .def file er niets mee te maken - die wordt alleen gebruikt om de DLL (en import library) te genereren.

[Gonadan]

Soultaker schreef op woensdag 08 februari 2006 @ 15:39:
Die Z8STB_InitPc is een gedecoreerde naam zoals die door een C++-compiler gegenereerd wordt. Als de oorspronkelijke DLL in C geschreven was en je schrijft een programma in C++, dan moet je C-linkage declareren voor de door jouw gebruikte functies:

C++:

extern "C" int STB_Init(char *var);

Of als je een meerdere declaraties hebt:

C++:

extern "C" {
#include "headertje.h"
}

Als je programma gewoon in C geschreven is, kun je die natuurlijk gewoon door een C compiler halen i.p.v. een C++-compiler.

Ik gebruik gcc om hem te compilen, dat lijkt me geen C++ toch?

Als ik het goed begrijp heb je trouwens al een werkende DLL en import library, dus dan heeft die .def file er niets mee te maken - die wordt alleen gebruikt om de DLL (en import library) te genereren.

De dll heb ik niet zelf gemaakt, die werkt gewoon. En ik had een .lib library, die heb ik omgezet naar een .a library via een .def file omdat .lib niet zou werken met gcc.

Alleen snap ik dan nog steeds niet waarom hij die functies niet gewoon kan aanroepen.


EDITIk heb het om de commandline gecheckt. En het blijkt dat het ***programma Dev-C++ het altijd als C++ foutmeldingen weergeeft.

Dus het linken gaat fout denk ik.

[ Voor 9% gewijzigd door Gonadan op 08-02-2006 15:57 ]

[Gonadan]

Yep, ik heb:
test.c
blaat.h
libblaat.a
blaat.lib
blaat.dll
blaat.def

en gebruik hiervoor:

gcc -I. -L. -lblaat test.c

En het werkt niet

[igmar]

Gonadan schreef op woensdag 08 februari 2006 @ 14:05:
Voor DOS dus

Je kan niet zomaar een DOS lib pakken, en dan hopen dat het gaat werken. Ook een large model werkt altijd met far pointers, en als je een native win32 binary hebt niet AFAIK. Nog afgezien van dit probleem heb je in Windows geen DOS interrupts meer, geen io support, etc.

Heb je geen source ? Da's eigenlijk wel een vereiste in dit geval.

[ Voor 30% gewijzigd door igmar op 08-02-2006 16:27 ]

[Gonadan]

igmar schreef op woensdag 08 februari 2006 @ 16:20:
[...]


Je kan niet zomaar een DOS lib pakken, en dan hopen dat het gaat werken.. Heb je geen source ? Da's eigenlijk wel een vereiste.

Ik heb een source, die heb ik wat aangepast, het was een DOS based source, met FAR enzo.
toen heb ik een dll (win32) geript naar .def, en daar weer een .a lib van gemaakt.

Die gebruik ik nu samen met de win32 .h file die bij de .dll hoort.

Alleen krijg ik steeds die linker error.

[igmar]

Gonadan schreef op woensdag 08 februari 2006 @ 15:02:
Ik zit nu alleen nog met 1 fout die ik niet snap. Namelijk deze:

C:

[Linker error] undefined reference to `Z8STB_InitPc@4'

en dat terwijl in de .def file

code:

_STB_Init@4

staat in de c code heet hij dan ook

code:

STB_Init(var)

dit gebeurd bij elke functie die in de library zit

Kloppen de prototypes ? De linker error is echt een typische C++, die de parameters in de functienaam codeert. Ik heb ooit een overzicht gehad met wat g++ kan genereren, maar dat kan ik momenteel even niet terugvinden..

[Soultaker]

Compileer eens je eigen source afzonderlijk naar een object file (dus zonder te linken) en kijk dan welke unresolved symbols daar in zitten?

(Symbols bekijken kan met nm uit de GNU binutils package; zit ook bij MinGW en kun je ook via de Bloodshed IDE installeren).

Ik heb nog steeds het idee dat er ergens een C++ compiler bij komt kijken; of GCC moet onder Windows ook aan name mangling doen (wat me sterk lijkt).

[Gonadan]

Soultaker schreef op woensdag 08 februari 2006 @ 17:28:
Compileer eens je eigen source afzonderlijk naar een object file (dus zonder te linken) en kijk dan welke unresolved symbols daar in zitten?

(Symbols bekijken kan met nm uit de GNU binutils package; zit ook bij MinGW en kun je ook via de Bloodshed IDE installeren).

Ik heb nog steeds het idee dat er ergens een C++ compiler bij komt kijken; of GCC moet onder Windows ook aan name mangling doen (wat me sterk lijkt).

Compileren zonder te linken gaat niet omdat hij dan ook die foutmeldingen geeft.
Ik heb hem nu gelinkt naar de originele .lib library en dat doet hij wel, alleen krijg ik dan onleesbare waarden terug uit de functies.
Hoe kan die .lib nou wel werken? gcc had toch .a nodig?

[Soultaker]

Gonadan schreef op donderdag 09 februari 2006 @ 08:13:
Compileren zonder te linken gaat niet omdat hij dan ook die foutmeldingen geeft.

Welke foutmeldingen; die linker error die je eerder postte? Dat is echt onmogelijk.

Of bedoel je die syntax errors waar je het eerder over had? Die kunnen optreden bij het compileren, maar die kun je ook onmogelijk oplossen door te linken. Je moet hoe dan ook je broncode kunnen compileren zonder te linken - probeer eerst de fouten die daarbij optreden maar op te lossen.

Ik heb hem nu gelinkt naar de originele .lib library en dat doet hij wel, alleen krijg ik dan onleesbare waarden terug uit de functies.

Hoe kan die .lib nou wel werken? gcc had toch .a nodig?

Ik durf hier weinig zinnigs over te zeggen (ook omdat ik niet zo heel veel ervaring heb met GCC onder Windows) maar ik heb het idee dat je nogal chaotisch te werk gaat, dus dan kan het op van alles en nogwat stuk gaan (een functie aanroepen met een verkeerde calling convention bijvoorbeeld).

[Gonadan]

Soultaker schreef op donderdag 09 februari 2006 @ 17:39:
[...]

Welke foutmeldingen; die linker error die je eerder postte? Dat is echt onmogelijk.

Raar maar waar

Of bedoel je die syntax errors waar je het eerder over had? Die kunnen optreden bij het compileren, maar die kun je ook onmogelijk oplossen door te linken. Je moet hoe dan ook je broncode kunnen compileren zonder te linken - probeer eerst de fouten die daarbij optreden maar op te lossen.

Dan ga ik dat proberen. Ik heb je msn toegevoegd, en hoop dus dat ik je nog spreek.
Misschien kan je me wat helpen.

[Soultaker]

Gonadan schreef op vrijdag 10 februari 2006 @ 09:07:
Raar maar waar

Toch geloof ik het niet. Welk commando gebruik je dan om te compileren?

Dan ga ik dat proberen. Ik heb je msn toegevoegd, en hoop dus dat ik je nog spreek.
Misschien kan je me wat helpen.

Ik geef de voorkeur aan communicatie via dit forum - dat zorgt ervoor dat je tussendoor de tijd hebt om dingen uit te proberen en je probleem overzichtelijk te formuleren.

[MSalters]

Gonadan schreef op donderdag 09 februari 2006 @ 08:13:
[...]
Compileren zonder te linken gaat niet omdat hij dan ook die foutmeldingen geeft.

Je weet dat GCC default compilet en linkt, ook als je zelf de linker niet aanroept?

[Gonadan]

MSalters schreef op zaterdag 11 februari 2006 @ 00:36:
[...]

Je weet dat GCC default compilet en linkt, ook als je zelf de linker niet aanroept?

Hoe weet GCC dan welke library ik wil gebruiken als ik dat niet op de commandline aangeef?

ik gebruik:
gcc -Wall -I. prog.c prog.dll
Ik heb het ook met de -static flag geprobeerd maar dat maakt niets uit.

[igmar]

Gonadan schreef op maandag 13 februari 2006 @ 08:37:
ik gebruik:
gcc -Wall -I. prog.c prog.dll
Ik heb het ook met de -static flag geprobeerd maar dat maakt niets uit.

Dit gaat niet werken denk ik.. gcc kan niet met een .dll linken AFAIK. Nu pak je prog.c, en maakt daar samen met prog.dll een .exe van. Dat gaat alleen goed indien prog.dll een objectfile is.

[Gonadan]

Ik heb het ook met impdef een .a gemaakt en die gelinkt.
Dat werkt ook al niet.

Ik heb ook andere compilers geprobeerd maar de fout blijft hetzelfde.

[Soultaker]

Gonadan schreef op maandag 13 februari 2006 @ 08:37:
Hoe weet GCC dan welke library ik wil gebruiken als ik dat niet op de commandline aangeef?

Dat weet 'ie niet (behalve de standard libraries, die 'ie by default automatisch toevoegt) maar bij het compileren is dat ook niet nodig. Als je inderdaad probeert te linken en geen extra libraries opgeeft, dan is het ook logisch dat je meldingen krijgt over 'undefined references' .

ik gebruik:
gcc -Wall -I. prog.c prog.dll
Ik heb het ook met de -static flag geprobeerd maar dat maakt niets uit.

Static linking gaat op deze manier niet werken. Compileren (zonder linken) gaat met de -c flag, bijvoorbeeld: gcc -Wall -I. -c prog.c -o prog.o. Include paths moet je natuurlijk wel opgeven (die zijn noodzakelijk voor het compileren) maar library paths en libraries niet.

Als dit foutloos werkt (en je eerdere posts lijken dat wel aan te geven) dan kun je met bv. nm zien welke symbols geïmporteerd worden en die vergelijken met de symbols die dll exporteert. Als het goed is komen de namen overeen, maar als prog.o bijvoorbeeld Z8STB_InitPc@4 importeert en je library blaat.lib exporteert STB_Init@4 dan heb je in prog.c toch echt een verkeerde declaratie staan.

[Gonadan]

Static linking gaat op deze manier niet werken. Compileren (zonder linken) gaat met de -c flag, bijvoorbeeld: gcc -Wall -I. -c prog.c -o prog.o. Include paths moet je natuurlijk wel opgeven (die zijn noodzakelijk voor het compileren) maar library paths en libraries niet.

Als dit foutloos werkt (en je eerdere posts lijken dat wel aan te geven) dan kun je met bv. nm zien welke symbols geïmporteerd worden en die vergelijken met de symbols die dll exporteert. Als het goed is komen de namen overeen, maar als prog.o bijvoorbeeld Z8STB_InitPc@4 importeert en je library blaat.lib exporteert STB_Init@4 dan heb je in prog.c toch echt een verkeerde declaratie staan.

Allereerst: voor jullie hulp

Ik weet nu eindelijk wat ik aan het doen ben.
Het compilen zonder linken lukt nu, moest wel half windows aan header files importeren maar het werkt. Ook het compilen met linken werkt.

Nu rest alleen nog het volgende probleem: de functies geven niet terug wat ze terug horen te geven.
Volgens de handleiding geven de functies de resultaten als pointer naar een struct. (Dit heb ik ook zien staan in de code van het testprogramma'tje).
Echter, als ik dat geheugenblok uitprint met de functie die ik ook uit het testprogramma heb, dan geeft hij geen goede resultaten.
Er zit een parameter nError in de struct, die moet 0 zijn als er geen fouten zijn opgetreden.
Ik krijg helaas een nError van 4663944 als ik hem als %d fprint.

Wat kan hier de oorzaak van zijn? Verkeerde datatypen misschien?

[Gonadan]

*schop*

[Soultaker]

Hmz, misschien iets met alignment. Post de hele struct definitie eens?

Als het een probleem met alignment is, dan zou je in ieder geval het eerste veld wel moeten kunnen printen, lijkt me.

[Gonadan]

C:

typedef struct tagCATBUF 
{
    int           nError;     
    WORD    nBytesUsed; 
    int           nItems;
    WORD    nFmt;
    char    CatBuf[2];
} CATBUF, *PCATBUF, FAR *LPCATBUF;

Omdat het origineel in large model gecompiled is heb ik ook wat zitten spelen met die ints en words maar dat maakte weinig uit.

[Soultaker]

Tja, dit is echt debug werk; lastig om zonder code te doen. Misschien kun je eens de 20 bytes die op het adres dat je terugkrijgt staan bekijken en vergelijken met waarden die je verwacht?

Verder kan ik me voorstellen dat er toch nog iets mis is met de function call; misschien kun je eens op assembly nivo kijken wat er precies gebeurt. Als het goed is komt de pointer naar de struct in eax terecht. Overigens klinkt wel 4663944 als een legitiem adres, maar dat is natuurlijk lastig te zeggen (je kunt 'm i.i.g. dereferencen).

[Gonadan]

Soultaker schreef op maandag 20 februari 2006 @ 15:59:
Tja, dit is echt debug werk; lastig om zonder code te doen. Misschien kun je eens de 20 bytes die op het adres dat je terugkrijgt staan bekijken en vergelijken met waarden die je verwacht?

Verder kan ik me voorstellen dat er toch nog iets mis is met de function call; misschien kun je eens op assembly nivo kijken wat er precies gebeurt. Als het goed is komt de pointer naar de struct in eax terecht. Overigens klinkt wel 4663944 als een legitiem adres, maar dat is natuurlijk lastig te zeggen (je kunt 'm i.i.g. dereferencen).

die 4663944 is geen adres maar een waarde, het zou 0 moeten zijn. dus het lijkt inderdaad wel alsof die functie loop te eikelen en weigert zijn werk te doen. Het gebrek aan documentatie is weer schrijnend

[Soultaker]

Ah ja, natuurlijk; post dan het adres van die struct eens.

Krijg je uit andere functies (zoals die Init die je postte) wel zinnige resultaten?

[ Voor 42% gewijzigd door Soultaker op 20-02-2006 16:25 ]

[Gonadan]

17956876

Ik heb een beetje zitten spelen met die typen (WORD/int/whatever) omdat het origineel voor 16-bit was. Maar dat hielp niet veel.

Die init geeft keurig TRUE terug, dus die klopt wel.

[ Voor 39% gewijzigd door Gonadan op 21-02-2006 08:27 . Reden: eerst denken, dan posten |:( ]

[__fred__]

Volgens mij heb je het volgende probleem met je dll's.
De oude source die je had was een 16bit DLL voor windows 3.xxx. Deze code kun je als executable draaien in WinNT,2K,XP via het WOW subsystem.
windows 3.xxx had namelijk een segmented memory model terwijl je windowsNT een 32bit flat virtual memory space heeft. Je kunt die DLL of code dus niet zomaar in een 32 bit memory space gaan draaien, unsegmented, omdat je dan de gekste resultaten krijgt.
Een far pointer is in het segmented memory model namelijk wel 32 bits, maar er is een deel overlap in een far pointer omdat er een 20bit adres uit gecreeerd wordt door het segmentadress vier bits naar links te schuiven en dan de offset erbij te tellen. Er kunnen dus verschillende far pointer waarden naar hetzelfde 20bit adres wijzen.
Bovendien heeft elk proces zijn eigen 32 bit address space itt tot een address space voor alle processen, dus memory delen tussen processen werkt ook niet. Daardoor lopen calls naar system dlls ook niet goed.
Wat WOW doet is een segmented adress space creeren voor alle 16 bit processen, daarin een DLL laden die de 16 bit stub functies mapt naar de echte 32 bit functies zodat je ook de beschikking hebt over de 16 bit windows api.
Volgens mij kun je of de source van die DLL c.q. library porten of ook een 16 bit executable schrijven.
(Of de crappy pauperinventieve oplossing: een 16 bit OLE server bouwen die de DLL aanroept met een 32 bit client die je OLE objecten gebruikt.)

edit:

Deze dude gebruikt windows messaging om tussen een 16 en 32 bit executable uit te wisselen. Ook wel aardig verzonnen en misschien wel sneller dan OLE:

http://www.codeproject.co..._copydata_32_-_16_bit.asp

[ Voor 14% gewijzigd door __fred__ op 21-02-2006 23:39 ]

[Soultaker]

Het lijkt mij dat je die 16-bit DLL dan helemaal niet kan laden. Ik dacht dat de WOW (Windows on Windows ) support zich beperkte tot 16-bits applicaties die dan misschien 16-bits DLL's kunnen laden, maar volgens mij krijg je nooit een 16-bits DLL geladen in een 32-bits applicatie. Maar ik moet bekennen dat ik er nooit zo diep ingedoken ben, dus ik weet het ook niet precies.

[__fred__]

Soultaker schreef op dinsdag 21 februari 2006 @ 23:46:
Het lijkt mij dat je die 16-bit DLL dan helemaal niet kan laden. Ik dacht dat de WOW (Windows on Windows ) support zich beperkte tot 16-bits applicaties die dan misschien 16-bits DLL's kunnen laden, maar volgens mij krijg je nooit een 16-bits DLL geladen in een 32-bits applicatie. Maar ik moet bekennen dat ik er nooit zo diep ingedoken ben, dus ik weet het ook niet precies.

Klopt en daarom moet je dus ook een 16 bits host executable bakken die de DLL laadt. Die kun je dan vanuit een 32 bits proces besturen via Windows Messaging of OLE oid

[Gonadan]

En kan ik dan niet gewoon een 16-bit executable eromheen bakken?
Volgens mij heb ik daar nog een deel source code van, alleen wilde die niet compilen onder windows.

En zo ja, kan ik dan die functies met JNI aanroepen? (na een wrapper functie gemaakt te hebben natuurlijk)

Edit:
Ik denk trouwens dat ik ook een 32 bit dll heb. Alleen gebruik ik daar als voorbeeld de 16-bit source code om het uit te lezen. Alleen moet ik daarin zoveel aanpassen dat ik niet meer weet of het nou aan de link of aan mij ligt. (bijvoorbeeld FAR gewoon weghalen)

Ik heb nu ook Open Watcom gedownload, misschien kan ik daar beter kiezen voor welk platform ik wil compilen.

[ Voor 44% gewijzigd door Gonadan op 22-02-2006 09:01 ]

[Soultaker]

Als je een 32-bit DLL hebt, kun je die in principe het beste gebruiken, anders kun je voor Windows Vista weer helemaal opnieuw beginnen. Sowieso is het makkelijker om 32-bits binaries te schrijven.

De vraag is dan dus hoe en of die 32-bit DLL werkt. Heb je applicaties die 'm ook gebruiken en waarmee 'ie goed werkt? Zo ja, dan lijkt me dat je zou moeten kunnen uitzoeken wat ze precies retourneren.

Wat JNI betreft: de native code moet in een 32-bit DLL komen, dus daarin kun je ook geen 16-bit DLL laden. Je moet dan rare constructies gaan toepassen zoals een aparte 16-bit applicatie starten en daarmee communiceren via Java ofzo - niet echt mooi als je het mij vraagt.

[Gonadan]

Soultaker schreef op woensdag 22 februari 2006 @ 10:36:
Als je een 32-bit DLL hebt, kun je die in principe het beste gebruiken, anders kun je voor Windows Vista weer helemaal opnieuw beginnen. Sowieso is het makkelijker om 32-bits binaries te schrijven.

De vraag is dan dus hoe en of die 32-bit DLL werkt. Heb je applicaties die 'm ook gebruiken en waarmee 'ie goed werkt? Zo ja, dan lijkt me dat je zou moeten kunnen uitzoeken wat ze precies retourneren.

Wat JNI betreft: de native code moet in een 32-bit DLL komen, dus daarin kun je ook geen 16-bit DLL laden. Je moet dan rare constructies gaan toepassen zoals een aparte 16-bit applicatie starten en daarmee communiceren via Java ofzo - niet echt mooi als je het mij vraagt.

Nou aangezien ik van een functie die alleen maar een boolean (int) retourneert ik wel een goed resultaat krijg kan ik er toch vanuit gaan dat als ik die andere functies goed aanroep het zou moeten werken.

Hoe kan ik zien wat ze precies retourneren? Ik heb zo'n ding al gedecompiled maar dat is alleen maar hoofdpijn bevorderend.

[igmar]

Is de sizeof(struct) in de originele omgeving hetzelfde als de sizeof(struct) in de omgeving die je nu gebruikt ? Ik denk zelf dat je met padding oid zit, dat verschilt per omgeving en compiler.

[Gonadan]

igmar schreef op woensdag 22 februari 2006 @ 10:44:
Is de sizeof(struct) in de originele omgeving hetzelfde als de sizeof(struct) in de omgeving die je nu gebruikt ? Ik denk zelf dat je met padding oid zit, dat verschilt per omgeving en compiler.

Ik zou niet weten hoe ik de sizeof() van de originele omgeving moet achterhalen.
Ik heb niet meer dan een API, (dos) source code, de gecompilde source code en libraries for dos, win16 en win32 (lib én dll)

[Soultaker]

Gonadan schreef op woensdag 22 februari 2006 @ 10:39:
Hoe kan ik zien wat ze precies retourneren? Ik heb zo'n ding al gedecompiled maar dat is alleen maar hoofdpijn bevorderend.

Dat is inderdaad lastig. Is het veel code? Zo niet, kun je hier zo'n functie posten die wat retourneert, met de functie- en structdefinitie die je er nu bij hebt?

[Gonadan]

Gonadan schreef op maandag 20 februari 2006 @ 15:43:

C:

typedef struct tagCATBUF 
{
    int           nError;     
    WORD    nBytesUsed; 
    int           nItems;
    WORD    nFmt;
    char    CatBuf[2];
} CATBUF, *PCATBUF, FAR *LPCATBUF;

Omdat het origineel in large model gecompiled is heb ik ook wat zitten spelen met die ints en words maar dat maakte weinig uit.

Dat is de struct waarin de functies hun resultaat zetten. Die ints kunnen ook WORD zijn. Maar dat hangt af van het platform denk ik.

Bedoel je met functie definitie de code? Want die heb ik niet
Ik definieer hem zo:

C:

_declspec(dllexport) HANDLE WINAPI _getInfo(void);

Dat heb ik uit de 32-bit header file die erbij zit gehaald.

Ik kan ook met far pascal of lpbytes aan de gang maar dat geeft ook niets nuttigs en lijkt me ook niet logisch omdat die voor de 16-bit libraries zijn als ik het goed heb.

[Gonadan]

IK BEN ERUIT!!!!

Dank zij een intiem msn gesprek met Soultaker hebben we de oplossing gevonden.

Het bleek dat ik een HANDLE terug kreeg, via LocalLock(handle) kreeg ik er wel een goede pointer uit en kon de data uit het geheugen lezen. Ik krijg nu foutloos de data terug.

Soultaker!!!!