I'm running 64 bit version of Windows 8.1
Times ago I developed a win32 application that creates and access some keys in the windows registry, in a path like:
HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE
Today, in the 64 bit world, I've seen that without doing any changes in the source code, my old 32 bit application creates and access the same keys in a new path:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MY_SOFTWARE
Thanks to a redirection done by the system, with complete transparency from an application point of view.
If I compile my application to be a 64 bit software, will it write under a "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6464Node\MY_SOFTWARE" node or back to the standard node "HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE" ?
Since these keys are accessed by other applications (third party applications both 32 and 64 bit), should I write the keys both in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MY_SOFTWARE and HKEY_LOCAL_MACHINE\SOFTWARE\MY_SOFTWARE
paths so that both 32Bit and 64Bit external applications can see them?
Related
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
I am currently trying to get a list of all autoruns, but I am struggling on a 64-bit system. When I use:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion\Run", False)
It shows me entries from:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run", False)
Anyone know why and/or how to fix this?
I should also state that the items in HKLM\..\Run are different to those in HKLM\..\Wow6432Node..\Run.
Your process is a 32 bit process and so, on a 64 bit OS, the registry redirector comes into play. The HKLM\Software key is redirected and there are two views of it, a 32 bit view that your process is finding, and a 64 bit view.
It is true that if you run a 64 bit process, you will see the 64 bit view of the registry. However, that is not the full story. Windows processes CurrentVersion\Run entries from both 32 and 64 bit views of the registry. So, if you just switched to an x64 or AnyCPU process you would then be missing the autoruns stored in the 32 bit registry view.
So, since your goal is to list all the autoruns, you will need to read both 32 and 64 bit views of the registry. You can do that using the RegistryView enumeration that was introduced in .net 4. This allows a 32 bit process to access the 64 bit view of the registry. And indeed it allows a 64 bit process to access the 32 bit view of the registry.
If you want a process that runs on both 32 bit and 64 bit systems you will need to target either x86 or AnyCPU. And then use RegistryView to read both views of the registry if you detect that you are running on a 64 bit system.
That's happen because your application is compiled for x86 platform and running on a 64bit operating system. There is a comprensive article on Registry Redirection on MSDN
The registry redirector isolates 32-bit and 64-bit applications by
providing separate logical views of certain portions of the registry
on WOW64. The registry redirector intercepts 32-bit and 64-bit
registry calls to their respective logical registry views and maps
them to the corresponding physical registry location. The redirection
process is transparent to the application. Therefore, a 32-bit
application can access registry data as if it were running on 32-bit
Windows even if the data is stored in a different location on 64-bit
Windows
You could fix the problem compiling your application for AnyCPU platform
Here's my scenario: the company I work has applications deployed to a 32bit Windows 2003 server and they want to move to a Windows 2008 Server that is 64 bit. It has been noted that these 32bit custom developed applications will not run on a 64 bit machine. I was not aware of this.
I have always thought that 32bit software CAN run on a 64 bit OS and just use the 32bit address. A 64 bit software on the other cannot run on a 32 bit OS. On a 64 bit, one does have to create 64 bit software but can and still also create software that is designed for 32 bit machines.
Can someone please elaborate on this?
In general, 32-bit applications will run under a 64-bit Windows (This is technically called WOW64 - Windows On Windows). This applies to all 64-bit Windows version to date, including Server.
WOW64 processes are marked in task manager with *32, For example: chrome.exe *32. Sysinternals' Process Explorer has a separate column for this: Image Type (64 vs 32-bit).
If the app has components hosted inside other processes, then those components must accommodate processes they're hosted in. Examples:
Shell extensions are hosted in explorer.exe, whose bitness matches the OS' bitness. Therefore, you should compile the extension in both 32- and 64-bit, and register the one matching the OS' bitness during installation.
Kernel-mode driver are hosted in the Kernel, whose bitness also matches the OS' bitness. So, the above applies.
Winsock LSPs (Layered Service Providers) are hosted in all processes, both 64-bit (native) and 32-bit (WOW64). Therefore, you should compile the LSP in both 32- and 64-bit, and register both in their respective catalogs during installation.
There are also considerations regarding file redirection (System32 / SysWOW64 / SysNative) and registry redirection (Wow6432Node), which I will not go into.
In general, 32-bit applications will run under a 64-bit OS. If your app relies on a 32-bit kernel driver (say, a VPN client), then you will have to port to 64-bit.
I know that with Vista you can generate a dump file by goigg to task manager->processes-> right clicking on the process.
Is this option available in other versions of windows meaning Windows 7, Windows 2003, Windows 2008 etc?
It is available in Windows 7 and 2008, but I don't know about Windows 2003. One thing to keep in mind is that on a 64 bit version of Windows, there are actually two versions of Task Manager - one 32 bit and one 64 bit. If you use the 64 bit, you'll get a 64 bit dump, even if the process is 32 bit. I.e. you'll get all the Wow64 in the process as well. However, if you use the 32 bit version of Task Manager, you'll get a 32 bit dump without the Wow64 stuff. The latter is significantly easier to debug as the abstraction layer isn't present in the dump.
To collect a 32 bit dump, by opening a 32 bit task manager found at C:\Windows\SysWOW64\taskmgr.exe
Check in process explorer that it has a (32) to it
I'm migrating my development workstation from 32-bit Vista to 64-bit Vista.
The production platform is 32-bit Windows Server and SQL Server 2008.
Does anyone know of any issues with migrating the code base?
EDIT:
the system consists of web forms, c# code, stored procedures.
there is also ajax.net, ssrs, ssis, and dynamic reports/graphs from dundas.
however, i think other users might appreciate any lessons learned or feedback in general regarding this move.
FINDINGS:
As of Jan 24, 2009
Checkpoint VPN does not support Vista 64 (actually it seems that very few do)
Cropper utility required special download and rebuild to work on Vista 64 (Cropper looks very nice, but it lacks scrollable window capture)
The lack of support for Vista 64 made it not worth while for me. I wish someone would have mentioned the lack of VPN support, but there is currently no vpn vendor that supports 64 bit clients.... So be forwarned - as of 1/28/2009 - using Vista 64 is not a good option for those of us who need vpn.
I have done exactly this - migrated my workstation to Vista 64 whilst still deploying code to 32-bit Win2008 servers.
Generally, your biggest problem will be the WOW64 emulation layer - which means that 32-bit processes and 64-bit processes see different versions of the same resources (registry keys, system folders, and so on.) In .NET, there's an enumeration System.Environment.SpecialFolder which will give you safely abstracted access to Program Files, Application Data and other potentially risky system folders. You'll also need to force IIS to run in 32-bit compatibility mode (it can't run 64-bit and 32-bit web apps simultaneously) - instructions at http://support.microsoft.com/kb/894435
There's nothing insurmountable, though - I'm successfully compiling COM-visible .NET assemblies on Vista x64 (setting the compiler to target x86 CPUs), and then deploying them alongside ASP.NET and legacy ASP code running 32-bit COM objects on a 32-bit server, and it's all working very well. There's some notes you might find useful posted on my blog; biggest headache I encountered personally was that 32-bit applications (including my favourite text editor) can't see C:\Windows\System32 any more... but even that's easy enough to work around.
Don't use hard coded names for system folders.
(a bad idea anyway)
I have come across one issue with Vista 64:
Program Files
Program files may be stored in Program Files x86 or in Program Files you may have to code around this if any of your code makes assumptions about where programs are stored - even if you have done the right thing and used environment variables, as there are 2 locations there are now 2 different environment variables. You need to know which of these your app will be installed in, which will be different if you target any CPU from if you target x86.
I had much trouble with adding 3rd party 32 bit ISAPI handler to IIS on 64 bit w2k3 server (php) I had to make IIS run in 32 bit compatibility mode. If it's all managed I can think of no serious problem though.