I really dislike half assed COM server implementations
-
Well, it's not a server server. It's not like it's serving data, as if it's a web server or anything. It's just Microsoft terminology: the DLL serves COM objects. However, it's practice (should be law!) to clean up properly before the DLL is unloaded. The windows in question are just message-only windows that process WM_TIMER.
-- Kein Mitleid Für Die Mehrheit
Yeah, I know what you mean, but IMO a server only provides services. These, in my opninion, should never involve user feedback. To do so breaks the ;ofic of an architecture. OK, perhaps I am a bit anal with architecture, but if it isnt clean, you have a buggy unstable product that no amount of code fixing can mend. On the other habd of the architecture is right, the product flies. Perhaps it is because I come form a mechanical engineering background and the physical limitations encountered in real world engineering impose a certain logic to the design. Limitations that arent there in SW solutions. So take an engine. Engines DONT have UIs, because thedy are buried under the hood. Instead the takdata fromm, and feed data to, the UI part of the design, the dash and controls. Anyway, I pity you. IMO I would just rewrite the COM dll myself and have done with it. :)
============================== Nothing to say.
-
Please tell me this is a thread that was accidentally moved up from the 90's. :doh: I take it there is no way to get a dll with a proper network api, no UI and no effing timers. :laugh: I hope everyone you work with recognizes that this component is a POS.
Curvature of the Mind now with 3D
Andy Brummer wrote:
Please tell me this is a thread that was accidentally moved up from the 90's.
No, but I reckon this COM dll was a collection of threads that hasnt changed since the 90's. :) But you are bang on. This kind of crap shouldne be around today, there is no excuse. And I bet it is some propriority code thats been knocking around for 10 years or so that some firm is constantly reselling to unsuspecting companies. From what I iunderstand it is running some kind of pin/card hardware. The hardware is probably connected to the seriali port, and this COM dll talks to the HW throuhg the COM port. Jorgen mentioned HDLC, its a basic protocl, I have written SDLC drivers for serial chips, and it is similar. SO it is probably an rts cts framed comms link. The unknown is the data protcol and timing, ie, the data IN the packet. If Jorgen knew that hje could probably write his own dll (doesnt need to be COM, COMN is only usefull when version change and functionality is unstable. If this doesnt change, then a plain old dll is perfectly suitable)
============================== Nothing to say.
-
Unfortunately, the protocol used between the API and PIN terminal, isn't public. If it was, I would have implemented it myself. I *think* it's an HDLC protocol, so it shouldn't be all that hard to reverse engineer. However, I don't think the PCI mob (https://www.pcisecuritystandards.org/[^]) would clear me for EMV status...
-- Kein Mitleid Für Die Mehrheit
Hmm. What is the OS? And since it is HDLC I bet the hardware conects to the PC via a COM port? It *could* be possible to put a kernel filter driver in the device stack and dump all the data passed back and forweards to dbgview, and thuis determine the actual data protocol (ie the packets inside the HDLC (probably rts cts) frame). Problem is that serial.sys is still a monolithic driver even on later (WDM compliant) Windoes OSs, and you need a layerd (WDM) type serial driver to be able to add a filter to the stack. Of course you could take the source code for serial.sys from the DDK, yes, it really IS the source code for the one that ships with the OS, and modify it and run that over your hardware. You can then dump data direct from the driver. Of course it is better to get the protocol off the firm that sold you the hardware and COM dll. But unless you threaten to go to another firm its unlikely. You could also of course ask them for their source code so you can fix it properly. :) They might go for it...
============================== Nothing to say.
-
Hmm. What is the OS? And since it is HDLC I bet the hardware conects to the PC via a COM port? It *could* be possible to put a kernel filter driver in the device stack and dump all the data passed back and forweards to dbgview, and thuis determine the actual data protocol (ie the packets inside the HDLC (probably rts cts) frame). Problem is that serial.sys is still a monolithic driver even on later (WDM compliant) Windoes OSs, and you need a layerd (WDM) type serial driver to be able to add a filter to the stack. Of course you could take the source code for serial.sys from the DDK, yes, it really IS the source code for the one that ships with the OS, and modify it and run that over your hardware. You can then dump data direct from the driver. Of course it is better to get the protocol off the firm that sold you the hardware and COM dll. But unless you threaten to go to another firm its unlikely. You could also of course ask them for their source code so you can fix it properly. :) They might go for it...
============================== Nothing to say.
Mostly, the HDLC is implemented over TCP/IP. There is support for serial ports, but it's a hassle. The PIN-terminal must be connected to the Internet anyway, because it sends transactions to the bank that way. Did I mention that the API works even worse when using serial communication? It crashes within seconds. :-D The problem with communication with the PIN-terminal directly requires us to go through certification programs, in order to get EMV status[^]. That would put us through PCI-DSS hell, and, well, that's enough to drive any business into the ground. When using an API, we only have to submit a declaration of conformance for PA-DSS. A tedious job, but doable. If I had unlimited time and resources, it would probably be fun, but I don't. As for sniffing a COM-port, you really don't have to go through all the kernel hacking stuff! com0com[^] would make it really easy to insert a "virtual break out box" between two serial end points. Although, it's more manly to hack in kernel mode...
-- Kein Mitleid Für Die Mehrheit
-
Mostly, the HDLC is implemented over TCP/IP. There is support for serial ports, but it's a hassle. The PIN-terminal must be connected to the Internet anyway, because it sends transactions to the bank that way. Did I mention that the API works even worse when using serial communication? It crashes within seconds. :-D The problem with communication with the PIN-terminal directly requires us to go through certification programs, in order to get EMV status[^]. That would put us through PCI-DSS hell, and, well, that's enough to drive any business into the ground. When using an API, we only have to submit a declaration of conformance for PA-DSS. A tedious job, but doable. If I had unlimited time and resources, it would probably be fun, but I don't. As for sniffing a COM-port, you really don't have to go through all the kernel hacking stuff! com0com[^] would make it really easy to insert a "virtual break out box" between two serial end points. Although, it's more manly to hack in kernel mode...
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
the HDLC is implemented over TCP/IP.
:wtf: So they had this old SW that used COM ports, then hacked it to run over an ethernet link! :laugh: Holy crap. HDLC is a hardware transmission protocol. Cts/Rts framed. With TCP/IP/Ethernet the hardware framing is done for you already and the data sent can be any old thing. :)
Jörgen Sigvardsson wrote:
Did I mention that the API works even worse when using serial communication? It crashes within seconds.
So it is getting better then.... :laugh:
Jörgen Sigvardsson wrote:
As for sniffing a COM-port, you really don't have to go through all the kernel hacking stuff! com0com[^] would make it really easy to insert a "virtual break out box" between two serial end points. Although, it's more manly to hack in kernel mode...
Well, now I know it is TCP traffic you can sniff the data with Etherreal. Then, you can just open a TCP port on the relevant IP address and send that data direct form you app. Easy! :) And yeah, the kernel is WAY more manly! :cool:
============================== Nothing to say.
-
I did try once to push it out of proc, but it just went crazy. I don't want to mess with that again! It seemed to work alright, but for some reason, the internal threads the COM object created just wouldn't die. I didn't believe my eyes when I observed it in the debugger. Dr Jekyll and Mr Hyde comes to mind...
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
the internal threads the COM object created just wouldn't die
I've seen this before, and it normally means the reference counting is screwed up. In other words, there's a whole hunka memory leaking going on in there.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
I am going to fight another battle tonight, to try to ward off ill behaving inproc COM servers. In all likelihood, the war will not be over. I dont't know how many times I have had to put up with this shit. :mad: My users see my app crash, so I'm the bad guy. I really don't like that... Wish me luck!
-- Kein Mitleid Für Die Mehrheit
I feel your pain. I've been going through the same crappola over the last month or so as well. They didn't call it COM hell for nothing, you know. :doh:
I wasn't, now I am, then I won't be anymore.
-
Jörgen Sigvardsson wrote:
the internal threads the COM object created just wouldn't die
I've seen this before, and it normally means the reference counting is screwed up. In other words, there's a whole hunka memory leaking going on in there.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
It is weird though, because when you run it in-proc, the server is unloaded quicker than lightning as soon as you release the last reference. Running a COM server as out-proc that was intended to be run in-proc, is a hack. I can't blame them for it not working properly. But hey, desperate times call for desperate measures!
-- Kein Mitleid Für Die Mehrheit
-
I feel your pain. I've been going through the same crappola over the last month or so as well. They didn't call it COM hell for nothing, you know. :doh:
I wasn't, now I am, then I won't be anymore.
When done right, COM is nice. I don't fear the low level nature of it. I fear situations where they put a Delphi programmer on the task, because those development environments are so far removed from the complexities of COM. You can't expect a Delphi programmer to hack it. It's like asking a .NET guy to do great work with J2EE - it can be done, but I wouldn't recommend it if the app is to be shipped in a short time frame, or if the development team is one person.
-- Kein Mitleid Für Die Mehrheit
-
I am going to fight another battle tonight, to try to ward off ill behaving inproc COM servers. In all likelihood, the war will not be over. I dont't know how many times I have had to put up with this shit. :mad: My users see my app crash, so I'm the bad guy. I really don't like that... Wish me luck!
-- Kein Mitleid Für Die Mehrheit
Problem solved. Bypassed the Co* layer, to instantiatie the object myself. This gives me full control of the DLL lifetime. Also made the developer fix the bugs in his implementation (I will probably find new ones next week, so don't worry - I'll still have a job to do). Push to customers on monday morning. Weekend saved! Have a good one!
-- Kein Mitleid Für Die Mehrheit