I' m trying to run a project on Delphi 7 and getting file not found error 'NMUUE.dcu'. It is needed to create TNMUUProcessor object. Reinstalling doesn't help . So where can I find this library for my project?
I assume you've migrated this project from a lower version of Delphi. If I remember correctly, NMUUE is the UUE encoding unit for the Fastnet internet components. These didn't ship with Delphi 7 (I think Delphi 5 was the last version that supported them). I'm not sure if there's a download available for it still as NetMasters have gone out of business. Your best bet would be to migrate the project to use something like Indy.
That component is part of FastNet. It is not distributed with Delphi 7: http://edn.embarcadero.com/article/29766
The Fastnet components are no longer bundled with Delphi. It appears Netmasters does have a version compatible with Delphi 7 which can be purchased at: http://www.netmastersllc.com/
You probably will need to upgrade to a paid version of FastNet that supports Delphi 7, if such a thing can still be obtained, or switch to Indy.
On the other hand, if you are not actually doing anything more than uuencoding you could easily find a Delphi uuencode function with a websearch.
You probably ought to try to understand your program and what its requirements are before you proceed much further. Blindly solving missing dependencies without understanding why your program needs them is usually a recipe for future pain.
Related
The following question has had me wondering for some time now as to how 3rd party component developers are able to ensure there components are compatible with all the various IDE versions?
I am just a single developer who uses Delphi XE and occasionally Lazarus, if I developed some components in Delphi XE how would I ensure they are compatible up to Delphi XE6 for example, and also compatible with older IDEs?
I don't mean in a coding sense because I believe you use the IFDEF flags when checking the Delphi version numbers. I mean if you don't have access to different Delphi versions how do you test the component?
It is not possible for me right now to purchase XE6 or a new Delphi IDE for a while - if it all, and even if I could I would not have previous IDE's like Delphi 5,6,7 etc.
So how do other component developers do it?
Purchase all the IDEs? which seems unlikely
Download Trials for the IDEs? which also seems unlikely
Get people to test the component if they have another IDE? Seems possible
Make it Open Source and let others test it? Also seems possible unless you want it Close Sourced
What it comes down to is I want to make a few simple components but I want them to be compatible with as many Delphi versions as possible should they ever be released to the public.
I don't have the means to get all the Delphi IDE versions and downloading trials may also not be possible. Even if I bought XE6 or the next release I would not be able to test with Delphi 8 for example.
So, how do 3rd party component developers make there components compatible and tested on various IDEs? Am I missing something obvious here, how can you have access to every Delphi IDE Version?
As a component vendor myself (I am the primary developer of Indy) who needs to support multiple versions, I can only speak for myself, but here is how I do it:
Purchase all the IDEs?
If possible, yes. I have a number of IDE versions installed in VMs, which I use for testing purposes. And for some versions that I do not have installed, I do have their RTL source code for reference purposes, at least. On the other hand, as a member of TeamB, I get free IDE licenses, which helps. Not everyone can afford to purchase every version, although newer versions do provide free licenses for older versions, so you should take advantage of that. I recently installed Delphi 7 through this. If a components works in Delphi 7 and Delphi XE6 then there is a good chance it will work in all versions in between (barring any version-specific RTL bugs, etc).
Download Trials for the IDEs?
N/A for me, but that might be a viable option for some people.
Get people to test the component if they have another IDE?
I do this with Indy. Although I do have several versions, I don't have every version. Other users who have versions I don't have myself do help. If nothing else, for setting up version-specific project files and testing install procedures.
Make it Open Source and let others test it?
This also helps. If you want to develop closed-source components, you could setup a private repository and give access to select users/volunteers. Most users want/need source code (to find and fix bugs when used in their projects, to satisfy corporate policy requirements, etc), so you should make sure you offer an option to pay for source code.
When you buy the latest you get access to all the previous versions (from v7 on - thanks Uwe Raabe)
Previous versions
I am using the first approach: Buy all versions. I have all Delphi versions back to version 3 (from 1997), but only 6 to XE6 are installed on my machine (with the exception of Delphi 8 which in my opinion should better be forgotten). But of course I didn't buy them all at the same time, I started with Delphi 3 and updated from there on.
Unfortunately it becomes more and more complicated to get older versions installed and running on "modern" operating systems (currently Windows 8.1 so far) so sooner or later I will be forced to switch to virtual machines. Not yet, though. Switching to VMs has the drawback that you can't batch compile using different Delphi versions:
call CompileForDelphi6.cmd
call CompileForDelphi7.cmd
etc.
like I do for GExperts.
I started occupational programming with Delphi when the Turbos came out , and have licenses for Delphi 2006 Turbo Pro and Delphi 2009 Professional. I have been asked to support another in-house tool, written by another occupational programmer, who has since retired.
It's a Windows program, but it was developed with Delphi 6 using the CLX library rather than the VCL.
From what I gather, the CLX library was QT based and was removed prior to Delphi 2006.The support only consists of a few bug fixes and some minor tweaks, so I would rather not port the code to VCL, if i can avoid it.
Is it possible to install CLX support into either Delphi 2006 or 2009?
Maybe not a direct answer but if you upgrade to Delphi XE, you will also get license keys for some of the older versions of Delphi down to 7, and Delphi 7 included CLX (it was dropped in Borland Delphi 2006).
The short answer is: no. Unfortunately I don't know any long answer which could tell you how to workaround this.
No, you can't add support for CLX to your other Delphi versions.
If it's in-house software, then your company should still have the in-house Delphi installation used to develop it. Multiple Delphi versions can co-exist on the same system; install earlier versions before installing later versions.
If the former employee took that installation with him when he left, can you get it back? I wouldn't expect it really belongs to him anyway. You said he retired; that wasn't a euphemism for died, was it? If not, then you can still contact him.
If there isn't an easy way (and I suspect that there is not), you may need to continue using D7. D2009 is going to introduce the hassle of Unicode, and even going to D2006 is going to cause problems with 3rd-party libraries.
You could run both versions of Delphi on the same machine, but another option would be to use a VM for the legacy development. Either set up a new instance, or you could use the VMWare Converter to convert the other developer's entire machine into a VM image, which you could run on your machine, via the free VMWare Player.
BTW, VMWare Converter is a GREAT way to preserve old environments, to allow maintenance on older software that really needs to use a particular Delphi version, on a particular OS, "just like I left it". If you have a bunch of dusty computers under your desk, consider this option. VMWare Converter is the only tool I know of that will easily convert a physical machine to a useable VM that will run anywhere.
Just a quick question for those of you that know. Is it possible to have both Delphi (ver 7) and Lazarus installed at the same time. I want to make sure the Lazarus install will not interfere with my current Delphi install in ANY WAY. I would have asked this on the Lazarus fourms but thought I would get quicker reply here.
Anyway if you have both Delphi & Lazarus installed please tell me any problems you have encountered (if any) thanks.
Chris
Lazarus does not interfere with any version of Delphi, they can live along very happily.
The only interference is for commandline building, both projects have a make.exe file which are not the same.
This is easily solvable by not adding FPC to the path (removing it via control-panel system), and do a
set PATH=c:\fpc\2.5.1\bin\i386-win32;%PATH%
or wherever you installed as first line in your batch files.
I generally don't bother, but a previous employer we did a lot of cmdline building with dcc, and then it matters.
File associations are another, but already named. (but not such a big problem since the project extensions vary (.dpr vs .lpr, .dproj vs .lpi) )
Btw: Other development products (cygwin,mingw, and maybe even VS) have their own respective make.exe files and the same kind of problems.
I currently have Delphi 5 and Lazarus both installed on my Windows 7 laptop. As near as I can tell they don't interfere with each other.
I don't really use Lazarus though, as I prefer Delphi 5 which is what I've used forever.
I have Delphi 2006, Delphi 2010 and Lazarus installed. No problems at all. I am sure Delphi 7 will be the same. The only problem I can see could be the use of .pas extension in Lazarus. I mean because of association problems. But you can use a different extension for Lazarus (free pascal) source files. I think the installer asks you that.
I have Lazarus "installed" on a USB drive. It interferes with nothing whatsoever. It is actually a checkout of the Git repository that mirrors the SVN repository. I installed the latest stable FPC to C:\FPC, and then copied that folder to inside my lazarus source folder, e.g. \lazarus\FPC\ (and then uninstalled the C:\FPC installation), and then whenever I like I build the latest lazarus like this:
X:\lazarus\> git fetch
[...fetch messages...]
X:\lazarus\> FPC\2.4.0\bin\i386-win32\make.exe clean all
[...compiler output messages...]
X:\lazarus\> startlazarus
[...IDE starts up...]
The main advantage of this is that if you find an IDE bug, the source is immediately available and you can make and submit a patch instantly.
Why is there an Indy9 folder (The default install folder of C:\Program Files\CodeGear\RAD Studio\6.0\source\Indy contains subdirectories for "Indy9" and "Indy10") Why are both versions installed? What is using Indy9? I didn't think it had been updated for 2009...is Indy9 now safe to use with Delphi 2009?
There is an opened QC report about this, but it's only visible to QC sysops.
The status of "open" typically means that it's accepted that this is a bug, rather than by design.
Remy Lebeau - one of the Indy developers - said this:
The 2009 installer does ship with the
Indy 9 source code, but it is not
selectable during install. There is a
note in the documentation that Indy 9
can be installed manually if needed.
But keep in mind that Indy 9 has not
been updated to actually support 2009.
At the moment, I am not sure if it
will be.
There are some changes in Indy 9 (from the 2007 version) so that it will compile under Delphi 2009 (a few String to AnsiString changes), but based on my tests it doesn't work. It tries to, but does not connect. If you want I can give you the changes that have been added for Unicode support, but I don't believe they are sufficient.
I can't really answer why. I could conjecture a few reasons, but I do not have any insider information.
Is it safe to use? YMMV. There is a lot to Indy, so there may be some parts that work fine for your project. Even a simple test with the TIdTCPClient resulted in Socket Error #11004 every time. Same for TIdHTTP. It seems like I tried the MD5 previously and it just got garbage, but I am not sure on that one.
Answer: It was included by mistake (assumption), and it is not safe to use (based on limited tests).
That is unfortunate, because Indy 10 has issues too, and I have some legacy apps that use Indy 9.
Indy9 is there for compatibility. There were some breaking changes in Indy10 (your code that was written against Indy9 may not compile under Indy10) so you have the option of continuing to use Indy9 (I think the installer prompts and asks what Indy you want to use - at least it did with D2007).
Update: Okay a few people have correctly commented that Indy9 wont compile with D2009 (because of the new Unicode support), so I guess I don't know why it is there.
My guess, it was in the source tree, and was automatically included by installer.
Keep in mind that the source files are not used unless you tell Delphi to recompile them.
If you do not have the Enterprise version you will not even have these folders.
In the next few months I will be resurrecting a project which made extensive use of Orpheus and SysTools. The development system I used is long gone, so would like to update the libraries to my current development environment.
My question(s): is anyone porting, or has anyone ported the TurboPower libraries to Tiburon, if so did you encounter any problems; and if the answer is nobody, is it worth collaborating to produce a Delphi 2009 version, sharing the load.
Some components in the process of being ported to Delphi 2009, including 5 TurboPower libraries. No Orpheus or SysTools, though.
http://www.songbeamer.com/delphi/
Update:
As M Plaut pointed out, Orpheus has been added to the site and has been updated as recently as Nov 13.
Orpheus407AU_3 was posted at http://sourceforge.net/projects/tporpheus/ on Sept 5, 2009.
There is Orpheus project at SourceForge but last release was made in 2005 :(
Systools is also to be found there.
When turbo power closed their doors, I analysed my code that was using Orpheus and SysTools. I found that there were only a handful of SysToosl functions I was using and so we wrote our own functions. (Can't remember what they were)
It was fairly straight forward, some of them were in the newer versions of Delphi and the rest were easy to code.
Orpheus was a little more difficult. I would be willing to throw some time into bringing back Orpheus. We replaced it with standard Delphi components and some code, but our applications lacks some of the coolness it once had.
We would definitely be looking to port this as well. We use alot of Orpheus components in our current applications and this would be a definite roadblock to Delphi 2009.
As of 10-11-2008, there is a version at http://www.songbeamer.com/delphi/
of Orpheus as well. The following comments are attached:
This is based on the version from CVS. The first two packages compile and are partly tested. Some asm code still needs updating. Some bugfixing also need to be found and fixed. Contributions are welcome (use the contact form on the top). Search for "FIXME" in the source.
Files that may need special attention and bugfixes: OVCDRPVW.PAS, OVCPF.PAS, OVCEDITU.PAS, OVCVIEWR.PAS, OVCSTR.PAS
I have to bring a very old project to delphi 2009 : a CNC editor. The project didn't use Orheus at that time, but I was looking into it (did some tests), and the orpheus text editor is still the fastest on the market. So yes, I am very interested. I tried to compile the old source in delphi 9, but it crashes.
I am not a good programmer, but I can do tests for you.