I distribute a Win32 Delphi application that uses ADVAPI32.DLL to call some encryption and decryption routines. It works great on modern versions of Windows, but a few customers use some very old versions of Windows, like Windows Vista and unpatched Windows 7. For those customers, the version of ADVAPI32.Dll is obsolete and sometimes causes decryption errors.
I know that advapi32.dll is a "known" system DLL, and as such it cannot be loaded locally (I mean, from my app folder instead of System32), so how can I solve this issue? I tried using a renamed local copy of the DLL but that didnt work either...
First and foremost, you are not legally allowed to redistribute advapi32.dll. Second, you cannot reliably run newer system DLLs on old systems, they come with dependencies and you need to provide the updated dependencies. Many system DLLs have special protection mechanisms preventing from loading an incorrect one as part of elementary DLL hijacking prevention security mechanisms. And finally, CryptDecrypt and friends, as well as other similar functions are working perfectly fine in Vista and Windows 7. If you encounter issues, is either a bug in your code, or you are simply not respecting the stated restrictions of Crypto API for said platforms. So better post the code you use, and the error you get on those older systems.
Even if you are able to load a different version of advapi32.dll, there is no guarantee that it will actually work on the target systems.
The advapi32.dll is only an interface dll that provides the "public API". Internally it delegates much functionality to the windows kernel, so if this interface changes or the kernel of the target system does not implement a function, your app will crash. You should think of advapi32.dllmore as an interface than an implementation - you call methods provided by it but it may do different things on different platforms that provide a version of the dll.
On Windows Nano Server the advapi32.dll is only a forwarding dll that delegates API calls to other DLLs ("OneCore" API).
In our program we are using a web service to pull back data from a third party into our program.
Ever since we updated to Delphi XE from Delphi 2009, Windows server 2003 users are receiving the following error message when making a SOAP call to the web service.
msvcrt.dll on Server 2003 does not have the procedure _ftol2_sse which is now being called for some reason..
I know this procedure was not being called when we had our source code on Delphi 2009 because I don't get this error on Windows server 2003 when running those builds.
Is this feasible? Could a change in the IDE affect which dll procedures are being called? Does anyone have any insight or ideas on how I might track down or fix this error?
Thanks
This is the third similar question you have asked on this topic. I'll attempt to give you some background information and help you work out what is going on.
First of all it's important to know that msvcrt.dll is a system component. It is not the MSVC runtime. It is supplied as part of Windows. Back in the bad old days, in the mid-90s, a lot of devlopers assumed that the MSVC6 runtime was always available. And they neglected to install that runtime as part of their program's installation. This occasionally caused trouble when the install program happened to find a machine without MSVC6.
The MSVC team moved to differently named runtime DLLs, msvcrt70.dll, msvcrt80.dll and so on. And they educated the developers that installing the MSVC runtime should be part of all MSVC application's installation programs.
But the Windows team wanted to help out legacy apps that had installers that assumed MSVC6 runtime was available. So they took the MSVC6 runtime under their control and started shipping it with Windows. I think this started around the time of Windows 2000 or XP.
The point I am trying to make is that msvcrt.dll is a system DLL over which you have no control. In your previous questions you have described your attempts to modify that DLL. Don't do that.
Now, from what I can glean, the version of msvcrt.dll that shipped with 2003 server does not export a function named _ftol2_sse. Hardly surprising since SSE floating point was not widely available back in the days of 2003 server. Clearly something in your system is resulting in an attempt to import _ftol2_sse.
You should be able to work out what is provoking this by using Dependency Walker. Use the functions on the Profile menu to start your application and study closely the logs. You should be able to see the chain of events that lead to an attempt to link to _ftol2_sse.
I'd be surprised if any of the Windows code linked to msvcrt.dll. That library is provided purely as a prop for legacy apps that link against MSVC6. But you never know.
Also try loading your executable in Dependency Walker. Look at the list of imported DLLs. Check to see if msvcrt.dll is in the list. If so, see what functions your executable imports, and if _ftol2_sse is in that list. If so then you'll be able to find it somewhere in the Delphi source code.
From the various similar sounding reports on the web I suspect that the problem you face is benign. Many of the people reporting the same issue can OK the dialogs and have their program continue without problem. This suggests that you can simply suppress the error reporting and so solve your problem. Use the SetErrorMode function to do so. You want to include the SEM_FAILCRITICALERRORS flag.
Be aware that SetErrorMode has a rather perverse interface. Almost all code that I have ever seen uses it incorrectly. Including the code in the Delphi RTL, and so many of the commonly used Delphi third party libraries. Raymond Chen, as usual, explains how to use it correctly.
Could switching compilers provoke the behaviour change? Certainly they could. Either the library code that you are using is implemented differently. Or perhaps the error mode is somehow different at the crucial moment.
I never really got the chance to do anything with Microsoft ActiveX in all of my programming career. So, I have very little knowledge of what it is or what it is used for. Although I've searched on the Internet for answer, I found many different definition for ActiveX or ActiveX Container. One of my customer is asking for ActiveX Container for my software which I don't have. He wants view or take control of my software remotely through this ActiveX Container. Is this possible? Also, is ActiveX still around? I am trying to see if I can put this ActiveX container real quick for him to use.
I am assuming that ActiveX is used to expose some part of your software to the Internet or the Intranet. So, that the user can get access to your application remotely.
Any response will be greatly appreciated.
Thanks,
An Activex container is a frame where An ActiveX control can run, These containers can be embedded in a Desktop app or a Web page.
Due which the ActiveX control contains native code you must setup the security settings of your browser in order to run this kind of objects. The only browser where the ActiveX is fully supported is IE (exist some experimental projects to support Activex in Firefox and chrome) Also these containers only can run under Windows.
The fastest way to convert your existing app into a ActiveX Control , is using a TActiveForm (below you have a link with a sample).
For more information try these links
Introduction to ActiveX Control Containers
Wrapping a Delphi TFrame descendant as an ActiveX control
I want to design Delphi plugin framework. There are three options:
1. DLL
2. BPL
3. COM interface
Every option has some disadvantage.
DLL - Promblem with MDI apllication, forms from plugin cannot be embeded to the host exe - mdi application.
BPL - Every *.bpl plugin and *.exe host application must be compiled with the same version of Delphi.
COM - Interfaces {xxx-xx-xxx-xx} must be registered in system, (regsvr) So plugin framework cannot be portable!
Is everything true what I wrote above? If not, please correct me, or is there some other possibility?
thanks
Yes, what you wrote is correct. All of these have advantages and disadvantages, the question is what is important for you, you didn't say what you want to do, so we can't tell you how to do it.
In general, I would pick BPL by default, use DLL if you need to use it from non Delphi apps, and pick COM only if you really have to.
The alternative is to not build your own, since there are several Delphi plugin frameworks available.
Also, this topic has been discussed here before, check out:
how-best-to-add-plugin-capability-to-a-delphi-program
plugins-system-for-delphi-application-bpl-vs-dll
Another possibility is having a scripting interface, such as with Python or Pascalscript. There are many advantages to this approach, not least of which is that the plugin source is also the executable, making it easy to debug and share.
I would look at Hydra from Remobjects.
Another candidate would be a combination of PaxCompiler (scripting) and EControl Form Designer (form designer).
We use DLLs, even when using only with a Delphi application.
Dll forms are embedded in the main form and use Tabs instead of MDI.
For DLL to work properly we also use a shared memory manager and built with runtime packages: vcl, rtl and our own package.
Have you taken a look at http://www.tmssoftware.com/site/tpf.asp
I am looking to add the capability for users to write plugins to the program I have developed in Delphi. The program is a single executable with no DLLs used.
This would allow the user community to write extensions to my program to access the internal data and add capabilities that they may find useful.
I've seen the post at: Suggestions for Adding Plugin Capability? but its answers don't seem transferrable to a Delphi program.
I would like, if possible, to add this capability and keep my application as a single executable without any DLLs or additional modules required.
Do you know of any resources, components or articles that would suggest how to best do this in Delphi, or do you have your own recommendation?
The first question I would ask is, do you need the plugins to access the UI of your host application, or add any UI elements of their own? Or will the plugins be limited to querying and/or supplying data to your host app?
The latter is much easier and opens up two possibilities. Others have already mentioned DLLs, which is the first way to go. Certain caveats apply - in general you should be interfacing with a dll using only the data types that are used in Windows API. THat way you can be sure that the plugin DLLs will understand your data types, no matter what language/compiler they were created in. (So for example, use PChars, not strings. Do not as a rule pass Delphi classes such as TStream to a DLL. This will appear to work in some cases, but is unsafe in general, because even if the DLL was compiled in Delphi, it may have been a different version of the compiler, with a slightly different idea of what TStream is). Google for using DLLs in Delphi, and you'll find plenty more tips.
Another way that hasn't been mentioned yet is to enable scripting in your application itself. There are several very capable 3rd-party scripting engines, both commercial and free, and most of them allow you to exchange Delphi objects with the script. Some of these libraries support only Pascal as the scripting language, others will let you use Basic (perhaps better for beginner users) or other languages. See for example RemObjects Pascal Script (free) at http://www.remobjects.com/free.aspx .
My favorite scripting solution at the moment is Python for Delphi (P4D, also free) from http://mmm-experts.com/Products.aspx?ProductID=3 It can interface beautifully with your classes via RTTI, and allows you to execute Python code in your Delphi app, as well as use Delphi classes in Python scripts. Given the popularity of Python, this may be a viable solution if you want to attract developers to your project. However, every user will need to have a Python distribution installed.
It seems to me that the barrier to entry, from the point of view of potential plugin writers, is lower if you use scripting than if you choose DLLs.
Now, back to my initial question: things get much more complicated if you need the plugins to interact with your user interface, e.g. by placing controls on it. In general, DLLs cannot be used to do this. The Borland/CodeGear-sanctioned way is to use packages (BPLs). With BPLs, you can access and instantiate classes offered by a plugin as if they were declared in your host application. The catch is, all BPLs must be compiled with the same exact version and build of Delphi that your main application is. In my opinion this makes packages completely impractical, since it's hard to expect that all the potential plugin writers around the world will be using the same version of Delphi you are. A major pitfall.
To get around this, I have experimented with a different approach: keep using DLLs, and develop a syntax for the plugin to describe the UI it needs, then create the UI yourself in the host app. (XML is a convenient way to express the UI, since you get the concept of parenting / nesting for free.) The UI description syntax can include callbacks to the DLL triggered when the contents or state of the control changes. This method will restrict plugins to the set of VCL controls your application already uses or has registered, though. And it's not a one-nighter job, while BPLs certainly are.
Google for "Delphi plugin framework", too. There are some ready-made solutions, but as far as I know they usually use BPLs, with their limited usefulness.
Actually, the accepted answer to the question you cite is quite appropriate for Delphi as well. Your plug-ins will be DLLs, and you can dictate that they should export a function with a certain name and signature. Then, your program will load the DLL (with LoadLibrary) and get the address of the function (with GetProcAddress). If the DLL doesn't load, or the function isn't there, then the DLL is not a plug-in for your application.
After you have the address for the DLL, you can call it. You can pass the function an interface to something that represents the parts of your application that you wish to expose. You can also require that the function return an interface with methods that your application will call at various times.
When testing your plug-in system, it will be wise to write a plug-in yourself with a language other than Delphi. That way, you can be more confident that you haven't inadvertently required everyone to use Delphi.
At first I went for BPL and DLL base plugins. And found them hard to mantain.
If you use BPL system, then you need to match BPL version with EXE version. This includes Delphi updates which can break something. I found out (the hard way) that if I need to include all my plugins with every release, there is no point in having plugins at all.
Then I switched to plain DLL plugins. But that system just complicated code base. And that's not a good thing.
While crusing the net I found out Lua embedded script language, and delivered with it. Lua is 150K DLL, embedding bytecode compiler, interpreter and very simple and smart dynamic programing language.
My plugins are simple lua scripts. Easily mantaind and made. There are premade Delphi examples, so you can export any class or procedure as Lua table or function. GUI or not. For example I had TurboPower Abbrevia in my app for zipping. I exported my zipping class to lua, and all plugins now can call zip('.', 'dir.zip') and unzip(). Then I switched to 7zip and only implemented old class to use 7zip. All plugins work as they did, with support for new zip('.', 'dir.7z').
I made TLuaAction which calls Execute(), Update(), Hint() procedure from its script.
Lua allso have it's own plugin system that makes it easy to add funcionality to it. Eg luacom make is easy to use COM automation, luainterface allows calling .net from lua.
See luaforge for more. There is Lua IDE made in Delphi, with source.
I tried to make an overview of all such options some time ago. Together with my readers/commenters we built this list:
DLL/BPL loaded from the program.
DLL/BPL loaded from a sandbox (which could be another copy of the program or a specialized "server" application and which communicates with the main program via messages/sockets/msmq/named pipes/mailslots/memory mapped files).
COM (in any of its variants).
DDE (please not).
External program that communicates via stanard input/output.
External program that communicates via files (file name is a parameter to the program).
External program that works via drop folder (useful for batch processing).
External program that communicates with windows messages/windows sockets/msmq/named pipes/mailslots/memory mapped files/database publish-subscribe.
The most universal method of adding plug-in capability is to use COM. A good book to get you started on the road is Delphi Com Programming by Eric Harmon. While it was originally written for Delphi versions 3 through 5, the books contents are still valid with the latest versions of Delphi.
Personally, I have used this technique along with active scripting to allow end user customization.
I'm using plug-ins to implement most of the functionality in the game engine I'm building. The main EXE is made up of a script engine, a plug-in manager, some basic graphics routines and not much else. I'm using TJvPluginManager from the JEDI VCL library. It's a very good manager, and it can add just about anything you want to your program. Check out the demos included with the package to see how it works. The only downside is that it adds a lot of JCL/JVCL code to your program, but that's not really an issue if you're already using other JVCL components.
If plugins will be developed in Delphi or C++ builder, use packages + interfaces. Delphi OTA is a good example for that.
If plugins will be language independent, COM is a good way to go.
Addition: If you won't use COM, u may need to provide SDKs for each language. And datatype handling between different languages can be pain(for example delphi string type). Delphi COM support is excellent, u don't need to worry about kind of details. Those are mostly impilicit with Delphi COM support. Don't try to invent the wheel again. I'm surprised why people doesn't tend to mention about it.
I found an article by Tim Sullivan:
Implementing Plug-Ins for Your Delphi Applications
You could have a look at Hydra from Remobjects. Not only will this allow you to add plugins, but also to mix win32 and .net.