I'm using ACOS3X smart cards in my Delphi application for user authentication. Everything is fine in Windows XP, but in Windows 7, every time I put the card into the reader (which is ACR38-CCID), windows tries to install a driver for it, to no avail. This does not affect my application in any way, but it's really annoying. Should I write a driver for my card just to satisfy Windows 7? And, if yes, could someone please tell me if it's possible to create drivers with Delphi?
This is what Windows 7 (and IIRC also Vista) does. If you insert a smart card, it tries to locate a minidriver through Windows Update.
Not sure if it works, but you can maybe modify Windows registry to include the necessary entry for your card (but not point to a working implementation).
Look into Windows Minidriver Specification (available from MS) and the "discovery" section in that document.
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 developed an app for computers a while back, that generates a word document and saves it automatically under a name provided by the software.
The application has worked perfectly in windows xp and windows 7. But now it needed to be moved to a windows 8.1 computer and since the generating works perfectly. But the save command wrdDoc.SaveAs(SaveToFile); does not work.
Basically what happens, is on that command's execution a save dialog appears and you can save the document yourself. After you click save. You get an error command failed with no further details.
Is there anything that has changed since windows 7 that prevents this code from executing properly?
The old computer used the following:
windows 7
office 2007/2010/2013(all were used at some point in time)
New computer:
windows 8.1
office 2010
UPDATE:
it is also worth noting, the dialog does not show any of the word documents in the folder if i browse there... Can this be a hint to the problem?
Resolved
I managed to find the problem. It's a brand new laptop, and Acer had a bunch of crap installed that sync's with office and explore. Once i uninstalled that the software returned to working normally...
Thank you guys anyway so much :)
It depends on your word version. Only 2007 has a "Saveas" method for the document object (https://msdn.microsoft.com/en-us/library/bb221597%28v=office.12%29.aspx). The later versions (2010 and 2013) only have a "Saveas2" Method (https://msdn.microsoft.com/en-us/library/ff836084.aspx)
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.)
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 developed an application using also third party components (developed on D7, WinXP).
When I deploy this application on XP everything works fine. When I run it on Vista, the application cease to work properly:
Toolbuttons on Toolbar does not size equally, when I switch visibility on/off, thats why (third party) skins are not properly nested and then it looks ugly. It bothers, it's annoying but it is not fatal as the next point.
Third party text processing component cease to write. I wrote some routines, which allows writing on this component under certain circumstances. It was a big shock to find out, that I can not write anything (probably these routines return false for writing, but I do not see any reason, why on XP it should work fine, but on Vista not).
The application runs (at last), but not in the way, like it supposed to !!!!
I would like to debug it, but how?
Should I install Delphi 7 on this problematic Vista computer and compile project on it? (this is it, what I am going to do...)
Is it problem of third party components?
Is there any possibility to use some compiler directives to ensure, that application will run on Vista flawless ? (be honest I do not know if Vista is to claim in general).
Is Delphi 7 too old for Vista?
NOTE:
When I run the same application on Win98, I get error message about invalid floating point operation...
Has anybody solved such problem?
Thanks
If Delphi 7 is compatible with Windows Vista, it only really means one or both of the following:
You can run Delphi 7 on Windows Vista
Delphi 7 can be used to write programs that can run on Windows Vista
It does not automatically mean that
All programs I create in Delphi 7 runs on Windows Vista
All programs I create in Delphi 7 runs properly on Windows Vista
Let me give you an analogy: That you can use a hammer to get a nail into your wall without hurting yourself does not mean that no matter what you do, you won't hurt yourself.
If your program, either in your own code, or as part of the third party components you use, use parts of Windows that has changed or possibly even been removed (although that's far less), then you need to fix your program, there's no way around it.
There's no silver bullet either, so no compiler directives or whatnot. The most I can think of is that perhaps Windows Vista has some compatibility settings for the shortcuts that might turn on some XP-compatibility layer in Vista that fixes the particular issues you have.
However, the only long-term solution is to change your program so that it is properly compatible with Windows Vista, and probably Windows 7 as well.
Since you say you're using third-party components, have you verified if the particular versions of them that you use happen to be Vista-compatible? You need to go check on the websites of the authors to find that. Perhaps it can be solved by simply upgrading those components.
However, it might also be that you need to make changes to your own code.
The best way to move forward is to install Vista and possibly Windows 7 and start debugging to try to find the underlying cause of the problems.
Note that just installing Delphi 7 on Vista and recompiling will not fix anything. The compiler does not produce a different program if you compile it on a particular Windows version. Only changes to the code will apply the necessary changes.
The easiest solution is to make sure your Delphi version and 3rd party components are Vista compatible.
Delphi versions since 2007 are.
Recent TMS, DevExpress and Raize components are.
The hard solution is to do all the changes yourself.
Be prepared to modify the VCL sources from 2002, carefully modify them to bring them up to Delphi 2007 level.
Then do the same for your 3rd party components.
--jeroen
I never really investigated, but I noted that in some apps that I have, in all skinned modes (XP-teletubbie, and Vista/W7 non classic) I had paint artifacts with all delphi verrsions if I put buttons and labels directly on tframes or ttabsheets.
The problems went away when I inserted a panel inbetween.