I'm going to upgrade my VC++ 2008 into VC++ 2010 or 2012. Before upgrading I have some questions:
My compiler only supports the largest __int64 integers. Is __int128 supported in version VC++ 2010, 2012 and so on?
My current compiler doesn't support something like _WIN64 or _WIN32 to check the Windows platform. But I doubt _INTEGRAL_MAX_BITS is an another solution; It will be 64 if it's run in Win32, or 128 otherwise. Is it true?
For all of the compilers that you mention, 64 bit integer types exist for both 32 and 64 bit targets. However, there are no 128 bit integer types. So, _INTEGRAL_MAX_BITS evaluates to 64 for all of the listed compilers, and for both 32 and 64 bit targets.
The best you can do is probably to use the SSE2 intrinsic __m128i but that depends on the presence of an SSE2 unit on the processor. But you don't need to upgrade to be able to use that. It's available in VS2008 also.
In the C++ standard there is a dedicated section for what you want, in short there is <limits> and the included methods that are a solution to your problem.
EDIT: I'm assuming that you want some kind of standardize support, otherwise you should simply refer to the online docs for your compiler
Related
I am used to using Win32Ada library for calling system calls for a terminal program that I was creating for Windows. The system calls were sufficient to achieve the control needed over the console, but nothing in Ada standard library would be. Examining the list of sources of GPS Community edition, I found Win32Ada missing. I am ready to continue using Win32Ada, but it is implied by its exclusion (as was the case with the POSIX exclusion for the Linux build years ago) that there is a better way to achieve low level interface. Can anyone give me the simplest code or reference to how I may interface with Windows in the way that will be supported from now on?
Example of before:
pragma Ada_2012;
with Win32;
with Ada.Text_IO;
...
I'm not sure that the exclusion of the win32ada library from the GNAT Community Edition implies it's obsolescence. The library is still available on GitHub and no obsolesce is mentioned in the README file. You just might have to clone, build and install it yourself.
Note also that win32ada seems to target 32-bit as well as 64-bit Windows. From what I know, the difference between 32-bit and 64-bit Windows boils down to the size of the pointers being used. These pointers are represented by the types ULONG_PTR and LONG_PTR defined in win32.ads where their sizes are defined using Standard'Address_Size; an attribute exposed by GNAT. Furthermore the fact that win32ada links to files like user32.dll and gdi32.dll with the number 32 in their names is irrelevant when it comes to targeting 32-bit or 64-bit Windows as is mentioned in e.g. this post.
That being said, you might, as an alternative, also want to check GNAT.OS_Lib. This package contains an abstraction to various OS related facilities (see also "Help > GNAT Runtime > GNAT > OS_Lib" in the GPS IDE). Depending on this package instead of win32ada might make your program more portable between operating systems.
You could take a look at the Visual Studio plugin for Ada, Visual Ada which has some UWP support for Windows 64
Visual Studio Community edition is free.
If you really really want to use win32ada, then you may have to contact AdaCore and see if they support it for their paid version or stick with the one supplied with GNAT GPL 2017 for windows 32bit (which is still downloadable). You could potentially pair it with a more updated Ada compiler from msys2 which has both 64 and 32 bit versions of GNAT that are maintained.
Have a look at how it is done in GWindows: the whole framework builds for both Win32 and Win64. Especially, you'll find in the package GWindows.Types how the detection 32 vs. 64 bit is done automatically:
type Handle is new System.Address;
Null_Handle : constant Handle := Handle (System.Null_Address);
type Wparam is mod 2 ** Standard'Address_Size;
type Lparam is new Wparam;
type Lresult is new Wparam;
I've got some data files that were written by a Visual C++ program (32 bit) with the structure alignment set to /Zp2. (Just a dump of a big typedef structure). Now I want to read those files using a 64 bit program, also in Visual C (but 2017 vs 2010). If I set the alignment here to /Zp2 for some reason it is crashing another library that I use, so the alignment is set to default, and I have put #pragma pack (2) in front of all the structures that I need. This does not seem to work however, when I try to access structure members, the data is off. Is there something I am missing or is this not going to be possible?
I am developing and deploying on 64 bit computers. Unfortunately, due to a bug in the 64 bit JIT compiler that has existed and remains unfixed by Microsoft since the introduction of the .NET 64 bit version, my code scales quadratically and breaks. Here is a link to the documentation on the bug: http://connect.microsoft.com/VisualStudio/feedback/details/508748 The old 32 bit compiler works fine. I need to compile one dll to 32 bits and make sure it runs as 32 bits.
In the workarounds someone has written:
Since Microsoft has not figured out in 3 years how to create a < 400MB
image from a 20K XSLT compiled transform script we have been surviving
by setting the assemblies that are implementing any XSLT
transformation to 32 bit.
How is that done? Thanks!
Note: I need this to compile a regex into an assembly using Regex.CompileToAssembly method.
In Visual Studio, select the Build menu and open the Configuration Manager. Look at the "Platform" column of the Project Contexts, and ensure that the selected platform for the project is x86, and that should ensure compilation to a 32-bit target.
I have an application which has many services and one UI module. All these are developed in VC++ 6.0. The total KLOC would be 560 KLOC.
It uses Mutltithreading,MFC and all datatypes like word,int, long.
Now we need to support 64bit OS. What would be the changes we would need to make to the product.
By support i mean both like running the application on a 64bit OS and also making use of the 64bit memory.
Edit: I am ruling out migration to VS2005 or anything higher than VC6.0 due to time constraints.
So what changes need to be done.
64bit Windows includes 32bit via WOW. Any 32bit application should just continue to work.
(It is only drivers that have to match the bitness of the OS.)
[Note to commenters: plugins—of whatever type—are not separate applications but dlls used by other applications which do need to match the host. In that case you also get the same problem where 64bit extensions are incompatible with 32bit hosts.]
As Richard says, the 32-bit version should continue to work unless you've got a driver or a shell extension or something.
However if you do need to upgrade the code you're going to have to upgrade the compiler too: I don't think MFC got good 64-bit support until VS2005 or later. I'd suggest you get the 32-bit code building in VS2010 - this will not be trivial - and then start thinking about converting it to 64-bit. You can of course leave the production 32-bit builds in VC6 but then you add maintainership burden.
You'll probably get most of the way converting by flipping the compiler to 64-bit and turning on full warnings - particularly given the size of your code it may be impractical to review it all. One thing to watch out for is storing pointers in ints, dwords, etc. which may now be too short to hold the pointer - you need DWORD_PTR etc. now - but I think the warnings do catch that.
Or if this is in many components then you might get away with only migrating a few components to 64-bit. Then, unfortunately, you've got data length issues for communication between the two versions.
You must convert to a newer compiler. Time constraints are pretty much irrelevant. The VC6 compiler simply cannot generate 64 bits code. Every pointer it generates is 32 bits, for starters. If you need to access "64 bit memory", i.e. memory above 0x00000000FFFFFFFF, then 32 bits is simply not enough.
If you're ruling out changing your IDE to one that intrinsically supports 64-bit compiling and debugging, you're making your job unnecessarily more complex. Are you sure it's not worth the hit?
Just for running on a 64bit OS, you won't need to make any changes. That's what WOW64 is for.
If, however, you want to run 64bit natively (i.e., access the 64bit memory space) you will have to compile as 64bit. That means using an IDE that supports 64bit. There is no way around this.
Most programs should have no problem converting to 64bit if they are written with decent coding standards (mainly, no assumptions about the size of a pointer, like int-pointer conversions). You'll get a lot of warnings about things like std::size_t conversions, but they will be fairly meaningless.
I'm porting our 32 bit windows app to 64 bit, and trying to clean up all the warnings. I have found calls in our code to CDC::GetTextExtent which take an int as a parameter.
I notice that GetTextExtent simply calls GetTextExtentPoint32. The 32 scares me, so i started looking for a 64 bit version of GetTextExtent but i can't find one.
Can anyone tell me is GetTextExtent totally safe in 64 bit? Or is there some other way we're supposed to get that information?
Thanks
According to the documentation, GetTextExtentPoint32 was added in 32-bit operating systems in order to provider more accurate results (I guess GetTextExtentPoint had a few limitations). All of the parameters are identical, so it doesn't have anything to do with 16-bit vs 32-bit vs 64-bit as far as I can tell. It would have made more sense to call it GetTextExtentPointEx or something, but what's done is done.