[C++] CleanCash SC-B .NET COM DLL

[DJMaze]

Ik heb geprobeerd deze DLL te exporteren naar LIB en DEF maar er zitten geen EXPORT regels in.
regsvr32 werkt daarom ook niet.

De handleiding is een summier Microsoft Word doc bestand met simpele functie omschrijvingen als
"FdmResultCode result = _fdmAPI.Open(“COM10”);"
Verder zijn er geen source bestanden meegeleverd, noch een handleiding hoe de RS-232 communicatie verloopt.

Iemand enig idee hoe ik zo'n DLL importeer in een C++ applicatie?

[farlane]

Als het een COM dll is kun je met #import importeren. Maar dan zou regsvr ook werken dus het lijkt er op dat je een aantal dingen dor elkaar haalt.

[DJMaze]

> regsvr32 CcFdmCom.dll

CcFdmCom.dll was loaded, but the DllRegisterServer entry point was not found.
This file can not be registered.

Het lijkt er dus op dat er alleen een class in zit "_fdmAPI" maar ja, hoe kom ik daarbij?

[Verwijderd]

Is dat een Active X DLL? Dan moet je deze eerst omzetten via tlbimp, daarna is deze als reference toe te voegen. Hoe je em vervolgens moet gebruiken moet je aan de maker van de DLL vragen.

Is het niet eenvoudiger om direct via RS232 met het ding te praten, protocol is op te vragen en niet ingewikkeld dacht ik.

[farlane]

DJMaze schreef op vrijdag 11 juli 2014 @ 18:57:
> regsvr32 CcFdmCom.dll
Het lijkt er dus op dat er alleen een class in zit "_fdmAPI" maar ja, hoe kom ik daarbij?

Weet je zeker dat het een COM dll is dan?

[Verwijderd]

Verwijderd schreef op vrijdag 11 juli 2014 @ 19:15:
Is het niet eenvoudiger om direct via RS232 met het ding te praten, protocol is op te vragen en niet ingewikkeld dacht ik.

Lijkt me beste oplossing. Er zijn ook softwaretools om COM poorten te sniffen zodat je ziet wat er over de lijn gaat. 9 van de 10 keer is dat gewoon plain text.

Ik denk overigens dat je COM (Component Object Model) en COM-poort door elkaar haalt, maar dat is een gokje.

[DJMaze]

Verwijderd schreef op vrijdag 11 juli 2014 @ 19:45:
Ik denk overigens dat je COM (Component Object Model) en COM-poort door elkaar haalt, maar dat is een gokje.

De summiere documentatie begint met: "CleanCash SC-B API is a .NET COM DLL for windows which serves for a simplified interface to the CleanCash SC-B units"
Tja, ik heb echt 10x gelezen of ze inderdaad "COM1" of COM bedoelen

Verwijderd schreef op vrijdag 11 juli 2014 @ 19:15:
Is dat een Active X DLL? Dan moet je deze eerst omzetten via tlbimp, daarna is deze als reference toe te voegen. Hoe je em vervolgens moet gebruiken moet je aan de maker van de DLL vragen.

Is het niet eenvoudiger om direct via RS232 met het ding te praten, protocol is op te vragen en niet ingewikkeld dacht ik.

Ik ontwikkel in een VirtualBox dus via een pipe config moet dat wel lukken
Heb alleen niet echt de tijd om alles uit te zoeken, en de Belgische overheid moet het straks goedkeuren en certificeren omdat bedrijven in de horeca sector verplicht per 1 januari 2016 gecertificeerde kassa's moeten gebruiken met een fiscale controle eenheid.

Wil het graag opensource maken zodat de OpenSource POS systemen op Linux (zoals Floreant) hier straks ook profijt van hebben, maar moet ergens beginnen.

Grootste nadeel is dat de CleanCash unit op dit moment de enige op de markt is, die is goedgekeurd door de Belgische overheid.

[ Voor 6% gewijzigd door DJMaze op 11-07-2014 20:50 ]

[Verwijderd]

Klopt, maar van wat ik uit de documentatie bij hun op de website haal is het bij "andere systemen" de bedoeling dat je direct via de RS232 gaat lullen met dat ding. Lijkt me niet dat dat een probleem is, ook niet voor de certificering. Zo lang je maar een gecertificeerde unit gebruikt en die verder niet aanpast.

Ieder POS systeem is anders, dus de certificering zal niet richten op de technische werking daarvan, enkel of de unit die de code voor op de bon maakt niet aangepast is en natuurlijk de juiste code op de bon komt.

Maar is het met tlbimp niet mogelijk de Active-X DLL om te zetten? Ik lees bij hun op de website dat het een Active X DLL is namelijk.

[DJMaze]

tlbimp zit niet in Embarcadero en in de import functie van RAD2010 werkte hij ook niet.
Heb het protocol maar opgevraagd.

Bedankt voor het aangeven van de richting SKRE

[Verwijderd]

Veel succes!

[Tribits]

Mocht het zelf implementeren van het protcol om de een of andere reden toch geen optie zijn dan nog de volgende kanttekeningen met betrekking tot de dll: Als het inderdaad een '.NET COM DLL' dan zou registratie moeten werken met regasm.exe, onderdeel van het .Net framework en daarna dus gewoon als COM object gebruiken. Als regasm met de melding 'RegAsm : warning RA0000 : No types were registered' terugkomt is het kennelijk wel een .Net DLL maar geen COM aware exemplaar. In dat geval is je beste optie om er in Visual C++ (ik maak uit je reacties op dat je zelf C++ builder gebruikt) een wrapper met exports voor te schrijven zodat je de DLL vanuit unmanaged code aan kan roepen. Ik weet niet zeker of dat met een express versie van Visual C++ werkt of dat je daar een volledige versie voor nodig hebt. Als regasm met de melding terugkomt dat het geen .Net dll is dan weet ik het verder ook even niet meer.

[ZaZ]

Gewoon effe met depends spieken. Zie je een entrypoint dllregisterserver en dllunregisterserver dan is het een 'gewone' COM dll die je met regsvr moet kunnen registreren.
Als je ziet dat ie leunt op de MSCOREE.DLL dan is het een .net dll en moet je 'm (elevated!) met regasm registreren.

Ik ben ook wel eens hybride misbaksels tegengekomen die het registratieprocess niet 'onboard' hebben maar de benodigde informatie apart leverden in een typelib. Zitten er nog meer files bij?

[MSalters]

Dependency Walker is inderdaad de correcte eerste stap om een onbekende DLL te reverse-engineeren.

Overigens zul je voor C++ nog een header file moeten hebben die "FdmResultCode" definieert.