I don't really get the difference between 2.0 and 1.1.
the registers aren't even showing up as 64bit format in 2.0.
Also 32bit apps take way too long to process with.
Plugins aren't even fully supported.
Is it possible to debug 64bit apps in 1.1 managing the problems
that I listed above?
I'm using 64bit Windows 8.1 and I;m trying to debug a 64bit sample file.
OllyDbg currently does not support debugging 64 bit apps, however the developer stated to start the development of a 64 bit version as soon as his free times allows him. For a 64 bit debugger, take a look at WinDBG.
Update 2021: These days, x64dbg is also an excellent choice. Its design is strongly inspired by OllyDbg.
Related
I have a new VM on which I have installed Visual studio.
I created a new SSIS project, and am trying to use the oledb data source task to access an .accdb MS-Access file.
However I cannot see the Provider. So I installed the Access 32 bit runtime. Now I can see the provider. I am reading that since visual studio is a 32-bit tool, we have to install the Access 32bit runtime. Otherwise if we install the 64bit runtime, then we will not be able to see the provider in the list because visual studio is 32bit and only shows 32bit providers.
When I hit the debug button in visual studio SSIS project it can access the MS-Access file. I am now confused and want to ask - when the project is running, does it run in 32 or 64 bit mode? If the answer is 64bit mode, then how can it access the MS-access file using the 32bit provider? Does it mean that project running in 64 bit mode can utilize 32 bit mode runtime/provider?
Assuming no settings are changed, when debug button is pressed, then does the program execute is 32 or 64 bit mode? Does the OS bitness have any impact on this?
You are quite right and quite close here.
Since Visual Studio is x32 bits?
Well, if your project is set to x86 (x32 bits) or set to ANY CPU?
Then hitting F5 to run + debug (or ctrl-F5 to run the .exe without debug), then you will get (have) a x32 bit running program. Some caution here. If you use ANY cpu? then again FROM VS f5 to run - you get a x32 bit process.
But, if you go to the windows commnd line?
Well, if you launch teh windows x64 bit command line (default on most computers), then if the project is ANY cpu? Then your app run will be x64 bits. (and ANY un-manged code such as Access, or any other windows code used for COM autoamtion? it will break.
If you launch the windows x32 bit command line (with any CPU) then you get a x32 bit version running.
So, from VS - F5 - always x32 bits.
From windows command line - depends.
So, what above suggests? Well, if your intention is to have + use x32 bits process? Then FORCE/SET the project to your intentions. That way, no "by chance" will fool you, and your application will ALWAYS run as to the project settings.
So, in such cases, I do avoid ANY CPU.
Now, what happens if you force the project to x64 bits? eg this:
Well, if you pick x64 bits? (and not any cpu, and not x86).
Then hitting f5 (or ctrl-F5), it WILL run the application as a x64 bits in-process. I am not sure quite how VS works, but they have some kind of "bridge" that marshals the x64 bit debugger to talk to VS x32 bits.
So, if you force the project to x64, then it will always run as x64 bit - including from VS.
So, this means:
if you set project to x64 bits - use a connection builder in settings?
You can use the connection builder but since (we assume) that you using
access x64 bits? Then the test connection button in VS will NEVER work.
But, if you run the code as x64, and have access x64, then it will work. So ONLY the test connection button fails - and that's due to VS being x32.
If you have even the wrong version of Access (say x32 bits), and your project is set to x64? Then the connection builders will work and EVEN the test connection will work (because test connection is ALWAYS x32 bits from VS). This has the effect of you building a connection, hitting test connection - it says good!!! But when you run the project (f5, ctrl-f5), the project runs as x64, and it will fail (this example assumes x32 bits).
Now this is building an writing code from VS. I don't' know of a SSIS package built with Visual Studio works different. But we do NOT want to confuse Visual Studio (VS) with that of say sql studio or other systems - they don't have the project "cpu" or "bit" setting options like you do for a VS project.
So, I quite much suggest if your intention is x32 bit operations, then ALWAYS force the VS project to x32 bits, and thus come time to launch that .exe from windows, then it will never run with a wrong or un-expected bit size.
I not tested a SISIS integration project, but if building this from VS? Then once again, force/set the project bit size.
In effect to remove the "chance" of the wrong bit size? Then force the project to the given bit size you as the developer were intending to use here - that way this is not left to chance.
There ARE times when you want to use ANY cpu. A really good example is when you build say class library code to share amoung projects. In that case, ANY cpu is a good choice, since then EVEN projects forced to x32 or x64 can referances those external assemblies and library code.
However, if you force those external assemblies to a given bit size, then only projects running that that correct bit size can consume such libraries.
.net code (managed) is differnt then un-managed code. .net code has the ability to run "either" x32 or x64 if you choose ANY cpu. But un-managed code (external non .net code such as Access) can't change on the fly like .net code can. And I use the term "on the fly lose here". Since ONCE a .net program starts running x32 or x64? It remains that bit size until terminated.
So, ANY CPU is fine for external class library code you write and thus want to include in any project. But the main project .exe program has to use SOME external non .net (non managed) code? Then you would do very well to force the project bit size settings.
And to answer you last question?
If the provider is a .net one, such as sql provider or whatever? Then it is managed code - cpu settings don't matter. it is ONLY when you start using external code systems that are NOT managed and NOT .net code. MS-Access is one such common example. So would be any windows c++ or even a lot of commerial programs.
For example. Sage/Simply accoutning, and Quickbooks accounting? They offer .net SDK's to interface to those accoutning packages. But they only have x32 bit verisons of those desktop programs - and they are not .net prorgrams. So once agian, you do well to force the project to x32 bits.
So, no x64 bit process can consume a x32 bit process. nor can you consume external librares that don't match.
However, if that library code and system is .net (managed code), and was compiled and created with any CPU, then you don't have any restrictions in regards to using ANY cpu, or even consuming those libraires when you force the .net project cpu settings.
So this whole system ONLY breaks down when you introduce or start using external code libraires.
For example, if you use .net ghostscript library? They have two versions - x32 and x64. And thus just like MS-Access you have to match up the bit size of those external libraries.
This actually is a REALLY nasty problem say for Adobe PDF. Their pdf viewers are x32 only. In fact it was only what - last month they started offering x64 bit versions of their PDF adobe reader. And they no doubt started doing this since office is now moving towards being x64 bits and not a x32 bit system/program.
I have a visual basic(.vbp) desktop application, actually an excel add-ins, it is in VB 2006 and for 32 bit.
I need to upgrade it so it can work with 64 bit, is it possible to do so and how. please guide I have already searched on all internet.
Visual Basic 6 (which came out in 1998, not 2006) predates 64-bit Windows development, and certainly predates it being a normal thing. (Windows XP 64-bit for Itanium was released in 2001, and it didn't get much use.) VB6 can only create 32-bit DLLs and Executables. In order to create a 64-bit application, you will need to recreate the program in a more modern programming environment.
Some of the older versions of Visual Basic .NET have built-in tools to assist with the migration, which can help with some automated translation from VB6 to VB.NET. But, you'd still need to do some amount of manual work to convert it, and thoroughly test for your use cases.
So I've been developing on Windows XP Visual Studio 2008. I guess it is building my C++ app in 32 bit mode. When I run the program on my new Windows 7 64 bit box, it gets half way through loading a then throws an access violation error. So, I loaded all my development tool and recompiled the project on Windows 7 to find the crash site but it works perfectly! What? How do I make my app work on x64? Do I have to release two seperate versions? I know I can target 64 bit but I don't like two separate executables. I've searched but keep getting the two version solution or everything .net. This is a native C++. is there an x86 flag somewhere?
"Do I have to release two seperate versions?"
It depends on what your app does. The majority of 32bit apps work just fine in WoW mode.
"is there an x86 flag somewhere?"
Yup. Open up the configuration manager (Alt-B, O) and you will likely see a win32 in the platform selection.
Why your app crashes is going to take some debugging. You should be able to attach the debugger to the 32bit version on the 64bit OS.
Have you considered the possibility that you may be trashing memory? From the way that the application happens to be loaded into memory, it may be that the 32-bit app on 32-bit Windows and the 64-bit app on 64-bit Windows "get lucky", i.e. no important memory locations are overwritten, whereas the 32-bit app on 64-bit Windows is less lucky and crashes.
To find out if you are indeed trashing memory, you can use tools such as Purify and Valgrind.
As the others' answers already said, it is very likely that the application has bugs that are being hidden in one environment. A good tool that has a low cost of entry in terms of learning curve is Microsoft's application verifier. That along with the debugging tools can provide a very good start. Take a look at the gflags utility.
Is it any way in QtCreator for windows to build a 64-bit executable? (I need to use a COM object as INPROC and this object is only available for 64 bit architecture)
I do not see any reason why not. You would need:
To be working on a 64-bit processor,
Ensure you have the Visual Studio 64 bit edition
Compile Qt on that 64 Bit setup
Compile QtCreator on that setup
The email says that debugging tools would also need to be compiled. I am not sure which debugger QtCreator uses but I would image it would be open source and you could compile it on that setup anyway.
Qt probably do not do it by default because they already produce loads of different builds for all the platforms they support and there has not yet been a large demand for 64bit windows desktop applications.
Pekka Gaiser correctly pointed to an email from Trolltech. Basically, that's it :)
Specifically: Seemingly there is no 64 bit cross-compiler for Windows (due to that, there is no 64bit VLC for Windows). Therefore, the Microsoft compiler must be used. Unfortunately, Creator's support for Microsoft's toolchain is limited (although they make big steps towards supporting it fully).
Again: The email pointed to by Pekka Gaiser contains the information and links for using Qt Creator with Microsoft's 64bit toolchain.
Can someone tell me why I don't have all of the dev studio windows available to me when I develop on a 64-bit platform? I upgraded my dev desktop box to server 2003 x64 to match our deployment platform. Since then (I'm using VS2005) I've noticed that several windows aren't available. I can't view Processes (which is the most annoying) so I don't know which processes I'm attached to. I can attach to a process fine, but it won't show me what is already running under the debugger. There are others, but that's the one that sticks out in my mind at the moment.
My question is where are these limitations of developing under 64 bit documented (assuming they are)? (Of course, I also get the "Edit/Continue" warning dialog all the time telling me that doesn't work in 64-bit)
Also, is VS2008 any better under 64 bit?
Follow-up: Apparently my question is a little bit vague. I'm developing a 64-bit app on a 64-bit development environment. "Recompile it in x86" doesn't solve my problems.
Follow-up #2: I'm giving it one more shot. I WANT TO DEBUG A 64 BIT PROGRAM ON A 64 BIT ENVIRONMENT AND I DON'T HAVE ALL OF THE VISUAL STUDIO FEATURES SHOWING UP. HOW DO I GET THEM?
Follow-up #3: I just installed XP 64 (previously I was using Server 2003 64-bit) and those features all showed up again (Process window, etc). Apparently the server version of windows doesn't provide all of the dev features.
Can anyone tell me why?
"Edit/Continue" can work if you change the build setting to X86 :)
Here was the suggestion from StackOverflow about it.
I had some problem with NUNIT when debugging code. The solution was to use the special program in the \bin\ folder Nunit-x86.exe for old code built in x86 and use the Nunit.exe for x64 built.