I am trying to compile and run a really really old application on my Windows 7 box.
It seems to need NTWDBLIB.DLL from SQL Server 2000. I can get that file, but it is a 32 bit file. When I try to run RegServ32 on it I get an error message.
Installing SQL Server 2000 Client tools is not allowed on Windows 7.
Is there any way of getting this file? (Short of making a 64 bit VM and installing on it to get the file.)
I just needed to copy the 32 bit version to the SysWOW64 folder rather than the System32 folder.
Kind of lame that the folder with 64 in the name is for the 32 bit stuff and the folder with the 32 in the name is for the 64 bit stuff.
Given the error message, it looks there may be issue with SQL Server 2000 executables in Windows 7. I'd suggest you to install a newer client (2005 or 2008 with all the required SP to be run on Windows 7), they are still able to connect to a SQL Server 2000 server.
Related
According to Embarcadero's docwiki, it is possible to setup unixODBC on a MAC and compile an app that connects to a database and run it on a MAC. The instruction shows how to compile the unixODBC but does not show how to create the required database drivers, which means no database connection can be setup. Has anyone been able to successfully do this?
FYI, I am trying to connect to a Sybase ASE database. I can create the 64 bit version of unixODBC and drivers using the instruction found here and use isql to run some queries against the database, but that is useless because applications created with RAD Studio are 32 bit (for MAC). and 32 bit apps cannot use 64 bit unixODBC.
Thank you
Sam
I need to work with Delphi 6 Update 2 in Windows 8.1 x64 (in case you were wondering, it's about maintaining an old application, migrating to a newer version is not an option. I can't use a VM because I use the same machine to connect to some peripherals that don't work in a VM).
The problem is that Update 2 has a 32 bit installer with a 16 bit stub. So the current behaviour is that the installer starts, it extracts the files in a temp location, starts the setup then nothing appears on screen.
So far, I gathered that it is impossible to do it. But the same behaviour I 've seen for SQL Server 2000 (don't ask) but there I was able to use msetup.exe (DemoShield) to open a sqlservr.dbd that started the script. However, there is no such dbd file. I guess I was lucky on SQLServer 2000.
So far I've tried compatibility mode, DosBox, replacing the setup file with both Installshield 3 and 5, waiting for hours for the setup to start (sometimes, W8 does that), even comparing files and registries on an XP machine before and after update 2 but this might be a bit too risky to apply on a real machine.
Since Windows 8.1 86 includes Hyper-V for running VMs, most modern hardware supports Hyper-V, and Windows 8 x86 can still run 16-bit based apps:
Install a Windows 8.1 x86 VM under your host physical machine, then install it there.
The up-tick: it is easy to move your VM to a new host without needing to reinstall a full new VM.
See http://www.techrepublic.com/blog/windows-and-office/get-started-with-windows-8-client-hyper-v-the-right-way/7893/ and http://www.infoworld.com/d/virtualization/5-excellent-uses-of-windows-8-hyper-v-208436 to get started with Hyper-V.
Hyper-V can redirect quite a bit of hardware from the host to the VM nowadays. For "old" hardware like COM and LPT ports you often can buy USB adapters that can be redirected.
If installing on x86 Windows 8.1 works and x64 fails, I think you have proved the assumption that the 16-bit portion of the installer is the culprit.
Maybe my blog post from last year can solve your problem:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
excerpt:
I just deleted the registry entry
HKCU\Software\Borland\Delphi\6.0\LM
(I did not make a backup, what would have been the point?)
I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.
Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.
I am having problem in running windows service of 32 bit on 64 bit windows server, query that i have is as following
1) will there be any problem if a windows service( using all 32 bit DLL's) is running on a 64 bit widows server??
2) If yes then how can we make a windows service of 32 bit run on windows server 2003 R2.
every time i try to run the service event log shows me error that attempt a load a program that is with incorrect format.( Exception from HRESULT: 0x8007000B)
Can this be a problem of service having any of its dll's of 64 bit?
You can absolutely run a 32-bit service on a 64-bit Windows OS.
can this be a problem of service having any of its dll's of 64 bit?
If the service cannot find a 32-bit version of DLLs that it references, it would fail to load. If the service is written with managed code, use the Fusion Log Viewer (Fuslogvw) to see if there are any binding failures.
I am recompiling a old Delphi program (from Delphi 2007) in (Delphi 2010). The code is absolutely unchanged and it compiles well. The key part of the program is the use of CopyFileExW to copy some files. Everything works OK and Dandy, however, there are some strange performance problems that I cannot understand where they come from.
When copying from a client computer to a Windows server the following happens:
Version compiled with D2007
From XP to Windows Server 2003, Copy performance OK
From XP to Windows Server 2008 Copy performance OK
From Windows 7 to Windows Server 2003, Copy performance OK
From Windows 7 to Windows server 2008 Copy performance OK
Version compiled with Delphi 2010
From XP to Windows Server 2003, Copy performance OK
From XP to Windows Server 2008 Copy performance OK
From Windows 7 to Windows Server 2003, Copy performance OK
From Windows 7 to Windows server 2008 Copy performance EXTREMLY SLOW
I can understand that perhaps there is an issue between the 2008 server and W7, like Remote Differential Compression or such (which BTW is disabled), but why does the version compiled with 2007 doesn't have the same problem? Any guesses?
Some ideas of possible causes:
AntiVirus software on WS2008 side thinking that the transfer is suspicious and making verifications (as already stated in the comments).
Possibly some implicit string conversion getting in the way.
Since you are just now updating a program to run on Delphi 2010, you should probably go to Delphi XE and start solving problems there. It comes with a profiler built in AND you get to work with the newest stuff.
Has anybody managed to get Tomcat to run as a service on Win2008 64bit? I need it for a 3rd party component that my site relies on. It works fine otherwise, but I just can't get it to run as a service. I've tried all the googling I can, and experimented with various 64bit tomcat.exe / tomcatw.exe without success. Upgrading to Tomcat 6 didn't help either.
I'm running Java 1.5 64bit.
Download apache-tomcat-6.0.30-windows-x64 version.
Extract to c:\Tomcat6
open command prompt run as Adminstrator
and go to Tomcat6\bin directory and run from command prompt>service install
Tomcat6 will install as Windows Service.
again go to Tomcat6\bin and open tomcat6w.exe run as administrator and modify your changes.
it works cool.
Download the latest builds. Your issue was the 64 bit procrun.exe/tomcatw.exe wasn't provided. The newer installers for Tomcat 5.5 and Tomcat 6 include both 32 and 64 bit and deploy the appropriate one
Extracted from http://www.openlogic.com/wazi/bid/188180/
While the Java components of Tomcat run happily under a 64 bit JVM, the installers that build the Windows service are 32 bit executables and won't work correctly under 64 bit Windows operating systems.
Fortunately, the Tomcat team has put together 64 bit versions of these executables, although they only include them in the source distribution for each version of Tomcat. If you've already installed a copy of Tomcat, here's how to update the executables:
1) Download and extract the source distribution for your version of Tomcat from OLEX
2) Find the directory tomcat-X.X.XX-src/connectors/procrun/bin/amd64/
3) Copy the executables from the above directory into the tomcat-X.X.XX/bin, overwriting the 32 bit versions
4) Run the command service.bat install. This will install the service under the displayed name Apache Tomcat (the service name will be Tomcat5)
It worked to me! And I was looking for this solution for a while...