views:

104

answers:

5

I have an application which has many services and one UI module. All these are developed in VC++ 6.0. The total KLOC would be 560 KLOC.

It uses Mutltithreading,MFC and all datatypes like word,int, long.

Now we need to support 64bit OS. What would be the changes we would need to make to the product.

By support i mean both like running the application on a 64bit OS and also making use of the 64bit memory.

Edit: I am ruling out migration to VS2005 or anything higher than VC6.0 due to time constraints.

So what changes need to be done.

+5  A: 
Richard
The other common one is plugins: if, for example, you want to add an explorer extension then that will need to match the OS bitness too.
Rup
Actually, it will need to match the bit-ness of the host process. For instance, 64 bits windows comes with both 32 and 64 bits versions of IE. You would need matching plugins as well.
MSalters
There's also shell extensions...
rubenvb
Apps that use the modem control panel won't "just work" (she says, from bitter experience).
Vicky
+4  A: 

As Richard says, the 32-bit version should continue to work unless you've got a driver or a shell extension or something.

However if you do need to upgrade the code you're going to have to upgrade the compiler too: I don't think MFC got good 64-bit support until VS2005 or later. I'd suggest you get the 32-bit code building in VS2010 - this will not be trivial - and then start thinking about converting it to 64-bit. You can of course leave the production 32-bit builds in VC6 but then you add maintainership burden.

You'll probably get most of the way converting by flipping the compiler to 64-bit and turning on full warnings - particularly given the size of your code it may be impractical to review it all. One thing to watch out for is storing pointers in ints, dwords, etc. which may now be too short to hold the pointer - you need DWORD_PTR etc. now - but I think the warnings do catch that.

Or if this is in many components then you might get away with only migrating a few components to 64-bit. Then, unfortunately, you've got data length issues for communication between the two versions.

Rup
+1  A: 

If you're ruling out changing your IDE to one that intrinsically supports 64-bit compiling and debugging, you're making your job unnecessarily more complex. Are you sure it's not worth the hit?

Dan Puzey
I understand your concern but my Manager is the one who has to take the call depending on schedule and resource constraints.
ckv
I think you'll have to, though, to get 64-bit MFC support - if not the 64-bit compiler itself.
Rup
Then I'd suggest you need to convince your manager that developing 64-bit support in an IDE that doesn't have the same is going to cost you more time and resource than the alternative!
Dan Puzey
+2  A: 

You must convert to a newer compiler. Time constraints are pretty much irrelevant. The VC6 compiler simply cannot generate 64 bits code. Every pointer it generates is 32 bits, for starters. If you need to access "64 bit memory", i.e. memory above 0x00000000FFFFFFFF, then 32 bits is simply not enough.

MSalters
A: 

Just for running on a 64bit OS, you won't need to make any changes. That's what WOW64 is for.

If, however, you want to run 64bit natively (i.e., access the 64bit memory space) you will have to compile as 64bit. That means using an IDE that supports 64bit. There is no way around this.

Most programs should have no problem converting to 64bit if they are written with decent coding standards (mainly, no assumptions about the size of a pointer, like int-pointer conversions). You'll get a lot of warnings about things like std::size_t conversions, but they will be fairly meaningless.

DeadMG