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.
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
Just a simple question: Is there any way to run a program compiled under a 64 bit Windows environment (with mingw64) on a 32 bit machine? Any DLL or any compatibility layer which I can use?
If you are talking about a 32-bit processor, then no. But if you are running a 32-bit OS on 64-bit hardware, then you can do it with VMWare. A 64-bit guest can run on a 32-bit host, if the hardware supports it.
Bochs should do the trick, but you'd need another copy of Windows to run in the virtual machine. (Some editions of Windows include additional licenses for virtual machines, so you might be in luck.)
Performance would probably be very poor.
No you cannot do this. The other direction is possible through an emulator, e.g. on Windows it is called WOW64.
It is standard practise on platforms that still have large install base of the 32-bit versions of the OS to ship either just a 32-bit version, or both 32- and 64-bit versions.
I can recommend VirtualBox for this purpose, you can download the free version and it's easier to use than VMWare. However you will need a 64bit installation CDROM, and storage space for a full system install, and if you are installing Microsoft Windows they will expect you to pay for a license key.
Also your CPU needs to support both 64 bit mode in the hardware, and the vt-X/AMD-V features (most of them do). It's a bit slower, although mostly that seems to be the display that slows it down, not the internal program calculations. This is NOT an emulation, the CPU is really running native 64 bit, but VirtualBox fakes the hardware devices (display, disk, network, etc) so the result is not as nice as running normally. 3D graphics acceleration is available, but it has limitations.
An easier option is simply to hire an online Virtual Machine by searching for someone offering 64 bit versions of Windows Server (there are plenty). Usually they will offer connection over Remote Desktop, typically you can pay by the month. Upload your programs, run what you want, then delete it when you are finished and cancel the service. The service provider handles installation, licensing, hardware, etc.
hey that was a problem that gave me a headache for a while but i solved it. I had windows 10 32 bit but when i opened system in control panel it said that "32 bit architecture, 64 bit processor." lookup some websites and your hardware must have a few things which you can check in CPU-Z( lookup some webpages for this) its necessary. Then export your folders,documents, softwares in an external hard drive..now download the windows 10 64 bit iso file and boot it.ands viola! you got 64 bit architecture ( i also recommend upgrading ram atleast minimum 4 gb) or the other way is to install 64 bit guest in VMware ir another virtual machine software...gud luck
No, It is not possible...........
I have a program built with VB6 and using some 32-bit DLL's. Will this program run on a 64-bit machine? This page suggests that it should run fine on the Windows on Windows layer, but what about the DLL's?
Yes, both the VB 6 program and the DLLs will work just fine on a 64-bit version of Windows.
Since both are 32-bit, they will run under the Windows-on-Windows 64 (WoW64) subsystem, which effectively emulates a 32-bit operating system on the 64-bit versions of Windows.
I've run many such programs myself with nary a hitch.
Beyond Explorer extensions and kernel mode drivers (neither of which you've written in VB 6), any compatibility problems that you might experience are almost certainly the result of bugs in your own code, which are easily fixed upon detection. Ask more questions about that when you find them.
Are the DLLs built with VB6 as well? Or are they native?
If you are dealing with 100% VB6, then in my experience, yes they tend to run with minimal problems (I maintained a number of plug-ins for another program that were mostly implemented as VB6 COM components, around the time that Windows 7 came out).
It will all of course depend on what libraries your code is using, whether or not you are accessing locations such as %PROGRAMFILES% etc, calling code in native libraries. These things can cause small problems but it is possible to work around them.
Microsoft are still supporting the VB6 runtime on 64-bit windows
Yes, it works, and if you have any problems they will help you.
Well, to begin with, I'm using Visual Studio 2008 on a 32-bits Windows XP system. I have a second 32-bits Vista system but that's not used for development.
I just ordered a new development computer which will use 64-bits Vista. (Don't want Windows 7 just yet, but will probably upgrade to Windows 7 in two years from now if it has a good market value.) (Btw, Intel Xeon Quadcore, 12 GB RAM, 1.3 TB diskspace over 2 disks.) I know that most 32-bits applications will work just fine, including VS and several others. I'm not too worried about this anyways. I also do development with Delphi 2007 but am not worried about this either. But I do want to take this in consideration:
On this new 64-bits system I can start developing 64-bits applications. This is new for me, so what are the most common pitfalls that I need to avoid when I start to develop new 64-bits applications? For example, datatypes that are of a different size, a file system that might be different, special 64-bits functions that I need to be aware of, possible conflict when I have to combine my 64-bits code with 32-bits assemblies, etc.
(I know one already: when developing web applications, I need to make sure my webhost is supporting 64-bits applications, else it's no use... Apparently, IIS doesn't seem to be able to support both 64-bits and 32-bits applications, so that's one pitfall.)
I'm not going to port 32-bits applications to 64-bits applications. I just want to create new 64-bits applications. From scratch! So without any 32-bits history. I've also read about this unanswered Caveat question but that's more about migrating. I won't migrate anything.
Deployment headaches at least for desktop applications.
Special Folders are different for some reason.
Edit and Continue in Visual Studio only works when compiling to 32bit.
You could find some obscure issues which could take forever to work around.
I've been using a 64-bit Vista system since November, with very few problems. The worst so far is that in Visual Studio, to debug a Script Task in SSIS, you have to tell it not to use the 64-bit runtime.
While it's my understanding that there's no fundamental reason a program written for 32-bit hardware / OSs not to run on 64-bit hardware / OSs, in practice, I've found many programs intended for 32-bit versions of Windows that will not work on 64-bit versions of Windows. Examples include a number of popular security utilities (most products from Norton and Check Point's Zone Alarm) and several games (I've been trying to get Grand Theft Auto 4 to run for a few weeks now, but to no avail - of course, that might be related to any number of other problems related to GTA4, but that's neither here nor there).
I've heard that a program's incompatibility might result from something as simple as not wanting to run from the "Program Files (x86)" folder, but what are some of the other reasons? Why would a virus scanner or firewall written for a 32-bit system not run on a 64-bit system? Why would a game not run when everything is theoretically backwards-compatible?
There is a lot of misinformation on this thread.
When a 32-bit application is run on 64-bit windows:
Most of the compatibility problems come when the application tries to install a kernel-mode driver. A 32-bit driver can't be installed on the 64-bit OS. This is amost certainly the problem with a firewall. It's trying to hook into the TCP/IP driver stack.
THERE IS NO EMULATOR! The 32-bit object code is executed by the cpu completely natively at full speed.
There is no support for old 16-bit code. This broke a lot of installers.
Accessing the right folders is generally not a problem. When a 32-bit program opens a file in, say %windir%\system32\, the OS automagically redirects it to %windir%\syswow64. The same for certain parts of the registry. There are a few potential gotchas here, but they're generally along the lines of assuming that various WINAPI Get...Directory() functions return the same strings that they did in Windows 95.
Whether it was compiled 10 years ago or just yesterday, then C/C++ pointers are still 32-bits (4 bytes) and all of the code that just assumed that -- including SendMessage()! -- still works. The 8-byte pointer issue doesn't come into the picture until you start converting to 64-bit compilers.
The best explanation I've found is offered here which basically says 32-bit programs are run on an layer of emulation which doesn't allow the system access you'd get from native programs run in a 64-bit environment:
http://blogs.msdn.com/oldnewthing/archive/2008/12/22/9244582.aspx
I would assume this means that problems with programs like GTA4 come from the layer of emulation not producing the expected results found on a 32-bit native system. This is why you keep seeing Microsoft release compatibility updates all the time.
Here's what the MSDN has to say about the matter:
http://msdn.microsoft.com/en-us/library/bb427430(VS.85).aspx
Drivers are a different story that programs:
http://support.microsoft.com/kb/896456
Zone Alarm uses a special 32-bit driver created by Check Point to do the monitoring. This is probably what's creating the issue with that application. As for Grand Theft Auto 4? I have no idea.
There can be any number of reasons.
Any application which is programmed ad a low level might be expecting 32 bit register. The Zone Alarm driver posted by novatrust is a good example. GTA4 might be using assembly to improve performance at several points which might result on anything or even simply assuming 32 bits on C++. For example take the following code:
struct GPoint
{
int x;
int y;
}
// Array of twenty GPoints
GPoint[] myArr = malloc(20 * sizeof(GPoint);
GPoint* myPointer = myArr;
int index = GetIndexAffectedPoint();
// Invert X and Y for the point
myPointer += 8*index;
swap(myPointer);
I know the example is pretty naive but anyway, in that code you are assuming you're struct is 8 bytes long (4 bytes of the x integer and 4 bytes for the y integer) but in a 64 bit system is actually twice that long so you'll end up swapping the wrong point... things like that happen a lot on low level languages, specially when trying to improve performance...
Security applications are a bad example. They all perform unsupported things against undocumented things. Changes between one 32-bit version of Windows to the next are enough to break them, nevermind moving to 64-bit.
That said, there are some compatibility shims that fixup your code on 32-bit that won't when the app is 64-bit. This is because Microsoft assumes you've tested it on 64-bit.
One resulting gotcha is with .NET applications. When running on a 32-bit system, the exe is jitted to 32-bits - where there are compatibility shims to fix your bugs. If your customer happens to be running on a 64-bit system, the executable will be jitted to 64-bits, where those compatibility shims that were protected you from yourself are no longer present.
Chris Jackson had a nice blog entry about this: Shimming Applications on Windows Vista 64-Bit
The problem is probably drivers. With games, it's probably some kind of slimy DRM scheme. Try getting the no-CD crack for the game so you can run it without DRM.
32-bit to 64-bit Migration Considerations
EDIT: Alternative link
If you are using the file system or the registry, make sure that you access the right folders. As a x86 program you will probably want to access "Program Files (x86)", "SysWOW64", "WOW6232Node" and such folders instead of the x64 ones.
Products with x86 applications like Norton and Check Point's Zone Alarm fail to run their x86 driver, as the driver needs to x64 to be able to ran by the operating system.