This is a weird one. I've now installed Delphi 5, updated to service pack 1, on my brand new Windows 7 64-bit machine. It seems to function well enough, but when I start it up an error message comes up telling me that the system cannot rename Delphi32.$$$ to Delphi32.dro. I thought "Okay" and went in to rename it manually, only to find that there was no Delphi32.$$$ but there, large as life, was a Delphi32.dro ...
I'm logged on to an administrator-level account, so I figure it isn't a permissions issue.
I'm willing to live with this slight annoyance, but I am worried that it is symptomatic of some deeper problem.
Has anyone else encountered this?
This is a user permissions issue.
Even running as an administrative user, Windows 7 puts some limits on where applications can write. C:\Program Files, (AKA %PROGRAMFILES%) is off-limits except to applications explicitly started using "Run as Administrator", even if you're running under an account with Admin privileges.
More recent versions of Delphi properly handle running from the restricted folders, but D5 was outdated long before Win7 was released and therefore does all sorts of things that aren't proper now. It writes to its own Bin and Lib folders, for instance, and stores the default Projects folder for your own projects there as well.
The easiest solution is to uninstall Delphi 5, and reinstall in a location outside the %PROGRAMFILES% directory structure, such as C:\Delphi5 or C:\Borland\Delphi5. Installing in a different root level folder resolves these issues.
Actually, the easiest solution is to upgrade to a more recent Delphi version, but I'll presume that isn't an option. :-)
This might also help with Delphi 5:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
Ken White's Answer sums it up nicely.
Installing Delphi in a folder other than "Program Files" can threaten and infect Delphi files, and malware can easily infect your Delphi files
(this is a serious threat).
My suggestion is to install a sandbox (or a program virtualization) such as Sandboxie-Plus and Run Delphi from it, you can force Delphi to always run from the sandbox, just be careful your project files are stored inside the sandbox, so you have to manually move them out of the sandbox (for when you want to publish it)
Related
I was making a Delphi application, and wanted to test it on another PC to see if everything was working properly. I compiled and built the executable file, of course and I transfered all of the files from the Project folder to the other PC. When I launched the .exe file on the PC, nothing would happen. I then ticked the "Build with runtime packages" option in Project Options:
This made the .exe go from around 300 KBs to around 30 KBs, but now, instead of being able to launch the application on another (non-Delphi) PC, that PC got an error saying it was missing various files required to open the .exe .
I sent the same thing to various friends and all reported the same problem.
My application is a rather simple lottery prototype application, so I don't understand why I'm having trouble opening it on other PCs. Are there other special options I need to enable for this to work?
When you use runtime packages, you need to distribute those packages. These are the .bpl files that your program links to. It will be a subset of the packages listed in the runtime packages edit box in your screenshot. You should just list the packages that you use.
The net result of doing this is that the total amount that you will have to distribute is much greater than a single monolithic executable. Because in a monolithic executable the unused code can be stripped. If you want to minimize the size of your program, and make life simple, do not use runtime packages.
It would be worthwhile reading Embarcadero's documentation:
Working with Packages and Components
Solve the first problem.
Using Runtime Packages will not solve the problem of your EXE not running on certain PC's. All it does is increase the complexity of deploying your application (as you have found).
Unless you need Runtime Packages for other, specific reasons, then you are far, far better off NOT using them, especially if you do not understand them (which based on the way you describe having discovered them does appear to be the case, if we're being honest).
Concentrate on finding out why your application does not run as a single, stand-alone EXE.
With all of the problems involving runtime packages your EXE is currently not even reaching the point of running your application code, and this may be where your original problem lies. Which means that once you have solved all the issues created by Runtime Packages, you will stil be left with an EXE which does not run. i.e. your original problem.
What does your application do when it starts ? Does it attempt to load files from any specific locations ? What are those locations ? What are the files ? Are you using any third party libraries which may expect DLL's to be present or other external files ? Are you trying to read or write settings to the registry or any external files (INI files etc).
What is the OS you are trying to run on ? This can be a very significant question for applications compiled with older Delphi versions. Have you tried configuring the EXE to run in Compatibility Mode for older versions of Windows ? (something that you do in Windows itself, not when compiling the EXE).
These are the questions you should be focussing on. Not runtime packages.
Gday,
A small tool that's been around for a while to help you with this is Dependency Walker. You can find it at http://www.dependencywalker.com. It's helped me out on more than one occasion. This will tell you what files (usually BPLs as stated in the other responses) need to be sent with your EXE.
Also look at NSIS to create a simple installer, and put your EXE and supporting BPLs and any other files in the same directory.
I have two PCs both with XE2. I thought that I had installed identically on both but have problems installing 3rd party packages on one while the other is just fine.
I want the same on both anyway. The easist would probably just to "migrate" the working set-up by moving in into my Dropbox folder. Can I do that? If so, how?
If not, can I (easilly) backup my registry settings on one machine and then import them on the other?
I suppose I could just sort out the problem on the one PC, but am not having much luck so far. I would rather invest the time in only having one Delphi setup. And since I am moving lots of other stuff to DropBox anyway ...
The tool for this is now built into Delphi XE8 and higher.
It's found here:
C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\migrationtool.exe
Online documentation:
http://docwiki.embarcadero.com/RADStudio/Rio/en/Settings_Migration_Tool
Install CnPack wizards from http://www.cnpack.org
From the CnPack toolbar select IDE Config Backup/Restore (image below) and save this file somewhere safe
Copy the components to the second delphi machine . Keep the exact same directory structure.
I store my components as follows this helps backing up, moving etc., but you can use your own structure
D:\components_bds\DCU
D:\components_bds\BPL
D:\components_bds\ComponentsThemselves
Use the restore config file from CnPack to restore your components on the new machine
This is also useful if your testing components that you plan to remove later and keeping a backup of your installation incase something goes wrong you can save time with new delphi installation if hard drive dies. Keep a copy on flashdrive or somewhere safe
You may compare/diff the config file created by cnPack using a tool like Beyond Compare and see what the differences are to find out why third party components give problems on one of the machines. It may be a Delphi registry/installation problem or a problem in the paths of the thirdparty components. Components need to be installed in an order perhaps it did not find the needed dcu or dll it depends on.
I don't know of any way to do so with DropBox. Here's an old post I made (related to Delphi 7, but with correction of registry keys still applicable) in the CodeGear newsgroups; hopefully it will help.
(It probably goes without saying, but back up the existing registry settings on the destination machine before starting by using RegEdit and exporting them, just in case. You'll at least be able to get back to the point you're at now if something goes wrong by deleting the imported entries and then importing the saved ones.)
You can't, without some difficulty anyway. (Especially if you have
third party components installed, as they may have placed files in the
%SYSTEM% folder you may not know about.)
You may be able to (for going from the old computer to the new
computer running the same exact version of Windows!) by exporting the
registry keys under HKCU\Software\Embarcadero and
HKLM\Software\Embarcadero from the old machine, and then after
installing Delphi on the new machine (in the exact same folder
location) importing that registry file.
Many of the compiler, linker, and other settings are configured on a
per-project basis, and should transfer over when you move your source
code to the new machine.
Third-party components are a problem, as I mentioned above. You may be
able to get away with using the registry export/import if you copy
each third-party component set from the old computer into exactly
the same location on the new machine before importing the registry
file. You'll probably have to track down some .BPL files that end up
in the $(BDS)\Bin and possibly other folders under the $(BDS)
tree; the IDE will tell you about missing stuff when you try and start
it. Make sure you answer "Yes " when asked if you want to try and load
it again next time!
Most of my development is hobby stuff or wannabe releases. Instead of dying trying to move my XE2 Pro from my Dell Inspiron N7110 Win 7 machine to my new Win 10 SSD machine, I'm seriously thinking of switching to Lazarus. I've used Lazarus 2.x with Indy 10, ZeosLib, and Firebird and successfully created a working distributed internet system. I also created Lazarus version of my XE2 Blackjack program. When compared to XE2, Lazarus (IMO) has only two weakness and neither are deal breakers for me. BTW, I have successfully duplicated Lazarus (with all installed components) from one machine to another simply by copying and pasting the Lazarus directory and it works. Try that with Delphi.
Sam
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.
My computer crashed recently. We have a Delphi app that takes a lot of work to get running.
One of my co-workers has it all installed still. Is there a way to copy the stuff stored in the palette? And the library paths?
I am using Delphi 5 (I know it is very very very old)
That information is stored in the Registry. I don't know exactly how Delphi 5 does it, but try looking for a key called HKEY_CURRENT_USER\Software\Borland\Delphi\5 or something like that. You'll find all the registration information under that key, including a list of installed packages. You can export the keys to a registry file, copy it to the new computer and install it.
Standard disclaimer: Mucking around in the registry manually can be risky if you don't know what you're doing. Be very careful, and if this solution causes your computer to crash, your house to burn down, or demons to come flying out your nose, it's not my fault.
Try CNWizards which has an export functionality for your IDE settings. You can use the same tool restore them on the new machine. We use it to get the same settings on every development machine. In that way we can ensure that all builds are the same, regardless of who built it.
Based on my experience of having done this a few times(!), the most important registry keys are:
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known Packages
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Library
and possibly
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known IDE Packages
and maybe
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette Defaults
So long as you have done a standard D5 installation first.
It's easier/more reliable to let the IDE fill in the other bits as you start using it and you change options as appropriate. Some component packages, eg madExcept, DevExpress etc are often best re-installed using their own installers anyway.
Unless you're going to have multiple users on the same machine using Delphi then the HKLM stuff isn't really all that important - I don't think.
As a related aside - I have learned that a good way to handle this is to build a FinalBuilder script (or similar) to set up my Delphi environment each time I decide to use a new machine/installation. I copy/download/checkout (which can be done in FB too) all package source then use FB to compile it, copy it, create dirs, and fill in the appropriate registry keys etc. I always get a consistent environment and makes it much easier to rebuild individual components or packages as and when they get upgraded too. The items can also be put into the script in 'dependency order' so that you know to re-compile a dependent package if something else changes. I now have a single FB sciprt that builds D5, D2007, D2009, D2010 environments and packages of all my main components, all depending on which compiler(s) I'm interested in which I indicate by a simple variable. Well worth it.
Seems to have just worked for me on a Win 7, SP1 and Delphi 5
Logged as user with Delphi & 3rd party components installed.
registry export
hkey current user\software\borland
(no other borland products so selected Borland)
rather than Borland\Delphi\5.0)
Logged into pc as new user.
Did not start Delphi5 (i.e. never started for this user).
Regedit File, Import
Started Delphi all components, including lots of 3rd
party, present.
Project compiled as expected under new user.