| |
| ▲ | rfoo 6 hours ago | parent [-] | | Until the moment when you are forced to use a third-party SDK with std:: and boost:: (yeah, WTF?) types in the interface. Oh, and you can't avoid that, say, you are working on a trading bot and that's the only "supported" way to connect to an exchange. In the end people usually just reverse engineer and reimplement to get rid of such cursed blob. Fortunately, it works - the vendor can't effectively push all clients to update their SDK too, so all wire protocols are infinitely backward compatible. | | |
| ▲ | gary_0 2 hours ago | parent | next [-] | | The last time I was forced to deal with such a proprietary SDK (that required an ancient Windows C++ runtime, and segfaulted like crazy, natch), rather than waste months reverse-engineering it, I wrapped it in a separate process and talked to it via IPC. That got the job done, and every time their shitty code locked up or crashed, I just restarted the wrapper process from the main application. | |
| ▲ | HelloNurse an hour ago | parent | prev [-] | | For mummified binary dependencies, C# allows tediously fine control over stack frames in DLL function calls, and similar FFI systems are likely to be equally malleable; there's probably a blind spot towards reverse engineering in C++, due to the expectation that a random ABI should "just work". | | |
| ▲ | rfoo 6 minutes ago | parent [-] | | The problem is actually not ABI, it's ODR violation. You can make it work, just make your own wrapper in C ABI, link it with whatever dependency (and version) that your vendor insists on, then `-fvisibility=hidden` and partial link the entire shit to avoid ODR violation. People reverse these SDK partly because it makes the codebase saner, and partly because, well, this is trading, a saner implementation is almost guaranteed to be faster than vendor's bullshit one, and guess who cares about being a little bit faster than everyone else? |
|
|
|
