I really dislike half assed COM server implementations
-
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 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
-
Jörgen Sigvardsson wrote:
My users see my app crash
Cant you exception protect a call to an inproc server and reload it on failure?
============================== Nothing to say.
That depends on whether or not the server makes calls back into you. You can certainly wrap your calls into the server with exception handling. However, if the server is running in its own thread and crashes you're SOL. You'd have to run the server in its own process and make out-of-proc calls between your process and the child process. Not fun, but doable.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Jörgen Sigvardsson wrote:
My users see my app crash
Cant you exception protect a call to an inproc server and reload it on failure?
============================== Nothing to say.
The problem is that the COM server creates windows with associated WndProcs. Windows outlive the DLL. I think the server doesn't kill its window timers. The dispatch of a WM_TIMER causes a call to a WndProc located in the memory range were the DLL used to be. I am hesitant to catch exceptions in my message pump. I will attempt loading the DLL manually, and create the COM object manually instead of going through the Co* layer. The biggest problem is that the server also leaks HWNDs. Sometimes you get weird message boxes from the server's delphi runtime that it can't create timer windows. That I can take, because the window title identifies the third party software, and it doesn't crash my app. This isn't my first battle with the server, and I doubt it will be the last. I will however create a proxy process for this shit once I get time to do it.
-- Kein Mitleid Für Die Mehrheit
-
Jörgen Sigvardsson wrote:
My users see my app crash
Cant you exception protect a call to an inproc server and reload it on failure?
============================== Nothing to say.
My earlier battles with the server includes faulty behavior (not according to specifications) and resetting the FPU control word (making the MS C++ runtime go bonkers when you deal with floating point numbers). Also, I can't just reload the component, because it has state. The component deals with credit card transactions... I just don't want to mess with it too much. :)
-- Kein Mitleid Für Die Mehrheit
-
The problem is that the COM server creates windows with associated WndProcs. Windows outlive the DLL. I think the server doesn't kill its window timers. The dispatch of a WM_TIMER causes a call to a WndProc located in the memory range were the DLL used to be. I am hesitant to catch exceptions in my message pump. I will attempt loading the DLL manually, and create the COM object manually instead of going through the Co* layer. The biggest problem is that the server also leaks HWNDs. Sometimes you get weird message boxes from the server's delphi runtime that it can't create timer windows. That I can take, because the window title identifies the third party software, and it doesn't crash my app. This isn't my first battle with the server, and I doubt it will be the last. I will however create a proxy process for this shit once I get time to do it.
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
The problem is that the COM server creates windows with associated WndProcs
:omg: :wtf: :omg: :wtf: :omg: What sort of freaking architectutre is that! I mean, isnt rule 1 that servers dont pop windows?
============================== Nothing to say.
-
That depends on whether or not the server makes calls back into you. You can certainly wrap your calls into the server with exception handling. However, if the server is running in its own thread and crashes you're SOL. You'd have to run the server in its own process and make out-of-proc calls between your process and the child process. Not fun, but doable.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von BraunIsnt there an exe wrapper for COM dlls (in proc servers) that makes them out of proc servers? I dont know if thats what you are refering too, i havent any experience with doing that, so if it is as painfull as you say then it looks like Mr Sigvardsen is just plain fucked. :)
============================== Nothing to say.
-
My earlier battles with the server includes faulty behavior (not according to specifications) and resetting the FPU control word (making the MS C++ runtime go bonkers when you deal with floating point numbers). Also, I can't just reload the component, because it has state. The component deals with credit card transactions... I just don't want to mess with it too much. :)
-- Kein Mitleid Für Die Mehrheit
-
Isnt there an exe wrapper for COM dlls (in proc servers) that makes them out of proc servers? I dont know if thats what you are refering too, i havent any experience with doing that, so if it is as painfull as you say then it looks like Mr Sigvardsen is just plain fucked. :)
============================== Nothing to say.
I believe you may be correct. But I don't recall the details.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Jörgen Sigvardsson wrote:
The problem is that the COM server creates windows with associated WndProcs
:omg: :wtf: :omg: :wtf: :omg: What sort of freaking architectutre is that! I mean, isnt rule 1 that servers dont pop windows?
============================== Nothing to say.
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
-
Isnt there an exe wrapper for COM dlls (in proc servers) that makes them out of proc servers? I dont know if thats what you are refering too, i havent any experience with doing that, so if it is as painfull as you say then it looks like Mr Sigvardsen is just plain fucked. :)
============================== 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:
Also, I can't just reload the component, because it has state
Oh no! It gets worse!
============================== 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
-
My earlier battles with the server includes faulty behavior (not according to specifications) and resetting the FPU control word (making the MS C++ runtime go bonkers when you deal with floating point numbers). Also, I can't just reload the component, because it has state. The component deals with credit card transactions... I just don't want to mess with it too much. :)
-- Kein Mitleid Für Die Mehrheit
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
-
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.