For reasons related to customers with different applications versions i need to maintain in my laptop several versions of Delphi (7, XE 7, XE 8, XE 10.1 Berlin and XE 10.2 Tokyo). My main concern is about PATH variable and problems during compilation and linking time. There'll be any problems ? Do i need to change what ? Any suggestion is most welcome.
I have all versions of Delphi from 7 thru XE8 installed in a single VM and versions 1 thru 6 in another (my Delphi "museum" :)).
The Delphi "museum" is a Windows XP VM to avoid the problems that those older versions of Delphi have with more recent Windows versions. The Delphi 7+ VM started life as Windows 7 VM but has since been upgraded to Windows 8.x and then Windows 10 without any problem.
The two sets of VM's are kept separate in this way to avoid OS complications with those older versions and because I use 1-6 only very, very rarely and version 7+ more often. The precise version at which the "cut-off" was made was determined by the fact that dotted unit names were also only supported from version 7 onward so a lot of the code I ever wrote for 7+ is simply not even usable with 1-6 so there's no point having them alongside each other.
In both cases the IDE/compilers (any version) have no intrinsic problems running alongside other versions.
The only real difficulty is installing Delphi 2006 on Windows Vista (or later). Should you ever need to, this is the only one that presents any real difficulty due to a dependency on .NET which is not handled very well by the installer. But it is do-able and not especially difficult as long as you follow the steps described in detail by Dr. Bob.
Install Locations: Minimising PATH Length/Manageability
With a large number of Delphi versions installed the overall length of the PATH variable can become a problem, but in my experience this is a problem only of manageability. To simplify things on that score and to avoid problems with earlier versions of Delphi on more recent versions of Windows, I installed all my IDE's in a sub-folder directly off the root:
c:\delphi\<version>
Where version is each Delphi version number (e.g. 7.0, 2007, 2009, XE, XE2 etc etc). I then have a number of other folders for shared components:
c:\delphi\bde
c:\delphi\database desktop
c:\delphi\shared files
When I setup the VM I installed each Delphi version in order and changed the installation locations for these components to these locations. In this way there is one common installation of these shared components which is updated by each more recent version as required.
I also have a c:\delphi\common\ folder where I keep things such as pre-compiled FastMM_FullDebugMode.dll etc to be shared across all Delphi versions.
I did all this primarily for my own benefit however, to keep things organised and consistent rather than to solve any particular problem (apart from the previously mentioned issues affecting older versions if installed under Program Files).
e.g. if you simply install into default locations then you will end up with versions "scattered" across Borland, CodeGear and Embarcadero folders. All my IDE versions are in one place.
With or without these considerations, the IDE should be perfectly happy to run all the different versions you mention without any particular configuration required, but you may need to pay attention to configuration/assumptions made by some 3rd party packages/libraries.
3rd Party Packages
Most 3rd party libraries/packages are usually fine, but there may be the occasional one that needs a bit of help. I myself have never come across anything that couldn't be resolved but have to say that I also don't use 3rd party libraries particularly extensively so simply may not have come across any "trouble makers".
In any event, it's unfortunately difficult to give general advice on this point since it obviously depends very much on the 3rd party libraries and the particular "problems" that any particular one might have.
I have all Delphi versions from 6 to 10.2 installed on a computer running Windows 8.1 64 bit. It's not easy to setup, especially for the older versions. The first rule would be: Do not install to "c:\program files", use a separate directory (I use "c:\delphi" with a numerical subdirectory for each version.)
That has two effects:
Older versions, that still write to the installation directory, will work.
The path entries will not be as long (even though, they will be too long after the 5th or 6th Delphi install, see the comments to your question for possible solutions)
Why did I not use multiple VMs? I maintain GExperts for the versions mentioned above and it is too much hassle to maintain the VMs. As long as it works, I will keep all Delphi versions on my computer. If it stops working, I will probably drop GExperts suppport for some Delphi versions.
There are multiple articles on getting older Delphi versions to work on Windows 8.1. They might be useful if you try it.
They are all in the category Windows 8.1:
https://blog.dummzeuch.de/category/windows/windows-8-1/
Related
I've been debating whether or not to bundle a JRE with my application. I've listed some reasons below why I think it would be useful, but I'm also hesitant to do this because it makes the app much larger.
Why I think it would be useful:
Right now the app is run by running a batch file (well, a shortcut to a batch file, it is run via a batch file). It just calls java -jar XXX, which requires Java to be in the path, which is not always the case.
We're a small team and not fully running on Java 7 (there are some strange errors we are trying to debug still). If a user has Java 7, they may have an unpleasant software experience - this is not good for us. Packaging a specific version of the JRE ensure we've fully tested on it.
We support 32 and 64 bit Windows platforms. When the user downloads the software, they choose 32 or 64-bit, but this is asking which version of Java are they using. Most users don't know if 32-bit java is installed on their 64-bit platform, and it can be confusing to download 32-bit even though their OS is 64-bit.
There are some good reasons why not to package it though:
If a security hole is in Java or other significant updates are made to the JRE, we need to distribute a new version of our app with a new Java version. We are generally updating our app every couple of weeks, so I'm not too concerned about this one right now.
The app will now be much larger because it includes a packaged JRE.
Can anyone provide some guidance as to whether or not (based on these requirements) they think it is a good idea to package the JRE? If not, what are some alternatives to just hoping that java is in the path (and more importantly if it's not, it is possible our users may not know how to add it).
Java Web Start. The JRE will be on the path.
For version control, see Java Web Start - Runtime Versioning & particularly Earlier Version.
JWS can partition resources between a 64 bit & 32 bit JRE.
So, 'bad idea to bundle JRE'. Use web-start instead.
I would suggest to NOT bundle the JRE although I often see it as a common practice.
Instead I would either use webstart (can be used offline as well) or some other installer or pacakge manager solution that ensures that Java is installed including the correct version. This will widely depend on the operating system you expect to run on.
Going down the way of including Java begs the question what else you want to include, just to be sure... which will lead you to the whole operating system and everything needed thought to the end.
I would also suggest to closely look into what types of users will install the app and adapt to that and make some sort of estimate on how capable they will be.
I've got an old VB4 app I want to look at to convert/re-write into something maintainable.
I have the source, but of course, nothing to compile it with, and VS2010 doesn't like the vbp and won't open it.
Although it installs, it won't run - failing with an out of memory error. I want to try an updated version of Jet 3.0, but I can't seem to get the files referenced in this link http://support.microsoft.com/kb/q151186/
So a few questions:
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to view the forms, designers, etc to convert the app?
1) If at all possible move to Jet 4.0/DAO 3.6 as they have been included in every version of Windows since Windows 2000. It's not worth your while trying to use an older version of Jet with all the install problems you will likely encounter. You might have a few syntax changes to make but I doubt they will be that severe.
2) I have no idea about how good or bad the upgrade path is from VB3 to newer versions of VB. If you don't get an answer here the real long time VB Classic (not VB.NET) experts hang out in http://groups.google.com/group/microsoft.public.vb.general.discussion/topics?hl=en That said the VB6 IDE works well in Windows 7 once you know about one particular install trick which requires creating a 0 byte msjava.dll file in the Windows directory.
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to
view the forms, designers, etc to convert the app?
1 - I'd try to dig up an old copy of Access (or Office)
2 - Actually I doubt it'll even work in vb6 (and vb5 might be an adventure), the project upgrade paths weren't very smooth back then, but yes, you're pretty much stuck. As far as I know there was never anything else that would emulate those designers.
If you can find a version of VB4, or Access 95, then this would come with JET3.
2) Realistically you would need VB4 to have the best chance of opening this. Try to find someone who has some old MSDN disk sets.
You might try a later version. The jump from VB4 to 6 might be too much. I imagine it would open but perhaps not run in VB5 as I presume Microsoft looked at people upgrading projects from the immediately prior version.
We have a legacy vb6 application that uses an ancient windows media player component, msdxm.ocx, to embed ultrasound (pregnancy) video's in the medical record.
This doesn't work any more on Windows 7: it has a newer version of msdxm.ocx which cannot be referenced from vb6.
The newer version of the embeddable player is wmp.dll, so we are planning to upgrade the application to the newer version for Windows 7.
Before we have to find it all out the hard way by ourselves: does someone have experience with this upgrade from msdxm.ocx to wpm.dll? Is there a list of things to consider when upgrading? Or a table to convert constants and events from the first to the second?
I haven't seen anything listing their object models side-by-side or offering any "conversion."
The msdxm.ocx was really a scriptable IE object and should not have been used in VB6 programs. Lots of people did though. Windows 7 still has this OCX but starting with Vista (or perhaps IE7?) its interfaces changed in a way that seems to prevent use in VB6 programs.
You might want to try running a tool like ActiveX Documenter aginst working versions of both libraries to assist your efforts though. The RTF output documents might be a starting point for writing your own conversion guide.
msdxm.ocx should still work if you put the OCX file in C:\Windows\SysWOW64 and register it.
I've tried on my Win7 and it works on my music player legacy app.
Don't know about Windows 8 though, but it might still be the same, MS might changed folder again then.
wxWdgets is a cross-platform library that includes support for all the major windows versions, but I can't find anywhere in the wxWidgets documentation that says anything about the portability of a single MSW (windows) build of the wxWidgets library across different windows versions. Assuming my core app just uses vanilla C++ (and perhaps the least common denominator of win32 apis available on all platforms) except for wx functions, would linking statically against a single version of the wxWidgets library produce a binary that would run across Win2K, XP, Vista, and windows 7? Would that library need to be built on win2K (the "least featureful" platform?), or would building it on XP also work? Any hints or pointers would be appreciated!
You can build the application on any OS version you want, this doesn't affect the application compatibility with different Windows versions. You can even cross-compile Windows applications on another OS.
The important thing is the selection of API calls that the application references. Any functions linked at loadtime need to be present in the OS, while libraries or API functions that are delay loaded don't affect the compatibility, as long as the application handles the errors gracefully.
The stable wxWidgets version 2.8 is compatible with at least Windows 2000 and all later versions (you could even target Windows 9X if you use the non-Unicode build of the library), it delay loads all functions that are not available in Windows 2000 (for example theme support, introduced with XP). You can be sure that the application runs, but there may be things that don't work on Windows 2000 (for example transparent PNGs).
There may be additional minimum OS version requirements imposed by the development environment. Newer Visual C++ versions for example may require the C runtime to be installed on older OS versions, and there may be a minimum supported version. This however is independent of wxWidgets being used in the program or not.
Yes, wx binaries are portable across XP--7 range (and the same binary should also write on systems as ancient as 95 if you don't use Unicode or use MSLU but so few people use those nowadays (thankfully) that this might have actually got broken without anybody noticing). wxWidgets loads any functions not present in the system DLLs on all Windows versions dynamically, i.e. via GetProcAddress(), and uses reasonable fallbacks for the older systems.
For software applications like games, does this mean software companies have a lot of extra coding to maintain 3 branches of certain libraries?
I know this is hard to say, but for game development in general, are there specific areas in the software where they will have to write 3 times in order to work in all 3 flavors of windows?
I'm guessing the core software will be untouched, but maybe some drivers will need to be version specific?
It depends how close to the OS you are. If you're just using the .NET framework or DirectX, probably not much changes between operating systems. If you're writing drivers or relying on the Win32 API then there definitely could be subtle or not so subtle changes.
If your code is written correctly in the first place, there should not be a huge investment into supporting an OS upgrade. Using something like the .NET framework helps guarantee this even more.
Also, why would games have 'drivers'?
Not really. If you use DirectX 9, you are fine on all 3 Windows Versions. The extra maintenance evolves around stuff like the Installer/Uninstaller, about the Games-Tab that was new in Vista (if you want to use it) etc., but as said, DirectX 9 is a stable API on all 3.
You will get into some fun with DirectX 10 (not on WinXP) and with OpenGL (Support in Vista is weird).
Even if you use "portable" interfaces like DirectX or .Net or whatever that are supposed to provide the same functionality, a responsible software developer will have to do QA and testing on each supported platform.
(Note that I don't claim to be a responsible software developer. :-))
Many game develoeprs, including the studio I work for, use engines that manage cross platform issues. We are using Unreal for our game and it ports to the PS3, Xbox, and PC with no issues other than performance differences between them. The engine typically handles the differences in platforms.
As a .Net developer, most of the issues I saw when running applications built with XP as the original target were things we were doing incorrectly that just happened to work in XP (most were using the system colors that looked ok on XP but were wrong for Vista -- e.g., the default Vista theme caused a black font on black background).
It was coding by coincidence at its finest (we were naive enough to not know it was wrong). However, once we started testing on both Vista and XP, we started to produce a better Windows product.