Recently, I tried to use z3 on a 32bit windows xp, and when I load z3dll using java api, it threw error message as follow:
WindowsError: [Error 998] Invalid access to memory location.
I noticed that, Z3 dosen't support Windows XP because of thread-local storage. I wonder is there any way to adapt z3 to windows xp.
Yes, there is a way, but it may involve considerable effort. Thread-local storage is used to track memory allocation sizes per thread which would otherwise have to be locked, I.e. It will be much slower. If you don't need any multi-threading you could of course just remove that part (see memory_manager.cpp). There's no guarantee that there aren't any other XP specific problems after that though; we don't test anything on XP anymore.
Also note that support for XP has ended globally (all of Microsoft, not just Z3).
I just disabled the if statement for the macro of '_USE_THREAD_LOCAL' in memory_manager.cpp and rebuild. It worked and could be loaded on windows xp now.
Related
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
I have an Delphi 7 Application that uses Halcyon dbf component. It works well in Windows ME.
Unfortunately in Windows XP data aware controls which are bound to Halcyon xBase Engine do not behave correctly. In addition pack command almost hangs the application. I tried compiling in XP. But no joy. Does that mean that API calls work differently? May be Data types mean different things....
Thanks for all help
A well written Delphi 7 application will work on any version of WIndows from 98 onwards. If you have managed to make an application that doesn't work on XP, then you should debug the problem on XP, not recompile and then give up. (no joy!? what? you're done already? Is that how you troubleshoot and debug?).
For posterity I should point out that if you change Delphi versions then of course, some things change. For example, If you build your Delphi application in Delphi 2009 or later, it will work properly on Windows XP, but not on Windows 98 or ME any more. But if you build your application using the same version of Delphi, why would you expect any changes in the application's bugs?
As David says; Rebuilding your application on a different computer, from the same code, and with the same compiler, produces the same binary. If you have a fundamental problem on Windows XP it is because you made a mistake in your code somewhere.
In general, windows 98/ME to 2000/XP was an easy transition, but that was a decade ago.
The only API I remember that was in Windows 98/ME that was not in XP, was the Windows 98 text-to-speech API which was removed and replaced with a different API in XP.
I believe your confusion is that windows contains something that affects Data Aware controls. It does not. Data Aware Controls are a purely Delphi thing, and they are not a part of Windows XP, they are 100% implemented inside Delphi. If you have some funny custom control that is badly written, perhaps it might not work. We have no idea what your code contains, and you haven't even described the nature of the failure.
You need to provide more information, or this question should be closed as unanswerable, or too localized. (My app doesn't work! Help! No other info given.)
I am really stumped.
I am running delphi 2007 on vista. I have built many applications and run them in XP with no problem. This latest app had to make use of threads. I'm pretty sure my code is correct. It runs fine on Vista, but when I run it on XP (tried multiple PC's) my program seems to lag (both os's 32 bit, XP sp3 and Vista sp1, dotnet v2). Best example being if I unplug the serial port my coms will continue to run etc.
I was installing delphi on my xp machine, and ran my program while delphi was running. As in I ran it from the exe built in vista. It ran fine then. Close delphi, and the comport starts to lag again.
If I unplug and replug a flash drive, the coms catches up again.
I want to build the app on my xp based machine, but have like a million 3rd party components that makes it a real mission to setup.
Oh fyi, i built a simple application with just the main thread, and a comport thread. Same problem. All the comthread will do is fetch data off the comport. Not even display it, i used a serial port monitor in the background to check for the lag.
Any suggestions welcome.
OK quick edit: the XP pc is freshly built. I opened msn messenger, and the program runs fine. I'm obviously missing some setting...
If you're using Sleep in your threads (hence my comment/query to your question), you should use timeBeginPeriod to indicate your desired resolution. As you've already found out it doesn't matter where you call it; can be the main thread or even an entirely different application.
See this thread on embarcadero forums, and of course the documentation (remarks) on MSDN.
Are your OS installed on two diverse PC?
I guess one of your computer has a true dual-core processor (the one with XP), and the other (the one with Vista) has a one-core processor. Sometimes multi-threaded app reveals their problem when run on true multi-core processor.
The Delphi debugger sometimes change the CPU affinity, so it could work on the debugger, but not outside it.
Another possibility to check: try your software under XP with setting affinity to only one CPU.
I've seen that before. But it's likely something else, since you said you've tried your SW in multiple PCs.
Over the past 15 years or so I've written all the software that runs my medical practice in Delphi 5.
Last week my disk became unbootable/unrecoverable. I have my original D5p disk and all the components backed up but I want to migrate to Windows7. I don't care if my delphi apps look like vista/7; I just want to be able to install it and code on the machine again for maintenance purposes.
are there any tricks to install D5 so it works in W7?
is using a virtual machine really the only/best way? if so, which is suggested?
Thanks in advance.
Larry
LKohnMD#msn.com
I don't know if this helps, but I run Delphi 7 on 64 bit Windows 7 with no problem.
There are some special steps to installing it, but after that, it works fine.
Check out this site for the details: http://www.drbob42.com/examines/examin84.htm
Although I use VMs for other things, running Delphi inside a VM IMO is a nuisance. So it'll be worth your trying the above. On the other hand, I know developers who swear by VMs for this since they can get such great backup snapshots, as noted by others.
I'm not an expert in the Delphi field any more, but I'm pretty sure you're not going to get D5 running on Windows 7 smoothly. Even if you get it running as such, it's going to give you trouble in the details.
But Windows 7's built-in XP virtual machine is a joy to use, and integrates seamlessly (i.e. you can even have Delphi and your old apps in Windows 7's start menu). I'd say the virtual machine is really the way to go. It's called Windows XP mode and can be downloaded here at no extra cost. You just need Windows 7 professional or better, it won't work on a Home edition.
We do commercial software development using Delphi 2009 in a Windows XP Virtual PC, hosted on Windows 7. Until last year, we were using Delphi 7 on an XP virtual machine on Vista. Both are excellent development platforms.
As far as I can see, there are no downsides to this setup. Under Windows 7, the Virtual XP machine integrates right into the desktop using XP mode. Backups are easy, since the VHD file (Virtual Hard Disk) is typically less than 16 GB. There have been absolutely no issues with stability. And although performance within the virtual machine is somewhat slower than on a native machine, the speed difference is not significant.
My opinion is that this is the best solution, and we have been using it successfully for years. If you have any questions about it, just let me know.
I got tired of having to reinstall all my Delphi components whenever I had to setup my machine from scratch/install a new operating system/move to a new laptop, so when I installed Windows Server 2008 (32-bit), I installed Delphi 5 in a virtual machine.
Because of that, when I recently moved to Windows 7, 64-bit, I could use the same virtual machine, no new setup required!
Granted, it is a bit slower, but, hey, this was meant to run on computers a lot slower than they are today.
It's a win/win all the way...
Two people at work are now running Delphi 5 on Windows 7 64-bit.
There is a problem with some Jedi files, that rely on a particular define (WINDOWS i think), that isn't true in 64-bit environment. In the end the Jedi files are not useing Windows.pas. Code then fails to compile when it can't find declarations such as DWORD.
Also, there is a bug in Delphi 5 compiled code, that is only exposed on 64-bit versions of Windows. If you have Overflow Checking turned on, and anything calls SendMessage, the compiled Delphi code is checking that the BOOL value is not greater than $FFFF.
This is wrong, since BOOL is declared by Win32, Microsoft, and Delphi 5, to be a 32-bit boolean value; in x64 it returns $FFFFFFFF as the non-zero value. It works on 32-bit Windows because Microsoft has to maintain compatibility with 16-bit applications; where BOOL was only 16-bits, returning $0000FFFF. 64-bit versions of Windows are unable to run 16-bit applications (this is because a 64-bit CPU running in 64-bit mode does not support running 16-bit instructions)
In other words: turn off Overflow Checks
If you have the option of restoring the original system to a working state, I recommend doing that, and the use the "VMWare vCenter Converter Standalone Client" to make a VM of your current system. Then install VMWare on the new PC when it gets here. Now you can simply bring that up under your new PC, and you've got your trusty old PC ready to roll, any time you need it.
You can do it. More over you can even deploy lower versions too.
I am running Delphi 4 on windows7 32 bit, now I tried to deploy to win 7 b4 bit.
So far the compile, building works, I can run my app outside ide.
Inside ide, I could not register correctly bordbk40.dllm this is why app is not starting from ide.
Database Desktop is also not working, saying unkown compatibility issues.
I have a plan to install my application which is compiled using RAD2010 in Vista 32 bit dev. environment, in a win 2008 server 64 bit.
I use Firebird 2.0 (32 bit) as database server.
Is there any issue? Or it should run without any problem?
No problem for this.
If you can use Firebird 2.1 (a version for 64bit server can be use).
Just take the fbclient.dll (32 bit version)
I see no reason why it shouldn't work, 32 bit processes and services work well under x64. If you need lots of memory for you application you can set the LARGE_ADDRESS_AWARE flag which gives your application access to 4GB of address space instead of 2 GB. If you want that you need to add a line containing {$SetPEFlags $20} to the .dpr file.
We have encountered 2 problems with Windows 2008 Server, but it does not seem they should impact you too much:
Critical Sections now come with a debug baggage that is cached and not freed when they are released. If you create lots of them, the memory footprint of your application will be much bigger. Can happen when using Interfaces or Threads heavily. see is-the-memory-not-reclaimed-for-delphi-apps-running-on-windows-server-2008-sp1 and critical-sections-leaking-memory-on-vista-win2008.
When using ADO, there is a memory leak (in MS stack) when passing the ConnectionString. If you close the connections and open them a lot passing the ConnectionString you end up eating all the memory after a while.
The only problem is if your application is library that needs to be loaded into a 64bit Process.
Examples:
Shell Extensions
ISAPI applications