|
Eddy Vluggen wrote: Simpeler; don't use DevExpress, and try to eliminate any other dependency.
Indeed - the whole app should have been coded with Excel macros! 
Marc
|
|
|
|
|
Sure. Just make sure the version and localization of all Excel installation matches: it's a pain to fix macros that don't work because the commands in the macros themselves are localized ... 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
That's the most absurd design choice I ever saw in all my life. It's a special stupid kind of stupid, the epitome of what could be wrong.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
 Wise words.
It sucks that you have to go through this. 
|
|
|
|
|
You don't have copies of the 3rd party assemblies? Maybe in source control?
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: You don't have copies of the 3rd party assemblies?
I have copies of the assemblies, so I could reference those (except Sandock, not sure how that failed), but I'm worried that if I reference the old DevExpress assemblies without properly registering them at installation, they'll be in trial mode. I didn't try that, but so far, the upgrade from DX 10.1 to 15.3 has worked, though I haven't run the app yet (due to other errors.)
I would really expect though, that having a complete copy of the installer and a text file on the registration keys, that I should just be able to install this stuff.
Online registration sucks, IMO.
Marc
|
|
|
|
|
.NET 2.0? You lucky bastard! 
I've had VB6 legacy projects that worked with libraries that are long gone, and third party tools that have advanced by 10 (non-compatible) versions, written for hardware that can't be bought anymore, not to mention the 80's database (forgot the name)...
Luckily I had a coworker who worked with this sort of stuff almost daily... And liked it (I don't think he learned anything new after 1999 or something, his .NET code was horrible) 
What do you mean this isn't a competition?
|
|
|
|
|
Last fall I was handed an MFC project from the late 90's originally created - by a company that long since went poof (hence why we got the work)- by porting from an even older C/*Nix (probably Solaris) application. One of it's dependencies was for something called the Black Ice Imaging SDK[^]. Once we replaced the include block for all the 15yo headers with an include block for the headers in their newest version (at some point they shuffled where what was exposed); everything just worked. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: everything just worked
You're not supposed to say that. This is a legacy-complain thread 
|
|
|
|
|
What do you think the part where I mentioned MFC was. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I was feeling sorry for you, until you said "everything just worked" (that's where the envy kicked in)
|
|
|
|
|
The codebase as a whole was lots of 'fun' ("our training will make sure the user never tries doing any steps out of order or stop a procedure halfway through in favor of something else", "I fixed all the graphics glitches by stuffing some extra calls to repaint the control, it's all good now") in ways that kept me and a coworker busy fixing stuff for a while; it was just the library upgrade that went smoothly.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
The legacy project I am working on right now is in Core PHP/jquery. No Framework, Just Core PHP.
|
|
|
|
|
Member 10854216 wrote: Just Core PHP.
Sorry man, PHP is awful in all of its forms
|
|
|
|
|
I know 
|
|
|
|
|
Sander Rossel wrote: the 80's database
I remember a few back then, only one relational db though. That was Uniplex. Late 80's. The big ISAM db I saw many places was BTrieve. Then there was the Borland project called Paradox. You know, I'm glad I've stuck with relational databases.
|
|
|
|
|
I think it was some version of dBase. Only once did I actually have to change anything in it, I asked a coworker
Relational is cool, certainly something I know. Not without perks though. I'd like to work with some NoSQL databases sometimes too. Unfortunately, my coworkers are pretty traditional when it comes to databases, Oracle or SQL Server (and preferably Oracle). Nothing is ever better for the job at hand
|
|
|
|
|
The question what other Options do we have? I think we do not have an other Option. Develope each and everting by ourselves... it takes to much time.
I think we have to live with some dependecies, like we depend on MS, Borland and in worst case (from my Point of view) on some open source source.
Bruno
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: I think we do not have an other Option.
Agreed. I wish I all the pieces properly working in my VM!
Marc
|
|
|
|
|
At my second professional development job, my boss said that if we can't get the source and compile it, we don't use it. Since then, I've warned colleagues and companies about this. Most agreed. Some didn't and are now in the same situation.
|
|
|
|
|
Very reasonable. We do just that, but in some cases (specifically the expensive libs, think 5 or 6 digit price tags) we go a slightly different route: we set up a contract that would guarantee us the right to access their source code in the case the third party devs are no longer available, able or willing to maintain their lib. We don't expect this to happen anytime soon, but our application is already 25+ years old, and it might last for another 10+ years easily. So better be safe than sorry.
Of course for versioning it's also a challenge to make sure each version is checked in in such a way that it uses the correct versions of the third party libraries. For those with source code it's easy, for those without, we have a mixed approach of either versioning the binaries (for those that change a lot) or keeping all versions available in separate paths (for those that are mostly stable).
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
How much effort do you put into monitoring the vendors to make sure if they go under that that provision of the contract is actually executed? I could easily see a scenario where:
0) several years pass from when you sign the contract with that extra provision and everyone involved in it leaves the vendor.
1) the vendor goes out of business.
2) the liquidator can't find anyone willing to buy ownership of the library and just formats the source control server obliterating the code.
3) a few more years pass.
4) you have a problem, try to contact the vendor, and discover you're elephanted.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
In our most recent contract that's been taken care of by an escrow who will make sure we get the code when push comes to shove. Sell-outs and liquidation won't change that - whoever buys the company or their assets will have to accept that we will get the code no matter what. (and probably most of the other clients as well).
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
You remembered me back old days when a .NET version changed and I was getting so many assembly errors in Visual Studio that was really annoying. I love Microsoft and backwards compatibility in all their products. 
|
|
|
|
|
Try doing Mac development sometime. Even a three-year-old project would have been built with an older version of Xcode that won't run on any new Mac that comes with the latest version of OS X. Older projects are even more fun, with things like Carbon, HFS paths, and even dependencies on CodeWarrior. Backward compatibility isn't even a concept at Apple.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
