Is it possible to normally run Visual C++ Express edition on windows7 64-bit?
Because when I try to install it, the setup window says "visual c++ 2010 express includes the 32-bit visual c++ compiler toolset".
I am a student and intend to use the IDE for learning/practicing C language. I don't plan to create windows-ready applications anytime soon with the windows SDK.
So, will it allow me to write and compile normally without the 64-bit compiler toolset(on my 64-bit system)? I mean will it make any difference if I don't plan on making applications using SDK? If yes, please explain how?
And finally, should I go on and install it or opt for other C/C++ IDE? I previously used Dev C++ but it isn't as great on Windows 7.
Thanks.
Yes, you'll be able to run your programs as every other 32-bit application - via WoW64 (Windows-on-Windows64) technology.
Yes, Windows 7 64bit supports pretty much all 32bit applications just fine (except if they depend on some 32bit-only driver components, but most applications don't do that).
Related
I've seen several tutorials on how to compile C++ applications for Windows on a linux system, however, I have failed to find a way to use Windows specific headers (i.e Windows.h) in my C++ program to compile for Windows (.exe/.dll). I was wondering if anyone knew how I can compile Visual C++ programs on Linux that use Windows OS Specific headers/functions (just compile). Thanks!
You can't. Windows system headers, e.g. windows.h reference OS specific APIs that are not known to Linux. Only Microsoft's compiler can create Windows format objects and executables and it doesn't run on Linux.
You can create cross-platform applications consisting of common code that will build and run on Windows and Linux. But the only way to use platform specific APIs in such an application, e.g. GUI, is to #define sections in/out according to the build environment.
I have written an application in C++/Qt that runs on Windows and I want to port it to Haskell/Qt using qtHaskell. Can I use Visual C++ to build qtHaskell or I have to install MinGW/Qt?
As far as I know, you can't mix and match c++ compilers because they make different ABI choices. So you should do what the docs say and use MinGW/Qt.
Is it possible to run VB.NET in Linux?
I have written code in VB.NET and compiled it as well using Visual Studio in Windows.
Can the same code be written (and compiled) on Linux as well?
If yes, then which software do I need to install on Linux?
Is the Linux alternative of VB.NET freeware?
You can run Visual Basic, VB.NET, C# code and applications on Linux.
The most popular .NET IDE is Visual Studio (now in version 2019) that runs in Windows and macOS. A good alternative for Linux users is Visual Studio Code (runs on Linux, Windows and Mac).
You can compile and run VB.NET code and applications (part of .NET framework, consider the successor of Visual Basic, with several language differences from Visual Basic 6.0). A subset of .NET is .NET Core that can be installed on
Red Hat Linux,
Ubuntu,
Linux Mint,
Debian,
Fedora,
CentOS,
Oracle Linux
and openSUSE Linux distributions.
Setup details are on https://www.microsoft.com/net/core.
You can also use Mono, a free and open-source project led by Xamarin (a subsidiary of Microsoft) and the .NET Foundation. The project focus is to support an ECMA standard-compliant .NET Framework-compatible set of tools (including a C# compiler and a Common Language Runtime).
Mono can be installed on
Ubuntu,
Debian,
Raspbian (used in Raspberry Pi)
and CentOS Linux distributions.
You can run most Windows applications (created with VB, VB.NET or with other tools) using Wine that supports the Windows API on Linux.
** About Visual Basic (not VB.NET, due to the original question) **
Note that the last version of visual basic is 6.0, released in 1998, declared legacy during 2008 and supported on Windows XP, Windows Vista, Windows Server 2008 including R2, Windows 7, Windows Server 2012, and Windows 8.x. There are also other basic flavors (like QuickBASIC, Gambas or others).
The support end dates for Visual Basic 6.0 are:
The Visual Basic 6.0 IDE [Integrated Development Environment]:
supported ended on April 8, 2008.
Visual Basic 6.0 Runtime the base libraries and execution engine used to run Visual Basic 6.0 applications: support ended on April 8, 2014.
Visual Basic 6.0 Runtime Extended Files: support ended on April 8, 2014.
You could have a look at the Mono VisualBasic.Net support, or maybe go and check out the Gambas project.
You won't find a fully compatible solution.
There are a few, like SimpleBasic, GnomeBasic and XBasic. None of them are fully compatible with Visual Basic.
The above answer was accepted eons ago, but is horribly outdated, since more recently, there's also .NET Core. This will run the actual VB.NET language, but it will not use Windows Forms controls and features powering most real VB.NET applications. .NET Core 3 does support some variation of Windows Forms, but only on Windows.
Please check Pedro Polonia's excellent answer that contains all the details that mine misses.
Mono is a really interesting project. You can run applications on Linux.
Is not fully compatible, but they are working on that.
Take a look in this site Working with Mono
VB on linux is posible using vb2005.
First install wine.
run in the terminal winetricks dotnet20 dotnet40
download the installer and run it
(wine Downloads/yourinstaller.exe)
execute wine WINEPREFIX=~/yourprefix WINEARCH='win32' wine yourprefix/drive_c/Program\ Files/Microsoft\ Visual\ Studio\ 8/Common7/IDE/vbexpress.exe
Gambas Basic is actively developed and works good. Here you can find a small tutorial for programming a calculator:
Gambas Basic 3.14
This is now possible using .NET Core.
Publish .NET apps with the .NET CLI
How to run a .NET Core console application on Linux
The Java countdown is now running :-)
For those looking for an alternative to Visual-Basic and Visual-Studio with cross-platform support, B4J (Basic For Java) is a good choice too. It's free, kind-of\semi "open-sourced" and really user friendly especially for those coming from VS.
Okay, so I have a legacy Codebase and an old Visual C++ 6.0 Standard Installation CD. I want to install that on my Windows XP SP3 System.
Is there anything I would need to avoid or to download besides SP6?
Are executables created with VC6 compatible on Vista and Windows 7? (I know that there is no 64-Bit compiler, and that's fine)
(I know that vc6 is old, unsupported and somewhat crappy, but my C++ skills are barely good enough to compile, make 2 or 3 small changes and re-compile, but not good enough to make sure it compiles in VS2008)
It's fine. Install SP6 and that should be it. You might need other dependencies; the platform SDK, if you need it, will require hunting for an older version than what's currently available.
AFAIK it should run fine provided you install VC++ runtime. I think you should install VC6 runtime to be sure, not the recent versions.
For latecomers who don't know where to get this "SP6" we're talking about, it's at:
"Visual Studio 6.0 service packs, what, where, why"
"Product Updates for Visual C++ 6.0"
"Service Pack 6 for Visual Basic 6.0, Visual C++ 6.0 with Visual Source Safe 6.0d"
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.