As per requirement we have written one custom GINA. I have observed one interesting behavior in Windows XP 32 Bit(SP2). Customized GINA internally calls windows default Windows GINA (msgina.dll) and shows one extra window as per our requirement.
I used to do remote desktop to XP machine from my machine. After replacing Windows GINA with customized GINA I tried to log off from the XP Machine (I am Using Remote Desktop Connection to log in), Log off completes successfully (After showing saving your settings, Closing network connections etc) and I will get log in screen which we get during log on, this is not expected compared to other flavors of Windows OD.
Where as in other operating systems such as Windows XP 64 Bit/ Windows 2003 32/64 Bit even after replacing the Windows Gina with custom GINA remote desktop session closes after log off from the machine. I have tried installing Novell GINA on Windows XP 32 Bit but I have not find any issue with that.
I have Tried upgrading XP SP2 to SP3, still I am facing the same issue.
Has anyone else faced such issues when working with Windows GINA?
I cannot say that I had the same issues. Are you passing most of the functions through to msgina or do you do a lot of custom processing (and replacing the original code)?
My custom GINA was a very shallow wrapper of existing functionality and worked perfectly fine on Windows 2000, XP and 2003.
However, as to the differences in behavior: XP x64 is based on the Windows 2003 Server code base. So this could well explain some of the similarities between those and differences to "vanilla" XP.
Related
I have a slight problem... I need to connect the Windows Phone 6 emulator to internet. That requires Virtual PC 2007. However, VPC 2007 is not supported for Windows 7. When I try to run the setup program Windows tells me the program is blocked due to compatibility issues. Running the setup file in Compatibility Mode didn't help either.
What to do ? o_O
I've used the method described on this blog dozens of times. It has workaround instructions for 32 and 64 bit Windows 7.
We are migrating our applications from windows xp to windows 7. One of the application is window and mouse hook. same code is working fine in windows xp but it is not working in windows 7 target machine(windows 7 installed with our own software platform).
One important thing is its working fine in my personal laptop which is having windows 7 os
i dont know what is happening...
please help me to resolve this...
There are increased security features in Windows 7, and that's probably what you're running into. Try running your app as administrator on your target machine (right click, run as admin).
I haven't tried such a hook in Win7 myself, but I saw this happen from XP to a Vista box.
I have found the answer. actually our application does hook every process we create. i have created 32bit dll. target machine is 64 bit so every process is 64bit right. so it tried to load my hook dll(32bit) into 64bit processes. we cannot load 32bit dll into 64bit exe...... :)
I have a setup created using Vb6. I am unable to install it under Windows 7. Windows 7 is not registering OCX controls included in the setup.
Same setup works fine under Windows XP and all other previous Microsoft operating systems.
Windows 7 OS is 64 bit.
Also, I have tried all compatibility mode which is available under Windows 7 without much luck.
Unfortunately I don't have source code with me. Otherwise I could have ported entire source to Dot Net.
Is there any way to get additional languages in Virtual XP Mode under Windows 7?
Thanks,
kreb
From my testing of XP mode it appears that its just a VM running on Windows Virtual PC where the VM add-ons provide hooks for Windows 7 to run any application that's installed on the VM. The key thing appears to be Windows Virtual PC and the add-ons, since you can have Windows 7 installed on the VM just as easily as XP.
I don't see why you couldn't have multiple VMs running different languages if that's what you're looking for.
Thanks, for the interest..
Anyway, I managed to make it work by inserting a physical Windows XP CD (Simplified Chinese, SP2) in and getting the language files from that. WinXP complains that the files are the wrong version though and that they're not the ones used by the install media, which in this case is an MSI that I got from the Microsoft website. So yeah, just ignore the warnings, reboot, you should be good.. :)
We have a Server/Client cybercafe management application which used to work fine on Windows XP and Vista but now fails to run on Windows 7.
The Client was supposed to get 'Locked' on Client PCs of the Cybercafe, meaning it replaced Windows Explorer by changing the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell"
to the path to the Client application's EXE file.
This worked just fine on Windows XP and now on Windows 7, neither Explorer.exe nor Client.exe are run and just a blank, blue screen is shown.
We thought it might have something to do with UAC so we disabled it, with no luck.
When we managed to start Explorer.exe on the Client PC through another computer, and used the Explorer window to open Client.exe, the Client started just fine.
(Note that running Explorer.exe didn't start Windows Shell and just opened an Explorer window, since the registry key was pointing to Client.exe and Shell doesn't start unless the registry key points to Explorer.exe)
Ideas, everyone? Any big difference between XP and 7 in this area?
Fixed it. Hope someone finds this useful:
A 32bit app running on 64bit Windows can't access certain areas of Windows Registry. The request to access that section is routed to some other key. That's why our application couldn't lock on Windows 7 (It was a 64bit Windows).
Changing Client.exe from x86 to "Any CPU" in Visual Studio fixed the problem.
However, it was still necessary to disable UAC to allow the Client to work.