I'm having a very similar problem to the one posed in this problem (having to connect twice on first load because of a "problem" loading the SSL dlls), except I'm pretty sure I'm using the latest version of Indy so the solutions proposed there do not solve my problem.
I am using Delphi7, and I selected not to install Indy from the Delphi7 installer since that version is incredibly obsolute. I did install Indy9 from latest SVN source before downloading and installing Indy10 (from SVN source), but I reconfigured the IDE and project settings to use the new Indy10 components/paths instead of Indy9. Clearly the project is using Indy10 to build as there are quite a number of methods I had to change to match all the Indy10 signatures to even compile.
My SVN repository for Indy10 is checked out from: https://svn.atozed.com:444/svn/Indy10/trunk/Lib and shows last commit revision of 4972, about 2 weeks ago--this does not look like "some really old version of Indy10".
I have downloaded OpenSSL 1.0.1e for Win32 from the binary build at http://opendec.wordpress.com/ (the location recommended from that other stackoverflow question I mentioned earlier) and put it in the same folder as my built .exe
Here's the code I'm using right now to open an SSL connection:
try
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
Except
on e : EIdOSSLCouldNotLoadSSLLibrary do
begin
ShowMessage('Failed to load: ' + WhichFailedToLoad());
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
end;
end;
BUT... this is causing an EIdOSSLCouldNotLoadSSLLibrary exception, and adding WhichFailedToLoad shows the exact same list of components, that would suggest it's expecting the "indy specific" version of OpenSSL:
But Wait a minute... Remy answered in the linked question that "Indy 10 was updated to no longer require the custom-built DLLs anymore. It now uses the standardized OpenSSL DLLs as-is." So why would it be complaining that it needs Indy specific functions?
How could I troubleshoot why it's failing to connect the first time/saying it needs functions I understand not to be needed anymore? Is my expectation that it should not be looking for indy specific functions incorrect?
My guess, confirmed in the comments to the question, is that your compiler is finding Indy 9 and not Indy 10 to build your project.
The things can go ever worst, because your IDE may be using one version in design time and the compiler may be using a different version. In fact the IDE and the compiler are different parts of the chain and you can broke the original synchronization between both. Because that, I'll explain both cases and, as I explain later, you have to change both.
The IDE and design time
Design time packages are loaded by the IDE to create objects while you're working, show you the properties of that objects in the object inspector, create the form DFM files and get the method firm to be used when you resort to the IDE to generate pascal code to respond to events.
For the IDE you can check what version you're using in design time by right clicking on any Indy component, as shown in the image.
To change the version you're using in design time, go to Component\Install packages and check the correct version in the list. You cannot load Indy 9 and Indy 10 at the same time.
The compiler and run time
The compiler uses the Library path to look for the units you use in your project that are not part of the project itself, and compile that code along with yours to produce the executable.
To check what Indy version was linked into your executable, you can resort to the Version property present on all INdy components, for example:
ShowMessage('Indy version: ' + MyIndyComponent.Version);
To change what the compiler finds first, you have to change the paths. You can do it from inside the IDE. In modern Delphi you could check in Tools\Options\Delphi options\Library\Library path\ and Project\Options\Delphi compiler\Search path\ (I just don't remember where the options were in D7).
The Indy 9/10 case
Indy introduced interface breaking changes that makes impossible to compile a project written for Indy 9 using Indy 10. In fact, the administrators of the project doesn't wait for a major release to break the code compatibility and you expect to be forced to adjust your code when you upgrade to any minor version if it happens to have a different interface.
Because of that, you're definitely using Indy 9 in both, at compile/run time and IDE/design time, so you have to adjust both in your environment. After that, be prepared to re-write part of your code to adjust. Once you understand what changed and learn how to adapt, the change is fairly simple. The details are out of the scope of this answer, but there's enough information in the Internet for you to figure out how to do it.
Related
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.
I've just downloaded from SVN the DUnit2 code base.
Does someone has compiled it successfully?
What steps/prerequisites I've to follow in order to compile it?
Do someone knows if an already compiled version exists?
thank you
fabio vitale
In the projects directory, find the subdirectory corresponding to your version of Delphi. In it, you should find a project-group file, either DUnit2ProjectGroup.bpg , DUnit2ProjectGroup.bdsgroup or DUnit2Delphi<version>.groupproj. Open it and compile all the projects in order.
Using DUnit2 is pretty much the same as using DUnit.
In case someone else stumbles over this question while trying to make DUnit2 run on Delphi XE (or XE5):
TL;DR:
Dunit2 (official SourceForge source, revision 101) doesn't currently (being as of this writing on 2015-06-01) build successfully on either Delphi XE or XE5.
To make it build on XE or XE5, go get the patch I posted here
Apply it to the source tree. It should now compile and you should be able to open the .groupproj and build all the contained projects successfully.
The patch may be applied with and was created with TortoiseSVN (in case it matters).
Longer version:
Amazingly tonight (2015-06-01) I followed the same steps as Fabio (in 2012 no less) and ran into exactly the same issue (E2010 Incompatible types: 'Pointer' and 'Integer') trying to compile DUnit2 (revision 101 trunk checked out directly from SourceForge) on XE and XE5.
I've come to the following conclusions:
1) There's multiple issues with the head revision with respect to both XE and XE5.
2) The key issue above that Fabio mentions can be fixed by replacing IntPtr with Pointer.
This doesn't actually seem to make any difference in the code as far as I can tell, and the test suites also pass fine on both XE and XE5 after this change, though caveat emptor - I've not looked too carefully either (and also subject to caveats below.)
3) Project search paths being out of date [XE]. Just needed updating/fixing.
4) Missing $DEFINES for XE5 and others, despite some other code being quite aware of XE5
5) Some enhanced TRect stuff that's not available on XE. (The amount is relatively small and relatively trivial to inline to more basic expressions that will compile and is available on XE so was by no means show stopping.)
(Re 3,4 & 5 -- Sadly I get the impression the codebase isn't very well tested against multiple compiler/BDS targets.)
6) Some kind of Application.OnIdle/GUI testing bug (run T_TGUITestCase tests to see it) whereby the GUI automation tests would block unless you keep "feeding" the Windows Message queue by say moving your mouse or pressing the shift key to trigger Application.OnIdle events (repeatable on my Windows 8 XE5 and XE binaries).
Now speaking off the top of my head, and from vague memory from many years ago, I seem to remember having run into this before, and that it is down to a subtle change in behaviour either in Delphi or in Windows some time ago. -- IIRC in past, it used to be the case that one would would actually still get the occasional Application.OnIdle() call in your Delphi app even when nothing else much was going on on the system, even when you set Done to True. And as I recall, this changed at some point due to either a change in Windows or Delphi (can't remember which) several years ago and one had to be a bit more circumspect about setting Done to False if you didn't want your App to go to sleep entirely. In any case, it clearly was/is an issue on my PC tonight with the current (as of this writing) DUnit code, so I had to patch around it.
I did this in arguably a rather kludgy way, e.g. by manhandling things via providing an OnIdle handler while running GUI automation tests to signal that that the app is not in fact done (e.g. "don't block, don't go to sleep") and then reinstating any prior handler immediately after. There is no doubt a more elegant solution to this, perhaps by posting a message to ourselves to keep the app "alive", but my first attempt or 2 at something better didn't work out and I'm not interested enough to pursue this further. I'd be interested to hear of a better fix though.
I've supplied patches, but got no feedback from the DUnit2 team on SourceForge. So I forked DUnit2 with the full commit history into my Github account. I've applied many fixes there, including the compilation issues with XE & XE3+ and the scriptable self-tests that pause if no mouse action occurs. I'll continue my development of DUnit2 on my Github account [https://github.com/graemeg/dunit2].
It's time for this question again, but this time with Delphi XE2.
I am using the Indy version 10.5.8.0 that ships with XE2, and I have tried four different versions of the SSL dlls. I have tried 1.0.x latest, and about 3 different 0.9.8 versions (e,h,x,....).
None of them works, when communicating to https:// urls at calendar.google.com. The author of the Delphi Google Calendar component at "Sync-components.com" ships his own binary
openssl DLL runtimes that have no version information in it, but it seems to be a very small, very old version of SSL libs older than 0.9.8. The author of the component says only his private unversioned DLLs are known to work. I can't believe that. Surely at least one version of the openSSL dlls works well enough with Delphi XE2 to connect to Google Calendar.
In order to get his custom ancient DLL to load into Indy 10 in Delphi XE2, he modifies IdSSLOpenHeaders.pas method Load, like this, at the end:
function Load: Boolean;
begin
/// ... lots of stuff
//Result := (FFailedFunctionLoadList.Count = 0); // original.
Result := (FFailedFunctionLoadList.Count <= 18); // changed to.
end;
Of course, the component that I am evaluating does not work in XE2, but I suspect it's the brokenness of either (a) this particular snapshot of Indy 10 that ships with XE2, or (b) the fact that the World of SSL DLLs is a veritable hell of "broken for you but works for me" different versions.
What do I have to do to get an SSL connection to Google Calendar, using Indy (or any other delphi component library with SSL support), in Delphi XE2?
Alternatively, if anyone has a google calendar API implementation that works with anything other than Indy that I could use for testing, I would appreciate links and pointers.
There is something wrong with the snapshot of Indy10 that ships with XE2, in that the idHTTP object appears not to work well with any of the OpenSSL dlls I found, in that I could not communicate with any Google Calendar server services with them.
The actual underlying nature of the problem seems to be that Indy doesn't handle HTTP redirects as transparently as we might have hoped. The code that is manipulating Indy (third party component) does some really hard to understand things with the Indy "http redirect" handling logic that appears to be a set of workarounds, that don't work. What is furthermore confusing, is that the exact places in the code where HTTP redirects occur varies from one person testing Google Calendars, to another, so these redirect glitches do not always appear in the same places for each person testing it.
Note that the login method, and method to get the calendars worked. But the methods and code that were to read events, seem not to work. I was unable to figure out the difference between the two, but the code I am using is commercial and I can't post any of it. I will update this message if I ever figure out the actual technical reason that the HTTP get request was returning "0 bytes" in its response for urls like this:
https://www.google.com/calendar/feeds/firstname.lastname%40gmail.com/private/full?max-results=100000
Those zero byte results were really HTTP 302 redirect response code, which the code I was using, did not check for or expect. It was expecting Indy to automatically handle redirects.
The problem could either that Indy10 version is very specific and only works with a version of the openSSL dlls that I didn't happen to find in my searching today, or that the Indy10 version that ships with XE2 doesn't work with ANY version of the OpenSSL dlls that I could find, at least not when the target it's talking to is google's HTTPS calendar servers.
The code I am running creates an IdHTTP object with a TIdSSLIOHandlerSocketOpenSSL.
This works in all versions of Delphi up to and including XE, but breaks with a factory XE2 system, due to the Indy version shipping with XE2.
The only fix I have found is to install a new nightly build of Indy, I grabbed 4760, which appears to work fine, when combined with OpenSSL dll version 1.0.1.
It looks to me like using OpenSSL with Delphi XE2 is a bit difficult out of the box. A huge thank you to the Indy team for working so hard.... But can someone please help them out? This is really a great project and a great product, but when it breaks, and when you have to follow a moving standard (like the openSSL implementation), perhaps a bit more documentation, and testing, and eyeballs would help. I stand ready to assist if anybody can show me how I could help out. The problems with SSL are not indy-specific, as I notice that other component vendors and open source people have specific versions of the OpenSSL dlls that they support or don't support.
Another sad things I learned today: Some of the installers from OpenSSL install their DLLs by default (without warning) into your windows System32 directory, causing not only your app, but others, like TortoiseHG and TortoiseSVN, to perhaps break. If you didn't have a big problem with SSL before you started playing around, you could easily make it worse if you install a bunch of installer-versions from the OpenSSL website.
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.
Since Indy is now built-into the install process of Delphi 2009... is there a proper way to 'remove' it so it can be upgraded to the latest from the SVN repo? There isn't an automated option to remove it as far as I'm aware.
The dcu files for Indy are stored separately from the other Delphi units. To stop using them, simply remove that directory from the search path, library path, etc., and remove the source files from the browse path.
You can remove the design-time packages the same as any other design-time packages. Remove them from the IDE configuration, and then delete the bpl and dcp files. (If you just delete the files, you may get errors when you next start the IDE since it won't find the expected files.)
Once the Indy components no longer appear on the Tool Palette, the packages no longer appear on the package list, and compiling a project that references Indy units fails with a "can't find used unit" error, you're ready to start installing the latest version.
As Rob already said: Just remove the direcories from Delphi's configuration. An additional step is required though: After each update, make sure they have not been added again! Some of the Delphi 2007 updates apparently did that and I missed it for quite a while until I stumbled upon a bug that I already thought fixed.
I didn't use Delphi 2009, but in older versions of Delphi the installation of Indy components was optional. So you could try launching the setup for Delphi 2009 and see if there is an option to "Add/Remove features" or something similar and use it to remove Indy.
Also, you can customize which packages should be loaded in a project, so you can simply deselect the Indy 10 one and add the one from SVN on a per-project basis (you can also configure the default configuration for projects).
PS. Indy rocks! :-)