32 to 64 bit - a general question on how to handle old technologies

Forums › IT Pro and developers › 32 to 64 bit - a general question on how to handle old technologies

jim.cox

224 posts

Master Geek
+1 received by user: 17

#233812 4-May-2018 05:42

Kia ora,

I have been asked to take a legacy 32bit windows application to 64bit.

There are over 25k lines of code, and a twenty year history, so it is not a trivial task.

So far it has gone well, we do have a working and running framework.

However we have run into three small issues with some 'old technology'.

One issue is that we were using DAO for a couple of database import/export functions - no real problem to just leave these functions out of the 64bit build, at least for now

But the program also uses two OCX components. The components we have are 32bit, and so not compatible with 64bit. I have had a quick look for possible replacements, nothing found as yet.

So, as a general question of technique, how do you good folks handle this sort of issue? Find replacements? Re-engineer from scratch?

Cheers

=mjc=
.

nathan

5695 posts

Uber Geek
+1 received by user: 1630
Inactive user

#2007948 4-May-2018 16:02

I don’t have the answer, but curious to know what the driver is to refactor it for 64bit is please?

It’s not like a 16bit app that won’t even run on a 64bit OS

jim.cox

224 posts

Master Geek
+1 received by user: 17

#2008301 5-May-2018 07:21

nathan: I don’t have the answer, but curious to know what the driver is to refactor it for 64bit is please?

The reason for the move is to be able to integrate with another software package (we do traffic flow modelling, they do traffic light timing) and their API is 64 bit.

=mjc=
.

andrewNZ

2487 posts

Uber Geek
+1 received by user: 1461
Inactive user

#2008304 5-May-2018 07:34

Would it not be easier to create a new bit of software to interface the two.

Surely a lot less work and easier to create replacements for different systems.

kingdragonfly

11984 posts

Uber Geek
+1 received by user: 12867

Subscriber

#2008336 5-May-2018 10:13

OCX is going to be a problem. You're correct in that there's no upgrade path.

You're in between the proverbial rock-and-hard place. I hope it's not a fixed price contract.

You'll have to rewrite those, or buy and adapt a third party equivalent.

I would also do away with DAO. ADO is the equivalent low-level database functions.

nova

260 posts

Ultimate Geek
+1 received by user: 143

Trusted

#2008407 5-May-2018 14:11

andrewNZ: Would it not be easier to create a new bit of software to interface the two.

I would strongly consider this approach as well. You could keep your existing 32bit code and run it in one process, and spin up a new 64bit process for the new library that you want to integrate. You would then create the communication betwen the two using a socket, a named piped or one of the other IPC mechanisms that windows supports. Or you could take it a bit further and create a web service API for the new library.

kingdragonfly

11984 posts

Uber Geek
+1 received by user: 12867

Subscriber

#2008448 5-May-2018 15:22

OCX was typically pre-DotNet, and almost always acts like a visual component, like a textbox or pull-down list.

So creating a 32 bit process to host it is probably not going to do it.

If the customer wants to keep the software around, they need to pay to keep it supportable.

It's not going to get better with age.

Dell

Shop now for Dell laptops and other devices (affiliate link).

nova

260 posts

Ultimate Geek
+1 received by user: 143

Trusted

#2008514 5-May-2018 18:31

kingdragonfly: OCX was typically pre-DotNet, and almost always acts like a visual component, like a textbox or pull-down list.

So creating a 32 bit process to host it is probably not going to do it.

If the customer wants to keep the software around, they need to pay to keep it supportable.

It's not going to get better with age.

They already had a working 32 bit application before they started the exercise, which included the OCX controls. So one approach would have been to create a new 64 bit process to wrap the new libraries they wanted to use, and extend the 32 bit app to talk to it.

But they probably are already committed to the ugrading the whole thing to 64 bit, in which case they will need to replace those OCX controls with something else. This will possibly take quite a bit of effort, but will ultimately leave them with something that is much easier to support going forward.

elpenguino

3576 posts

Uber Geek
+1 received by user: 2938

#2009589 7-May-2018 20:45

Sounds like you're building for Windows if you're using ocx.

If there's something you need to do, the modern frameworks can do it. What do these ocx do ?

Do you have to migrate languages too?

Most of the posters in this thread are just like chimpanzees on MDMA, full of feelings of bonhomie, joy, and optimism. Fred99 8/4/21