How not to transfer all code to 64 bits

To what it can be unpleasant: there is a 32-bit C ++ library that you have licensed to customers for many years, and now more and more customers want to use it from 64-bit programs. You develop the library, correct errors, refine, cherish and cherish it, it works great, but it’s not so important for customers - they just want 64 bits. They don’t even care if it will be all 64-bit, they just want to use it.
 
What to do? Obviously - rewrite the code so that it compiles into 32 bits and 64:
- we read many articles - for example, this one and those that appear in “similar publications” when it is read;
- Quickly edit the code (they should be managed in a week, right?);
- ???
- PROFIT
 
Now, welcome to the real world.
The code, for example, is two million lines, and the code is complex (all of a sudden), so rewrite it for a long time to come. When you are done, you will have one universal version of the C ++ code, but you will compile it in both 32 and 64 bits, i.e. the executable code will be twice as large.
 
Twice as much code →
→ twice as much testing;
→ twice as much debugging;
→ twice as much escort.
 
It was outlined by WIN, but already looks more like FAIL.
 
Second attempt. We rewrite everything in C #. C # is compiled into a magic bytecode, which then works without problems on a machine of any capacity. WIN?
- C ++ and C # are similar, but still different, so rewriting a lot of code is a very long time;
- you will need to re-profile all the code;
- you will need to re-test the entire code again;
- it’s very difficult to rewrite little by little - until you rewrite everything, you have nothing to license to clients;
- there are still clients who are not comfortable using .NET libraries.
 
Again FAIL. If the above problems did not convince you that rewriting all the code can be too expensive, Captain Evidence ™ reveals the topic of rewriting here (the original ) and partly here .
 
What should I do if you have less capitalization than Microsoft, but you want to make 32-bit code work from 64-bit programs?
 
Try not to rewrite. Try to make friends your 32-bit code with 64-bit code. On Windows, there is COM technology for this - everything necessary for its operation is included directly in the operating system.
 
"What? Yes, COM was old when I was about to go to first grade! ”- the thick troll reader will object in the subject. Actually ... Yes, COM has been around for a very long time. But the wheel was invented much earlier than COM, and still use it. For one reason: the wheel solves the tasks assigned to it. With COM, the same thing is a technology that works.
 
We’ll still have to work a bit:
- design the library interface,
- write a bunch of auxiliary mechanisms (ATL will help a lot here),
- test auxiliary mechanisms ...
 
... "Here, again, inhuman efforts," the reader will object. Yes, at first the development of COM components causes some difficulties, you will have to survive it. But on the way out:
 
- the library can be used from a wide range of languages ​​- C, C ++, C #, VB.NET, Delphi, many scripting languages ​​(and this is an incomplete list);
- you can make a component whose code is executed in a separate process;
- the code itself remains completely 32-bit;
 
“In a separate process? After all, customers will have to take a steam bath - it will be necessary for their program to be able to be friends with the component in another process. ”- the reader will object and will be wrong. COM includes magic (called “marshalling”), which allows a program to invoke component code as if it were being executed in its own process. The client can still write something in the spirit: COM itself: - starts a separate process, - asks it to create an object, - organizes the connection between the client program process and the component process, - provides the client program with an object that, from its point of view, leads yourself as a real COM object. All calls made by the client program will be redirected to that separate process completely transparently.
 
ThatLibrary.Worker worker = new ThatLibrary.WorkerClass();
worker.DoWork();
 





 

 
As usual, there is a _{fine print} . Magic for communication requires overhead, so it makes sense to design the interface so that there are fewer methods, and they do more useful work - then the share of magic in the total time will not bother.
 
There is still an unpleasant moment. The component’s work in a separate process is really needed only for those clients who have 64-bit programs. For customers who have 32-bit programs, this is no use, just the overhead. COM allows you to make a component working in the same process, but again two versions of the component - again more code, more testing, more maintenance.
 
British scientists ™ recently found a solution to this problem. This is COM + - a technology that, among other things, allows you to make a component designed to work in the same process work separately. COM + is available in all versions of Windows, starting with Windows 2000. You make a component to work in the same process and, if necessary, put it in COM + (Start → Settings → Control Panel → Administrative Tools → Component Services, there are a few clicks).
 
The client program works as usual. If the program is 32-bit, the component is created in the same process. If the program is 64-bit, magic is turned on, COM + starts the so-called surrogate process, loads the component into it, organizes marshalling, then the component is used transparently from a separate process.
 
We went this way when (suddenly) realized that the COM component for integration with the Recognition Server cannot be used from 64-bit programs, but it is very necessary. There is not much code there and we could transfer it, but it turned out to be much easier to use COM + to solve this problem. Compare - a lot of not very useful painstaking work or a few clicks of the mouse.
 
It’s not always worth rewriting all 64-bit code just for rewriting. The freed up time can be spent on trolling this post.

Dmitry Meshcheryakov
Recognition Server Development Team Leader