On my Windows 7 system, the GetVersionEx Windows API function returns "6.0", indicating Windows Vista, when it should return "6.1".
If it matters, I used the following Delphi code:
function winver: string;
var
ver: TOSVersionInfo;
begin
ver.dwOSVersionInfoSize := SizeOf(ver);
if GetVersionEx(ver) then
with ver do
result := IntToStr(dwMajorVersion) + '.' + IntToStr(dwMinorVersion) + '.' + IntToStr(dwBuildNumber) + ' (' + szCSDVersion + ')';
end;
and the string "6.0.6002 (Service Pack 2)" was returned.
Isn't this highly odd?
I now found that GetVersionEx returns Vista when my application runs through the Delphi 2009 debugger, but Windows 7 when the application is executed alone. I also found that RAD Studio (the Delphi IDE) actually runs in compatibility mode for Windows Vista SP2. Hence everything makes sense, for, as pointed out by kibab, a child process will "inherit" the compatibility settings of its parent process.
Is your executable running with any compatibility settings defined (I assume this might be the case for legacy Delphi applications)? The documentation of GetVersionEx states:
If compatibility mode is in effect, the GetVersionEx function reports the operating system as it identifies itself, which may not be the operating system that is installed. For example, if compatibility mode is in effect, GetVersionEx reports the operating system that is selected for application compatibility.
Maybe GetProductInfo can do what you want?
I think it may just be you. i.e. your D2009 may have been marked by windows, as needing to run in compatibility mode.
I made a test app with your function, and compiled and ran both with D2009 and D2010, inside the debugger and externally (click the exe in windows explorer), and for all 4 cases, it came back with: 6.1.7600 ()
Running on Windows7, 32-bit.
Related
It is probably me being stupid, but I am having problems detecting if a network drive is up, but only when running the program in the IDE – when running the program outside of the IDE, the network drive is correctly detected. The IDE works fine on Windows 7.
While the program in question is different, I can reproduce the issue by creating a new project and adding the following into the Forms OnActivate event:
var
bRet: Boolean;
LTemp2: string;
LFreeSpace: Int64;
LTotalSpace: Int64;
begin
LTemp2 := 'T:\';
bRet := GetDiskFreeSpaceEx(PAnsiChar(LTemp2), #LFreeSpace, #LTotalSpace, nil);
ShowMessage('GetDiskFreeSpaceEx: Drive T: is up? '+BoolToStr(bRet, True));
end;
Assuming I have a networked drive T:, if I run the program in the IDE then the above always returns False, but if I run the built program from a desktop shortcut then it returns True. I get the same behaviour if I run it via a button click after the program starts. Doing DiskSize() and FindFirst() on the root directory give the same results.
It is a clean Windows 10 install, not an upgrade, with a clean install of CodeGear 2007 with all the patches applied. I have tried “Run as administrator” and all the Compatibility Modes back to Windows 7.
Am I doing something stupid?
After R. Hoek's great insight, and while it does not fully sort out the issue, it is at least enough for a workaround. By the way, at least in my case, it does not matter if I launch Delphi 2007 with "Run as administrator" or not.
I added a TOpenDialog hooked up to a button: once I run this and select a file on T: then GetLogicalDrives() works fine.
So what I now suspect is that I installed Delphi 2007 as an administrator - not sure how, but I think I will re-install everything.
Even if that does not resolve it, and since it only occurs in the IDE and not in production usage, I can add code to pop up a TOpenDialog if GetLogicalDrives() returns 4.
Weird. Thank you all very much.
By the way, one aspect of this discussion may not have been clear: Delphi 2007 was running under the user account (and it could see the network drive without problems) - it is only the program which is being debugged that cannot see the networked drive. That is why using the TOpenDialog resolved the issue (until Delphi or the computer was restarted).
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.
I'm migrating from XP to Windows 7 64 bit. My app which I compiled on my XP machine works properly on XP. However when I run the exe on my W7 machine, the list of voices returned by GetVoices is as follows:
Microsoft Anna
Microsoft Mary
Microsoft Mike
Sample TTS Voice.
Checking the W7 Speech Properties dialog shows that only Microsoft Anna is loaded on the machine. Checking the registry at HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Speech/Voices confirms this.
Recompiling my app on my new Windows 7 development machine creates an exe that duplicate the above behavior. (The XP compiled code and the W7 compiled code reproduce the same error when executed under W7)
I'm developing in Delphi 7 on Windows 7 64 bit and I'm using the Microsoft Speech Object Library (Version 5.4) (note: 5.4 is what shows in the Import Type Library list).
I installed SpeechSDK51.exe onto my W7 machine. This came from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5e86ec97-40a7-453f-b0ee-6583171b4530&DisplayLang=en
The following code produces the list of 4 voices on Windows 7 even though there should only be one voice:
procedure TForm1.FormCreate(Sender: TObject);
var
i: integer;
SOToken: ISpeechObjectToken;
SOTokens: ISpeechObjectTokens;
begin
cbbVoices.Clear;
SOTokens := SpVoice1.GetVoices('', '');
for i := 0 to SOTokens.Count - 1 do begin
SOToken := SOTokens.Item(i);
cbbVoices.AddItem( SOToken.GetDescription(0), TObject(SOToken) );
SOToken._AddRef;
end;
end;
Any suggestions on how to deal with this problem?
thanks,
shawnh
Microsoft Anna is the only 64-bit voice you have
the other ones are 32-bit engines.
Your system can only use the 64-bit engine(Anna) so only this one can be selected in the panel. But the other ones are installed as well. If you open this file: /%Windows%/SystemWOW64/Speech/SpeechUX/sapi.cpl you will see a dialog similar to the one for the control panel but now you will be able to select any one of those voices as the standart voice.
Unconfirmed yet, but I think that Microsoft Sam, Microsoft Mike and Microsoft Mary do not work on Windows Vista and later.
I guess you could install them with the 5.1 SDK, so they are reported back when you query the voices, but being possibly not compatible with the 5.4 engine, they cannot be used.
You may want to filter GetVoices with the EngineProperties attribute to limit what is returned.
Disclaimer: all this is untested/guesswork/doc-reading....
I try to debug a COM+ DLL in Delphi 7 in a Win7 environment. How can I do this?
It's possible with a work around.
1 unregister from Com+ the dll
2 run as administrator in cmd : regsvr32.exe
3 Make a break point
4 In Delphi 7 Run -> Parameters : Host Application : Exe Application that use the interface dll
so the step 2 is the key ...
If it is mostly the debugging you are concerned about, not necessarily debugging in Windows 7 64, you could set up a virtual computer running Windows 7 32 bit, or, since you seem happy with older technologies, drop back to XP. You'll need to set up your development environment there, but at least you'll have a full running virtual machine that you can back up or move if you want to.
I searched around but I couldn't find a straight answer to these questions, only bits and pieces: if I install windows seven x64,
1 - will I be able to use delphi 2007+ as I'm used to aka start it, code in it, debug in it, compile in it ? I've seen the debugger issue and the hex edit workaround.
2 - will my application compiled in that environnement work on 32 bit versions of windows ?
3 - will my application I compiled with delphi on 32 bit windows work this 64 bit version ?
(of course all this is assuming "normal" applications as-in I don't expect things to work if I'm playing with pointers expecting them to be 32 bits long, obviously)
The overall question of this would be, as someone who is moving to windows seven 64 bits, will I be able to/should I use this as my main delphi developpement platform or will i be better off keeping a 32 bit boot for delphi dev ?
Thanks to anyone who can give me a clue about this
As Mason Wheeler stated, there's a problem with the 2007/2009 debugger and 64-bit platforms but it can easily be fixed.
I'm using D2007 (with this fix) on Windows 7 64-bit on a daily basis and it works just great.
There is now a hotfix for this.
No idea about Windows 7 64 bit version, but I have been using Delphi 4, 5, 2007 and 2009 for nearly a year now on Windows XP 64 bit, and given the effort Microsoft spends on backwards compatibility I don't see why things should be very different on Windows 7. This answers your last question - no need to keep a separate partition. Use virtualization for running things on a 32 bit system. Windows 7 does AFAIK offer you a virtualized Windows XP subsystem - at no cost, but you may need to download it separately.
Re 2. and 3.: The OS an application is compiled on does not matter for the deployment, as long as the compilation itself works. I have only ever been compiling 16 bit Delphi programs on 32 bit Windows versions, without problems. You should however always test on clean installations of your target OS versions, as a developer PC is sufficiently different from a user PC to not assume that everything will just work. This however is general advise, and has nothing to do with a 64 bit OS.
Your Delphi programs will run on a 32 bit layer (WOW64 - Windows on Windows 64) of Windows 64 bit which is close enough to the real 32 bit OS that you do not need to care about it, unless you work very closely with the lower system level.
I was doing some work on Delphi 2007 under Windows 7 64-bit yesterday, and it was a disaster. Every time I'd leave the program while debugging, either by quitting out normally or by stopping the debugger, it would raise an assertion failure that I couldn't get out of, bringing down the entire IDE. (This never happened under XP.) Apparently the WOW64 emulator isn't quite as stable as it ought to be... :(
If you're going to try to work on Windows 7 64-bit, I'd strongly recommend upgrading to Delphi 2010, which was built specifically with Windows 7 compliance in mind. If that's not an option, then at least install a VM with XP on it for your dev work.
Answers are:
1. Yes - With the workaround for the debugger issue
2. Yes - Delphi 2007 (native) will only build 32 bit applications
3. Yes - Unless it's a Device Driver or low-level service
First apply the patch as mentioned on Olaf's Blog. This fixes the debugger exit error.
Second, Install Windows XP Mode, which is a fully clean (and legal) windows XP 32bit virtual machine.
Compile application on Windows 7 64bit. Install onto the virtual machine. It should just work. Rinse, lather and repeat for other applications you are developing.
XP Mode is available to all owners of Windows 7 Professional and Ultimate editions. Don't know about corporate editions.
This is what I'm currently using for development as I had to perform an emergency OSectomy of a Macbook Pro
I run Delphi 2007 on Windows 7 Professional 64 bit and it was fine for a bit until a patch Tuesday a while ago. The IDE would die after throwing the debug error (SetThreadContext failed). I applied the patch found at http://cc.embarcadero.com/item/27521 and no more problems.
HTH. YMMV.
Doug
FYI, I am running Delphi 7 on Win7 64-bit. The trick to run this version is to NOT install to the Program Files(x86) folder - instead, install to something like C:\Delphi7. Been working with it this way for about a month now with a pretty heavy development load and it works great!