My application made using C++ builder XE3.
In my application i have done some xml parsing using XML.xmldoc.hpp
On XP machine when i run application it is showing me messagebox
"Microsoft msxml is not installed".
Please can anyone help me??
The error message is a little misleading. It does not mean MSXML is not installed at all. MSXML uses COM, and the error message actually means the MSXML COM object could not be instantiated via CoCreateInstance() (and the MSXML DOMVendor for TXMLDocument attempts to instantiate several different versions of MSXML before giving up). That is a subtle but important distinction to make. For instance, if you are using the XMLDocument in a worker thread, you have to make sure you are calling CoInitialize/Ex() beforehand. C++Builder does that for you in the main UI thread, but you have to do it manually in a worker thread.
Problably you need to find the msxml6.dll installer ( standard with Windows 7)
XP worked with msxml4.0
link download
Related
I have a program written in Delphi 6 that uses TXMLDocument, and during runtime it uses the MS XML 3.0 parser. But this program reports a The specified module could not be found error on one computer, and Process Monitor reports that the program is trying to access MS XML 4.0 modules and registry keys. This 4.0 installation is incomplete/corrupted and that is why the access fails with The specified module could not be found.
So, the core issue is some mechanism/decision algorithm that diverts TXMLDocument from using the standard MS XML 3.0 or MS XML 6.0 versions that are on all the current Windows 10 machine, and that presses TXMLDocument to use MS XML 4.0 version. What is this decision mechanism in TXMLDocument and how to correct it?
Of course, I can find, download, and install MS XML 4.0 on the client computer, but this seems to not be the correct solution.
There is no secret magic here. It is well known what mechanism is used. You can see the source code for yourself in Delphi's msxmldom.pas file.
When TXMLDocument uses the MSXML DOMVendor on Windows, it simply calls CoCreateInstance() in a loop to attempt to instantiate a hard coded list of different versions of MSXML's IXMLDOMDocument COM object, in decreasing order of version, until one version finally succeeds, or they all fail.
MSXML 6.0 did not exist yet when Delphi 6 was released, so it is not a version that is attempted. And you said MSXML 4.0 is broken on your customer's system. So it makes sense why MSXML 3.0 ends up being used instead.
Have a look at the following question for how to make TXMLDocument use MSXML 6.0 in such an old Delphi version:
How to create a TXML Document using MSXML 6.0 in Delphi 7?
Specifically, if msxml 4 is not present on the system, and msxml 6 is present, will the Delphi msxml component (in Delphi 2006) use msxml 6?
Q: Why don't you try it?
I presume you mean the Delphi class TXmlDocument and friends. It "expects" MSXML 4 ... but the VCL checks dynamically:
https://delphihaven.wordpress.com/2010/03/07/using-msxml6/
By default, the VCL’s TXMLDocument class will delegate to MSXML for
its actual parsing and writing. Now MSXML itself comes in various
versions, with newer ones being installed side-by-side with older
ones. To cope with this situation, the VCL tests for the existence of
a number of them, the idea being to prefer whatever MSXML version was
current when the unit in question (MSXMLDOM.pas) was last updated.
The same link also discusses how to select a "preferred" MSXML version if you wish.
STRONG SUGGESTION: Compile your Delphi .exe or .dll and test it on a "clean machine" (presumably a PC with only MSXML 6 installed) and observe the behavior.
It is not possible to test on a machine with only msxml6, because even Windows10 installs out of box with msxml3 and msxml6 present.
Delphi XE6 raises
ITaskbarList3 interface is not supported on this OS version
error at runtime on Vista and XP. It is a known issue in Quality Central and resolved in XE7.
The error comes when the TTaskbar VCL component is placed on a TForm and the application is run on OS prior to Windows 7 (such as Vista or XP).
How one can work around this in XE6?
This interface was introduced in Windows 7. It is not implemented by earlier versions. The requirements section of the documentation makes this clear. This is of course eminently reasonable since the interface encapsulates functionality that does not exist in Vista and earlier.
On a platform lower than Windows 7 you should not attempt to use this interface. My guess, although you do not state it, is that you are using a VCL wrapper around this interface, rather than the interface itself. All the same, the solution is the same. Avoid the component, or at least the code path, that uses the interface in question.
So, if you encounter the problem because you used TTaskbar, make sure that you don't use TTaskbar when the program runs on a system that does not support ITaskbarList3. Likely this means no longer creating the component using the form designer and instead doing so, conditionally, using runtime code.
Recently we upgraded our code from Delphi 2009 to Delphi XE and updated our Indy components (not sure if this is relevant).
But ever since then we have had errors on Windows Server 2003 machines when loading and saving XML files.
XMLDoc.LoadFromFile()
XMLDoc.SaveToFile()
The DLL msvcrt.dll is much smaller on Windows Server 2003 (300kb or so) compared to over 600kb on other operating systems... So its missing something in that file and its causing the error...
Does anyone know how to fix this? Or is there an alternative to TXMLDocument that I can try?
By default, TXMLDocument/IXMLDocument is just a wrapper around the MSXML COM interfaces when running on Windows platforms. Neither TXMLDocument nor Indy use the _ftol2_sse() function, or even link to msvcrt.dll. Something else in your project is at fault.
msvcrt.dll is (part of) the Microsoft Visual C++ Runtime. I think you got an older (or maybe even newer) version of this runtime that doesn't include this function.
Now you'll have to find out where this function is called. Do you link obj files with your project or use (other) 3rd party dll's?
To answer the last part ("is there an alternative?"), you might want to check out Jedi Code Library's TJclSimpleXML class. It does not require any external DLL, is quite fast, and is very easy to use. Besides, these days JCL and JVCL are a must-have anyway if you code in Delphi.
http://wiki.delphi-jedi.org/wiki/JEDI_Code_Library is their page I believe. I hear in seattle you can get it through IDEs integrated package manager.
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.