Three main things:
- memory space for printers and sound cards changed in Vista, so when you have some constellation of printers and you change the printer in dialog whole program just crash, because it is trying to touch restricted memory or something.
- running Paradox in network is quite difficult. Whole database was written in 80s before things like tcp/ip was thought as a good thing and all the networking part was hacked inside and it shows. Because of weird architectural choices made 20+ years ago I am not able to migrate out to sane database without rewriting whole application. (250+k lines of code)
- BDE could be quite unstable in various scenarios and you spend quite a lot of time fiddling with memory space, memory size and other variables to make it work.
Thanks for the explanation. A lot of my code is getting old (just like me), but I was lucky in that it was designed from the start to be cross platform. This ended up meaning that it was written in C and all the platform specific code was kept as separate modules.
My big problem is I have so many code paths that I can’t fully test the interactions between the different modules and functions (there are over 10^25 different possible paths). I am not sure what can be done about this given the functionality of the software is critically dependent on this flexibility. The best I have been able to come up with is testing 99.99% of the most popular paths and building in a lot of error recovery code.
>My big problem is I have so many code paths that I can’t fully test the interactions between the different modules and functions (there are over 10^25 different possible paths).
Interesting. Have you considered the pros and cons of writing a custom fuzzer for your app, and whether it may help?
I actually have written a custom fuzzer. It has been really useful in chasing out bugs caused by improper handling of corrupt files, but fuzzing won't help solve the combinatorial coverage problem.
But don't all those paths depend on the inputs, ultimately? Trying to understand this here. Can a fuzzer that generates lots of different inputs, not be used to exercise all those paths?
Three main things: - memory space for printers and sound cards changed in Vista, so when you have some constellation of printers and you change the printer in dialog whole program just crash, because it is trying to touch restricted memory or something.
Can this functionality be separated out into a different process, or called from a DLL compiled using Visual Studio?
Probably not: the application has around 100 printouts (with tons of spaghetti logic behind it making it impossible to count all variations) and it will be very hard to switch to new reporting framework.
The big problem with legacy software without huge user base and limited space for growth is that it just don't make sense to invest huge amount of time and money in it.
This is funny. I saw the same pattern in Smalltalk apps: Reports being the locus of spaghetti code.
Reports are added as an afterthought. Then the resulting spaghetti code patterns are replicated cut & paste, where they then slowly melt into surrounding code in a way that makes them impossible to extricate. After some years, it then becomes obvious that reports are the primary driver of value for those clients.
Yeah, I tried to migrate out of that mess into other tools and it ends up as even bigger mess. Now I do have three different reporting systems in three different technologies (QuickReports in Delphi, code that generate HTML code from inside Delphi code and then XQuery based declarative code that can be customised by (/for) customer) and I ended up in even deeper hole.
6 mb for typical binary, but there are around 10 different exe files compiled from this codebase, most of them overlaping and sharing big portion of functionality.
- running Paradox in network is quite difficult. Whole database was written in 80s before things like tcp/ip was thought as a good thing and all the networking part was hacked inside and it shows. Because of weird architectural choices made 20+ years ago I am not able to migrate out to sane database without rewriting whole application. (250+k lines of code)
- BDE could be quite unstable in various scenarios and you spend quite a lot of time fiddling with memory space, memory size and other variables to make it work.