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.
Related
I was recently fixing some IAT on MoleBox packed executable and saw that it links with kernel32 functions: '_lopen', '_lwrite' and '_lread'. This site states that those API's are provided for compatibility with 16-bit versions of Windows. I undesrtand that 'Win16' applications can't be executed in long mode (yes - I'm running Win8.1 x64) - so what is the purpose those to be still included in 'kernel32.dll'?
By the way those functions aren't even included in the 'msdn' library.
EDIT: It also seems that those function aren't actually 16-bit! They're taking 32-bit parameters on the stack.
It's not that the functions can be called by 16 bit applications. Clearly they cannot because they live in 32 bit and 64 bit modules. The point is (was) to make it easier for developers to compile old programs without having to re-write them.
Now, in 2015 there's no real need to cater for developers that have 16 bit programs that they wish to re-compile. That is probably not happening any more to any significant level. But if you roll back the clock 20 years then this was a real concern. And hence MS included these compat crutches. And once they had been included, then MS probably decided to leave them there so as not to break binary compatibility. MS does go to great lengths to avoid breaking old programs. Were these functions to be removed, any programs that rely on them would break.
Microsoft doesn't remove functions "just because" they're old. They will remove these functions as soon as they would require a reimplementation, but for now it takes less work to keep them.
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 am interested whether I can write an application which will be able to call some code without emulation layer and some code inside of 32 bit emulation layer.
The main reason for that is that I will need to use API SetWindowHook and I want to set hook both for 64 bit and 32 bit applications.
Sure, I can create 2 application (one for 32 bit and another for 64 bit) and launch them simultaneously. However, I will need more code to manage them (start, stop, upgrade and etc).
So, I am looking whether it's possible at all to have one application.
The only idea which I have is to have one application and 2 COM DLL's (32bit and 64bit) and use a surrogate process to run code of 32 bit. However, it will require some additional COM wrappers and so on.
I cannot suggest a better way of doing it but what I can do is give you the source to a simple hook-based tool which does exactly the same kind of thing. Feel free to the bits that are useful to you:
http://www.pretentiousname.com/NoBarTab/NoBarTab_poc3.zip
(If this URL breaks in the future, just go up a level; it'd probably because I've finished it and put a real page up for the tool and its source.)
It's a VS2010 C++ project but should be easy to compile in older IDEs. (Writing this actually put me off using VS2010 any further for now, heh.)
Obviously, if you use it, please rename any window classes and binary names to avoid conflicts with my tool. (Anything with "NoBarTab" in the name.)
FWIW, this is a tool I started writing a few weeks ago but haven't got around to finishing. The hooking part is finished, though. It hooks window creation so that it can, for specific processes, remove tabs from the Windows 7 taskbar. (I hate the way that feature is used by VMware, in particular.) I was going to release the source code anyway when I finished it...
The 32/64-bit hooking part is all done. The only thing I haven't got around to is adding a config UI so you can specify which processes it should care about, but that's not important for what you are doing.
(I should say that the way I remove tabs from the Win7 taskbar is a complete hack and might break with future versions of Windows. There's no documented way to do that so I had to settle on a nasty kludge. The actual hooking code that you'd be interested in is all "proper", though.)
Also, I made it so that almost all of the real logic is within the main 64-bit exe. The 32-bit EXE just exists to install the 32-bit hook DLL and both the 32-bit and 64-bit hook DLLs just post a message to the main 64-bit exe's hidden window. Whether that is suitable for what you're doing I leave to you to decide, but I figure it probably fits with your desire to have everything in one place as much as possible.
Hope it's useful!
SetWinEventHook is a higher-level hooking API which handles the 32-bit/64-bit stuff for you. This came up in the answers to another question today and I thought it'd be worth mentioning here in case that solved your problem. Full credit to #atzz for his answer over there.
Whether or not SetWinEventHook is as suitable to you as the lower-level SetWindowsHookEx will depend on exactly what you're doing. (In my case, I could probably re-write the NoBarTab code in my other answer to use the more simple API. Haven't looked in detail yet, though.)
The biggest reason for the emulation layer is that your 64-bit code is going to have a larger address space. Say, for example, you have data addressed at 0x12345678aa000000. If you pass that pointer straight to 32-bit code, it will get truncated to 32-bit address space. That is, to say, that the high-order 32 bits get removed. So the address to your data looks like 0x00000000aa000000 to your 32-bit code. This is clearly a completely different area and not what you intended.
Yes, it's possible. No you shouldn't do it unless you're extremely experience with x86 and x64 assembly, and have access to the 32-bit source code to ensure that it knows that its actually running in 64-bit space and also have access to 64-bit code to ensure that all of the data it passes to the 32-bit code is only in the 32-bit address range.
No, executing 32-bit code without the emulation layer is undesirable unless you are trying to make an UBER UGLY hack.
I think your only hope is to do it through something like out-of-process COM because each process has to be all 32 bit or all 64 bit.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
On these questions:
Which Vista edition is best for a developer machine?
Vista or XP for Dev Machine
People are recommending 64 bit, can you explain why? Is it just so you can have more then 3GB of addressable RAM that 32 bit gives you?
And how does Visual Studio benefit from all this extra RAM?
I went from 64 bit XP back to 32 bit due to 90% of the software I was using only being 32 bit anyway and I had issues with drivers and some software with 64 bit.
Vista, as far as I know, has much better 64 bit support than XP. It is more well advertised than 64 bit XP, and more popular. Driver and software support should be much better for 64-bit Vista.
The 64-bit switch is in progress right now in the computing industry. You might as well switch. Microsoft made the serious leap to 64-bit already, and many have already followed suit. Those who haven't switched, will soon, most likely.
As for the technical benefits, there aren't many aside from the higher memory limits. Vista will certainly allow you to take advantage of the 4GB+ of RAM if you have it on 64-bit though.
A number of reasons.
Yes, you're right it is so you can have more than 3 gig of ram
More and more systems are going to be 64 bit soon so it makes sense to develop on what you're going to be running on
Some bugs can only be observed when running in 64 bit mode
"There are some gotchas in terms of p/invoke calls not always working across 32/64, as well as Managed DirectX not working well under 64-bit, but on the whole I think its something people are going to be doing more as time goes by."
This is caused, in .net, by having the AnyCPU flag set. AnyCPU on an x64 machine will run the process as a x64 process, which proceeds to explode when attempting to call/load a 32 bit dll. Since those libraries are 32 bit you need to set the build to x86, to ensure the app will run as an x86 process, if on an x64 machine it will run in WoW.
Signed Drivers. No more "Unknown Device Driver" blue screens, drivers that cause issues are found out, and rightly blamed for their crashes.
Signed drivers also means the drivers are current. Manufacturers that used to get away with updating a driver once every 2-3 years had to get signed/certified. Which means the driver is relatively current and had to pass basic "is this total crap" test at Microsoft.
This "lack of driver support" I've always seen as a boon. Forcing manufacturer certification.
More address space. Others have mentioned that this allows more RAM, which is true. But it has more impact on memory management performance. It also means having 4 gigs RAM and a graphics card with 512MB on it will be fully used by the system. On a 32 bit OS the system has to decide, out of the limited addresses, what hardware gets what range, physical RAM loses.
Then there is always the possibility of using more than 4 gigs RAM, good for when you have lots of VMs
x64 Vista loads core OS processes/services, during boot, into random addresses. Giving some exploits a 1/256 chance of picking the right memory location, instead of 100% on a 32 machine.
No kernel patching. None. Nada. Zilch. It does mean some Sysinternal tools do not work, however it means xyz spyware/virus cant maliciously apply the same techniques as sysinternals to hide forever, intercept calls, etc. (this is what keeps out some anti-virus software... as well as viruses)
Another technical benefit, aside from the increased address space, is that 64bit apps always use DEP, so you are forced to fix those bugs and potential security holes.
64-bit won't be mainstream before most programs are availiable in 64 bit versions. And who make programs? Developers, developers, developers!
See my point? If developers don't make the shift, how is 64-bit programs going to be mainstream?
Other than that, there is of cource more reasons:
Signed drivers
More memory, as you mentioned
You get the possibility to test your programs on 64-bit (obviously)
It's the future. =)
I switched from 32 bit Vista to 64 bit and haven't looked back. I have only had a problem with one device (a multi-track firewire mixing board) - but everything else that has worked for 32-bit works for 64. Throw in the ability to add piles of cheap RAM, and I don't see any reason why anyone would stick with 32 if the processor supports it.
If you're really unsure, use Vista's much improved multi-boot functionality and install 32 bit XP and 64 bit Vista on the same machine on different partitions. I did, but to tell you the truth, I haven't gone back into XP for at least 9 months now.
Another advantage of 64 bit:
All the registers associated with the microprocessors are 64-bit. This enables High- precision computations and 64-bit arithmetic to be performed in fewer clock-cycles as compared to 32-bit microprocessors. In certain cases like 64-bit multiplication, it is twice as fast.
XP 64bit wasn't ready for prime time, there were no drivers for it. In Windows Vista 64-bit this isn't the case. So if you are looking to install Windows Vista go 64-bit if you are keeping XP stay at 32-bit.
Bigger is always best? The RAM thing is the major advantage, and the increased address space. I guess as long as drivers aren't an issue, then why NOT 64bit?
People are recommending 64 bit, can you explain why? Is it just so you can have more then 3Gb of addressable RAM that 32 bit gives you?
This addressable RAM limit is not a problem for a regular user, but it is pretty critical on DB configuration, scientific computing, etc...
And how does Visual Studio benefit from all this extra RAM?
Does it??? If you want to compile faster you can gain up to 20% compilation time compiling directly from a ramdisk partition. I went from 64 bit XP back to 32 bit due to 90% of the software I was using only being 32 bit anyway and I had issues with drivers and some software with 64 bit.
Switching 64 bits for a regular dev station is probably useless.
Vista x64 has been a very pleasant experience for me. There are a couple of edge cases, but most software and drivers work fine with it at this point. The biggest practical reason I see to use it is that you can load up on RAM (say 6GB or more) and then dedicate lots of it to virtual machines and other apps that require lots of memory (like Photoshop). If you are only using Visual Studio and maybe a couple other apps day to day, then it might not be as beneficial, but I find myself 0ften running 10 to 20 apps at a time (seriously) and the extra RAM is critical.
DotNet rocks had a recent show all about the benefits and pitfalls of going 64-bit from a .Net developer perspective.
http://www.dotnetrocks.com/default.aspx?showNum=341
There are the obvious benefits of having access to more RAM in windows, as well as the obvious possible downside presented by unavailable drivers (which not only have to be 64-bit, but signed and certified as well).
Other points made are in that if you ever need to test anything you are developing under 64-bit, the only way you can do that is on a 64-bit OS. You can always create VM image to test under 32-bit from a 64-bit OS.
There are some gotchas in terms of p/invoke calls not always working across 32/64, as well as Managed DirectX not working well under 64-bit, but on the whole I think its something people are going to be doing more as time goes by.