I'm working with an old (Delphi 2010) app with a number of very specific components that have to be installed, some from compiled from sources. It's a pain to set up, is what I'm getting at.
Currently, I have it on a Windows 10 machine, but I haven't upgraded Windows 10 in quite some time. If I upgrade Windows, it breaks the debugger (and I haven't been able to fix that so I've downgraded Windows).
I'm trying to find any way to move the Delphi environment without having to go through the various steps to get it to work, like making a VM out of it. Or, if I have to go through the steps again, only do it one more time in such a way that I can push-button recreate it. (There are a lot of things I need to try to upgrade the app itself, but many of those strategies will break the environment for me.)
Any strategies?
Related
Recently lost my hard drive where I had WAMP installed and Imagick working.
Someone else did that part for me way back.
Reinstalling Win7 and getting everything working again = nightmare.
So I installed the latest version of WAMP - NO Imagick.
3 days of trying all the solutions on this site (and some others - sorry) and got nowhere.
Does anyone know of a "one shot" installation that will work out the box?
Maybe a fork of one of them - I looked but found nothing
Or maybe I should install Ubuntu onto an old PC and use that as a web server on my home LAN?
Seriously - they are depreciating the GD library some time soon and Imagick is apparently the successor but no-one supports Imagick natively.
Jumping through all sorts of hoops is no guarantee that it will work either as I have painfully found out.
Thanks in advance people.
WAMP and XAMPP are not up to speed with the transition from the soon to be removed GD library to the ImageMagic library and it would seem that neither are planning to bring their products up to date any time soon.
That leaves many users with a major problem as most web site developers need to be able to manipulate images at some time or another during their work.
For users who are not at a reasonably high level of expertize as far as messing around in the guts of the (in my case, Windows) operating systems, this is a nightmare and can be downright dangerous.
I did find what seemed to be a viable alternative in WampDeveloper Pro but unless you specifically go looking for it, their website is very hush-hush about the fact that its going to cost you over $125 to get it working.
You only find out about this at the first run after installing.
So my options are the following:
Put one of the Ubuntu distributions on a VM
or
Find an old drive, install it into your PC and make the PC dual boot using a Ubuntu distribution.
The second option will "ease" me into converting from Microsoft based OS reliance to a Linux based OS however if that does not work out, I do have the option to create an Ubuntu VM under the Windows system (I have used VM for a while under Windows) and use that in place of the other Windows based web server alternatives.
Either way I will be able to carry on servicing my clients and making a living without spending money or having a stroke due to pure frustration.
I may regret this decision BUT I may start wondering to myself "Now why did you wait so long?"
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
Greetings,
I feel kinda stupid for asking this, but I want to set the windows sdk build environment so that any process (including some non MS developer tools) can access the correct setup, without me trying to inject setenv.cmd /x86 into every process's startup.
I can't seem to find the right search terms for this, and I don't want to hand pick various exes and dirs to include them in the path.
Is there a way to make setenv.cmd effect the whole windows environment? (xp)
Best Regards
Seref
It isn't impossible, you could use Control Panel + System and add the environment variables set by the .cmd file. Doing so has several troublesome consequences though:
the build tools will only work on your machine, you'll have a hard time getting a build going on your colleagues' machine or a build server. Especially since you no longer try to keep it compatible.
you'll have a very hard time switching between a debug and release build or a x86 and a x64 build
you'll have a very hard time when you start using a new release of the SDK, especially when you temporarily need to switch back and forth between the old and the new release.
I'm pretty sure you'll deeply regret doing this, eventually.
As a guy who frequently switches between QA, build and operations, I keep running into the issue of what to do about operating system updates on the build server. The dichotomy is the same on Windows, Linux, MacOS or any other o/s that can update itself via the internet:
The QA team wants to keep the build server exactly as it is from the beginning of the product release cycle to the end, since installing updates could destabilize the server and means that successive builds aren't made against the same baseline.
The ops team wants the software to be deployed on a system with all the latest security patches; this can mean that the software isn't deployed on exactly the same version of the o/s that it was built on.
I usually mitigate this by taking release candidate builds and installing them on a test server that has a completely up-to-date o/s, repeating the automated tests that are run on the build server and doing some additional system level testing to make sure everything looks good before deployment. However, this seems inefficient to me; does anyone have a better way ?
Personally i don't think you have much of an issue here - just apply the latest updates to the build server. The main reasons i say this are:
it is highly unlikely that your code or any of the dependencies on the build server are so tightly coupled to the OS version that installing regular updates is going to affect anything, let alone break it. There can be minor differences between window messages etc between Windows versions, but those are few and far between, and are usually quite well documented out there on teh interweb. If you are using managed technology stacks like WPF/Silverlight or ASP.Net and even mostly Winforms then you will be isolated from these changes - they should only affect you if you are doing hardcore stuff using the WinAPI directly to create your windows or draw your buttons.
it is a good practice to always engineer your product against the latest version of the OS, because you need to encourage your customer to implement those updates too - IOW you should not be in a position where you have to say to your client to not install update xyz because your application will not run against it - especially if that update is a critical security update
testing for differences between OS versions should be done by the QA team and should independant of what is on the build server
you do not want your build server to get in to such a state that it has been so isolated from the company update process that when you finally do apply them all it barfs and spits molten silicon everywhere. IOW, the longer you wait to update, the higher the risk of something going wrong and doing so catastrophically. Small and frequent/incremental updates are lower risk than mass updates once per decade :)
The build server updates that you do have to be cautious about are third party controls or library updates - they can frequently contain breaking changes or considerably altered behavior. They really should be scheduled, and followed up by a round of testing looking for any changes.
Virtualize!
Using stuff like VMWare Server you can script the launch and suspend of virtual machines. So you can script VM resume, SSH to launch build, copy, VM suspend, repeat. (I say this, but I abandoned my work on this. Still, I was making progress at the time.)
Also, you can trust your OS vendors. Can't you?
They have an interest in compatibility. If you build on Windows XP it is almost certain to work on XP SP3 and Vista and Windows 7.
If you build on RedHat Enterprise 5, it had better work on 5.1, 5.2, 5.3, 5.4, etc.
In my experience this has worked out OK so far for me and I recommend building on your lowest patch OS versions. With the Linux stuff in particular I have found newer releases linking to more recent libraries not available on older versions.
Of course it doesn't hurt to test your code on a copy of the deployment server. It all depends on how certain you want to be.
Take the build server off the network, that way you do not need to worry about installing security updates. Only load the source from CD, thumb drive or whatever other means.
Plug it back in at the end of your release cycle and then let all the updates take place.
Well, for the most stable process, I would have two build servers, "Build with Initial config, Build with update config", and two autotest test servers with similar differences. Use virtualization to do this effectively and scriptably.
This week I’m going to try and start the move from Windows XP to Windows 7 on my development PC at work. I’ve downloaded the Windows Easy Transfer app for going from XP to Win7; that should take care of My Documents. My concern is all of the development environment. In particular I’m concerned about re-establishing things like my Windows services, which host my WCG services, etc. They use TCP and various ports. Plus there are the various ASP.NET apps that are on my machine. What caveats should I be aware of, before I start this?
I deeply don't recommend you to migrate. If I were you, I'd backup these files, format the PC, reinstall everything back again and re-set up the websites. No matter how much pain that may cause, it's still less pain then the potential one you might get if you use this migration tool rather than doing it properly, which would eventually cause you to do the right way anyway.