I know that there are issues with the VFP OLEDB provider on 64 bit machines. ... but what issues do you encounter while actually running a VFP application - on a 64 bit machine? Has anyone had any experience in this area?
My first thought was that it would just run as a 32bit app, without making use of the 64 bit power. However, I ran into difficulties with a FoxPro application connecting to a SQL Server database (probably an OLEDB issue as well). Are there other issues as well?
This is somewhat of a specialized scenario, and it may not be related to 64 bitness, but since you asked...
My organization recently hosted a legacy VFP 7 app on a Windows Server 2008 Enterprise 64 bit server for access over Terminal Services. The app runs fine, but there is some kind of bug with the TS Easy Print technology. When you print from the app to a redirected client printer over Easy Print, the top, left, and bottom sides of each page of the document get clipped. The workaround we use is to have the users print to pdfFactory on the server first, then print from pdfFactory to the redirected client printer over Easy Print. Works great.
This is somewhat of a stab in the dark...but I believe there are some drivers with MDAC that aren't available in x64 windows. I think you may be able to install the normal 32-bit MDAC but it will install to the x86 folder.
We've seen zero problems with our VFP9 apps on 64-bit XP, Server 2003, Vista, or Server 2008.
Our print engine is a VB DLL though, so we wouldn't run into any VFP-specific printing issues.
Related
Long story, so please bear with me.
I have an app that I wrote back in 2001 for an AS400/iSeries ISV. Basically, it takes drawing commands off of the AS400, and creates a windows graphic (bmp) file so that they can then display the graphic in their application. Everything has worked great over the years. Now, they have a new customer that is having problems running the application. The problem is that when my application is called from the ISV's software, windows generates a message stating that the application is a 16 bit application and can not be run. I am sure that the application is a 32 bit application. We have tested this on 3 machines running Windows 10 x64 at the ISV's office and do not get the error. We get the graphic and everything runs as intended.
I am guessing that the problem is that the WOW64 layer is somehow not enabled or not setup. Questions:
I thought that VB6 apps were all 32 bit. Is that correct?
Is it possible to not install the WOW64 layer during a Windows setup?
Is it somehow possible in Windows 10 x64 to not enable 32 bit apps?
If you have any other suggestions, we are glad to hear them.
TIA and for your time.
Wally
I have fairly large legacy (read only) VSS 8 database that is currently sitting on a windows 2003 server.
As part of an infrastructure consolidation I am being asked to move it onto a new Windows 2012 server. I can't find any notes on whether or not VSS8 will run on 2012; before I even attempt this do you know of any issues running VSS on Windows 2012?
Is it easier to flip the old server to a VM and keep it for posterity and those rare occasions we want to know what someone did in the naughties?
The database itself is merely a fileshare, so you don't have to install the accelerator if you don't want to/are unable to.
In the weeks since asking have deploying VSS2005 (with the runtime available on the server) onto Windows 2012 enterprise. The applications install with a warning about versions but they run fine; including the admin tools for users and checking the consistency of the databases. The end user side all works well too.
I am using TFS 2010 and visual studio 2012.
I have created a C# api to connect to tfs. The code works. I used couple of microsoft.foundation dlls. They are using version 2.0
But I had to configure my application pool in IIS on my server (windows server 2008 64-bit) by setting Enable 32-bit applications to True.
The production server doesn't like the 32 bit and is acting up. The dlls can't be used.
I must find the equivalent 64 bit. Can someone point me to where I can find them?
Thank you
#sudhir3, thank you for your suggestion.
Like I said, the code is not an issue and it works, but that involved setting the 32 bit flag on the app pool.
Further investigations lead me to know that there is no equivalent of 64 bit for the 32 bit dll. VS itself is still 32 bit. No near conversion by microsoft to 64 bit is near.
So, I I ended up leaving the IIS 32 bit flag in the app pool set to false and created web api webservice that passed values to a powershell cmdlet, which in turn executes my TFS api code.
I inherited a huge code base which was written to work on Windows XP. Now we would like to migrate to Windows 7. I do not know what is the proper way to go about this. What is the proper approach to do the above task? I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
Usually how do S/W developers migrate their code/apps written for one version of OS say Vista to Windows 7?
I sell an autoupdate solution (AutoUpdate+, minor plug) and so have lots of experience porting Windows apps to the latest releases, and yet still maintaining backwards compatibility. Porting from Windows XP to Windows 7 can be a big challenge (there should be almost no difference in a move from Windows Vista to Window 7).
Window XP doesn't care where your application exists, and hence programmers would dump both their application and support logic (log files, config files, user profiles etc.) into the same location under "C:\Program Files\". Take this application to Windows 7 and you'll start finding some unusual behaviors. For starters, you will notice that files seem to 'disappear'. Instead of a log file being modified under the common Program Files location, you may end up with multiple, and separate, copies for each user under "Compatibility / Program Files". Windows Vista/7 introduced file system virtualization, and will now create separate user instances of files to ensure to ensure that each user has their own secure copy.
Another problem you will encounter on Windows Vista, and to a lesser extent on Windows 7, is User Account Control (UAC) prompts. It's similar to the issue above, in that new security restrictions will now cause Windows Vista/7 to prompt the user for approval to proceed. The most noticeable area where this occurs is when you are tampering with executable files in sensitive directories, installing applications and drivers, and sometimes when trying to self-update an app (the abovementioned app actually works around these prompts with some smart logic).
So in short, security changes are the biggest difference between Windows XP and Windows Vista/7. Your best start is to separate application logic (binaries) from supporting logic, by putting the latter into user specific directories. Some apps may never be fixable and can be forced instead to work in Compatibility Mode or to launch always under the Admin account context --- poor workarounds, but may be suitable in your company.
Simon # http://AutoUpdatePlus.com
There are three parts to the migration. First, make it just plain work. This means fixing up hardcoded file paths (there's no more Documents and Settings), changing some of your save locations so you don't need to be elevated to work properly and don't rely on virtualization, changing some of your registry key locations for the same reason, and coping with high-DPI which might now be applied automatically based on screen size rather than as a user's choice.
Second, make it look and work like a Windows 7 application. Is your jumplist usable? Your thumbnail? You get some things for free, do you like what you get or would you like to take control? Are there obvious wins you could use like thumbnail buttons, jumplist tasks, taskbar overlays, etc. Don't surprise your users and don't disappoint your users. (Example of disappointment: VS 2008 and the crummy jumplists it offered. They had the excuse of being released before Windows 7 - you don't.)
Third, take advantage of Windows 7 to be greater than you otherwise would. Stop polling for network joins, file creation, hardware being plugged in, going on and off AC power etc and learn how to get notified when those things happen. Add touch support beyond what you get for free. Talk to a sensor or GPS for the first time, since Windows 7 makes it simpler than it ever was. That sort of thing.
1 is not optional. 2 is really not optional either, a year after Windows 7 is released. 3 will differentiate you and I recommend, once you get past 1 and 2, you look into it.
Basically Windows7 is a 4bit OS and so necessarily runs on a 64bit processor environment. XP has 32bit as well as 4 bit flavours. If your application is for the 32bit version of XP, in that case, the major migration means making the application run on 4bit OS effectively.
The basic steps can be something like this:
Make it compatible to 64bit win7. So you may just compile the code off a win7 machine (on 64bit). If the compilation works fine, you might be able to run the app successfully.
The first step just allows to move ahead. But your application might not be effective. In that case, you might have to review the code for any specific implementation coupled on 32bit os and upgrade them to take advantage of 64bit OS.
The major advantages on 64bit OS is higher address-ability (so access more RAM) and also cache etc.
I did some googling on differences between XP and Windows 7 but I do not get any proper links which describe how the internals of 7 differ from XP. Any links will be appreciated.
API diff report between XP and Vista: https://abi-laboratory.pro/compatibility/Windows_5.0_to_Windows_6.0/x86_64/abi_compat_report.html
API diff report between Vista and 7: https://abi-laboratory.pro/compatibility/Windows_6.0_to_Windows_7.0/x86_64/abi_compat_report.html
The reports are generated by the abi-compliance-checker tool.
I am planning to get Sharepoint (MOSS) setup on my home development workstation and one of the things I read about using virtualisation (I currently have Vista, need Windows Server) is that you can install VMs with different OS's (eg Vista, Server) or you can run one OS with the ability to do development on Sharepoint/MS CRM etc which is sandboxed (Can't effect the OS).
My pc specs: Intel Quad Core 2.4ghz, 4GB RAM, Vista 32-bit (so I can't see/use all 4gbs).
How is this usually setup?
Thanks
This article has everything you need. It covers essential post-installation tasks such as server configuration.
How to Create a MOSS 2007 VPC Image: The Whole 9 Yards
Just want to point out that there are more problems with 32-bit SharePoint than the fact that you can’t use all your memory. Read this blog post for more info. I guess you are talking about SharePoint 2007, but 2010 is around the corner and its 64-bit only (probably due to the problems described in that blog post). So I'd recommend you to do it properly and set up an x64 environment from the beginning.
Download a virtualization software. Virtual PC, Virtual Server, VMWare Server are popular and free
Install according to the instructions.
Create a virtual machine (it is usually a wizard)
Install a OS and configure manually, or you can download a use an existing virtual hard drive.
Microsoft Offers one you can use.
http://www.microsoft.com/downloads/details.aspx?FamilyID=67f93dcb-ada8-4db5-a47b-df17e14b2c74&DisplayLang=en
One option could be to copy an existing virtual image from the company network and run that image at home.
If you don't have any existing images at the company you can create one using the "physical to VM" option in VMware workstation / Virtual server and then clone an existing server.
Remember that you might need to create a library of images if you have to test code on an box with SP1, SP2, June Cumulative and so on.
this post on ServerFault is a nice guide to max the performance of the image.
I would just like to add the following to other great answers:
Use Windows 2008 Hyper-V as your host operating system. In my case it had much better performance than Vista on same machine
In case you plan to develop for SharePoint+CRM there is MS prepared virtual machine with both. Unfortunately it is available on to MBS partners. SharePoint only machine is publicly available. Both machines will expire after 30 days, but just apply your product key and you will prolong it's life for additional year.
I have installed Windows Server 2008 directly on my laptop, so no need for VMs. It's an x64 machine as well. I use SQL server 2008 as well. It's just easier than running VMs and believe me, you need the full 4 GB if you are running Vista. Just install the x64 version of Win2008 on your machine (Standard edition will do. Just use this Google query on how to set up Win 2008 just like Vista and make it the ultimate workstation!
Google Query