I have a JScript script which is called by cscript. That script creates Visual Source Safe ActiveX object using new ActiveXObject("SourceSafe") code in it's internals.
Everything was ok on 32-bit windows. But on 64-bit windows I need to call 64-bit version of cscript and still use 32-bit ActiveX object (SourceSafe). 64-bit version of cscript doesn't see that ActiveX class (because 32-bit class is in 32-bit branch of windows registry).
Is there any way to create that object from 64-bit cscript? (except writing 64-bit automation adapter for SourceSafe ActiveX class)
I have created COM+ server which aggregates SourceSafe COM component (see MSDN). It took less than a minute. After that I can create SourceSafe object in out-proc server using the following simple code:
WScript.CreateObject("SourceSafe")
How it works (my understanding): COM+ 64-bit out-proc server marshals automation calls to COM 32-bit out-proc server which delegates calls to 32-bit in-proc server.
Related
Are there any problems with programs that are compiled with Delphi 2010, using Rave reports (no database connection) running on Windows 10?
In principle, there's no reason why a program compiled with Delphi 2010 will not work perfectly well on Windows 10. Indeed, a program compiled with any 32 bit version of Delphi (Delphi 2 or later) can, in principle, be executed on Windows 10.
The usual caveats apply though. You have to make sure that your code respects features like UAC. So don't attempt to write to HKLM, system directories, etc. as standard user.
As a broad guideline, if your program executes on Windows 8.1, you can expect it to execute on Windows 10 also.
So, in summary, you should be perfectly capable of producing a program that runs on Windows 10 using Delphi 2010. However, it's impossible for anyone to tell you definitively that your program will run because only you know the full details of how your program is implemented. You should test your program on each new operating system as it is released, if not before it is released.
I'm not sure, but the internal Kernel ID from Windows is set from 6.x (Windows Vista - Windows 8.1) to 10.0 (Windows 10) so this can be a problem.
Situation:
I developed a DelphiXE5 ISAPI Webbroker application on a VMWare workstation under WIndows 7 Pro 64Bit. Testing on that platform with the code compiled as 32bit (default for DelphiXE5) was successful. The program consacts Stamps.com via HTTPS and uses the Stamps.com SOAP web application to purchase postage and create a mailing label with a valid postage stamp (indicium).
The mailing label is created as a PDF on a Stamps server and they send me back a URL which I then use to fetch the PDF and save it in my local SQL Server database. This fetch is done using INDY 10.6.0.5040 (per Remy at Indy). As part of that fetch, the INDY ssl component has to load and use the OpenSSL libraries. These load OK in the test environment.
I then moved the program (compiled as 32bit) to the Windows 64bit 2003 R2 server. This server is a virtual server running under VMWare. I am sure that the actual hardware is truly 64 bit. The OpenSSL libraries will not load on that server. I have tried the most current 32 bit libraries and the most current 64 bit libraries. Same result ... not loading. I tried the ones that load successfully in test .. they failed. Using the Indy WhichFailedToLoad() function shows "failed to load libeay32.dll". Funny thing is , I get the same message with the 64bit libraries. The libraries, even though 32 vs 64 bit, have the same name, so i get the same message. Now, my specific questions are ....
could there be a default area that the libraries load from and my placing them in the same directory as my program dll is not changing anything at all ?? Indy is going the default first and if they exist, that's the ones it is using. If so, does anyone know where that might be. I have tried to trace through the INDY code to see what was hapening but it jumps into assembler and I'm not a ms assembler programmer. I know IBM mainframe assembler in my sleep but MS seems uside down and backwards to me :-)
For Delphi experts out there.... SHould the program really be compiled as a 64 bit application and put in production and then use the 64bit libraries? In the test environment I'm running on 64bit hardware, 64bit host, 64bit guest on which the 32bit compile takes place. The 32 bit libraries work there and it seems that it should work in production on W2003 Server as that is identitical .. except for the OS version.
Could it be permissions problem with IIS 8.5 that wont let my dll read or load the OpenSSL libraries ? If so, any hints as to what ?
I have the DLL in the scripts directory along with libraries.
Who ever figures this out can get a job as my backup :-) ... really !
If your program is 32bit, the dll it uses have to be compiled in 32bit.
As for the location of the OpenSSL dlls, in my case, on a Win2012 R2 server, I put them in C:\Windows\SysWow64\inetsrv.
We have an Delphi application that has a built in com object. When compiled in Delphi XE3 (Windows 8) we can't reference it from Visual Studio C#. However, an older version that was compiled in Delphi 2010 (Windows 7) works as expected.
The com object registers without errors and i can access it by using VBA script in Excel. Has anyone come accross something like this?
The most likely explanation is a bitness mismatch. I'm assuming that the COM server is 32 bit since you have been compiling it in Delphi 2010.
Suppose that your COM server is an in-proc server. Then I guess that your failing host is a 64 bit application. If so then you need to make the bitness match. Most probably by switching your host to be 32 bit by targeting x86.
If the COM server is out-of-proc then the issue is with registration rather than executable bitness matching. It will be registered in the 32 bit registry view, but your 64 bit host is looking in the 64 bit view. This would explain why your 32 bit Excel VBA code can find it. You need to register the server in both 32 and 64 bit registry views. Or switch the host to 32 bit.
I have a COM object, originally compiled under Delphi 2007, 32-bit. Now I have ported to Delphi XE3 using 64-bit compiler. It compiles successfully with a new 64-bit DLL but I just can't get it registered.
I am using the Admin to register the DLL, it works fine for 32-bit DLL but not for 64-bit.
It keeps saying 'Invalid Access to Memory Locations'
Any hints here?
PS: the command i use is simply %systemroot%\System32\regsvr32.exe test.dll.
When registered in Windows 7 64-bit, it shows 'Invalid Access to Memory Locations'; when registered in Windows 8 64-bit, it shows 'A dynamic link library initialisation routine failed'.
Yes, i found the cause.
In initialization section of one of the unit, it still uses third party 32-bit floating operations.
After I remove the code, it successfully registers the DLL.
On win7, the errormessage is confusing, but on win8, it says "'A dynamic link library initialisation routine failed', which gives a clearer cause.
My Windows driver has a .sys file and a .dll (which I'm guessing is the programming interface to the driver?). Anyway, I need to compile the driver to run on Windows 7 64-bit. I have downloaded the DDK and am able to compile everything, but my application still won't work with the new driver.
If the application is a 32-bit application, does the driver DLL need to be compiled as a 32-bit DLL, and the .sys file a 64-bit file? Or do the SYS and DLL files both need to be 64-bit?
On a 64-bit system:
driver should always be 64-bit
an application can be either 32-bit or 64-bit
a DLL used by an application (that is, a DLL an application links with) should be 32-bit for a 32-bit application and 64-bit for a 64-bit application
If a DLL is engineered to communicate with a device driver, it should be carefully written to use the same data type definitions as the driver. It's best if both the driver and the DLL avoid using data types that are defined differently for 32-bit and 64-bit (e.g. size_t) in structures that are used for communicating with each other.
However, this does not mean that the DLL should be built as a 64-bit DLL (i.e. using the x86-64 instruction set). It should use whatever instruction set the application linking to it will be using.
The DLL has to be 64 bit too.
Will try to find a reference.
Got one
Since a 64-bit program can't call a 32-bit Dynamic Link Library (DLL)
This is why no 32 bit driver works on 64 bit and why they are always separate downloads