64-bit

问题 I'm running a VBScript that may run under x64 Windows. I need to read a registry key from the 32-bit part of the registry. For that I use path HKLM\Software\Wow6432Node\xyz instead of HKLM\Software\xyz . How can I check if the script is executed under x64? 回答1: I'm not sure you need to check if the script is executing under x64. Try to read from HKLM\Software\Wow6432Node\xyz , if that fails, try to read from HKLM\Software\xyz , if that fails, your registry key doesn't exist, take whatever

问题 I decided to take a crack at assembly the other day, and I've been playing around with really basic things like printing stuff from argv to stdout. I found this great list of linux syscall numbers with arguments and everything, and I'm curious why r10 is used for arguments before r8 and r9 . I've found all kinds of weird conventions about what can be used what for what and when, like how loop counters go in rcx . Is there a particular reason why r10 was moved up? Was it more convenient? I

问题 Attempting to call SetupDiCallClassInstaller from a program compiled in 32 bit mode fails on 64 bit Windows. Apparently this is by design, but I'd like to know the reason. 回答1: According to MSDN: Device Installations on 64-Bit Systems: The 32-bit version of the application must check the value returned by UpdateDriverForPlugAndPlayDevices. If the return value is ERROR_IN_WOW64, the 32-bit application is executing on a 64-bit platform and cannot update inbox drivers. Instead, it must call

问题 I really hope there is some help to get on this subject. Has anyone ever used lua in an application that needs to have both 32-bit and 64-bit support? We are currently transitioning to 64-bit but are having trouble with client compiled lua scripts that we can't recompile ourselves using the 64-bit version. So in effect we need to be able to load bytecode files compiled using 32-bit lua in a 64-bit application. When we try to do so we receive an error message: virtual machine mismatch in test

问题 I am working on porting an application to 64-bit on Linux platform. The application is currently supported on Linux, Windows, Mac 32-bit and Windows 64-bit. One of the issues we are frequently encountering is the usage of long for int and vice versa. This wasn't a problem till now since long and int are interchangeable (both are 4 bytes) in the platforms the application is currently supported on. The codebase being a huge one, with lots of legacy code with #defines for many data types, makes

问题 I was trying to upgrade my server to latest Apache 2.4.23 and PHP 7.1 but it fail to load php_curl library, don't know why. PHP Warning: PHP Startup: Unable to load dynamic library 'ext\\php_curl.dll' - The specified procedure could not be found.\r\n in Unknown on line 0 I have tried followings Change extension path to full path like d:\webserver\php\ext Copy php_curl.dll, libssh2.dll, libeay32.dll, ssleay32.dll to System32 , php/ext , apache/bin , php Added php path system variable Have

问题 I have some unsafe C# code that does pointer arithmetic on large blocks of memory on type byte* , running on a 64-bit machine. It works correctly most of the time but when things get large I often get some kind of corruption where the pointer gets incorrect. The strange thing is that if I turn on "Check for arithmetic overflow/underflow" everything works correctly. I do not get any overflow exceptions. But due to the large performance hit I need to run the code without this option. What could

问题 How do I thunk an arbitrary function with an arbitrary (fixed) number of arguments, on x86 and x64? (I don't need floating-point, SSE, or the like. The arguments are all integers or pointers.) 回答1: Here's my generic implementation. I initially made it with AsmJit, then modified it by hand to remove the dependency. It works for both x86 and x64! It works for both cdecl and stdcall! It should also work for "thiscall", both on VC++ and GCC, but I haven't tested it. (VC++ would probably not touch

问题 With the iPhone 5S update I want my app to be able to support the new 64-Bit processor. However, using 64-Bit may cause truncation if a larger data type is casted into a smaller one, as in the case of casting a long into an int. Most of the time this can be easily fixed by just using the bigger data type, but in the case of random number generators which are sometimes seeded by using the "time(NULL)" function I cannot do that. The current code is simple: srandom(time(NULL)); But in XCode 5

问题 I understand that writing anything in assembly, or adding assembly to any program harms its portability. But, how bad? I mean, basically all PC's are x86 or x64 these days, right? So, if I embed assembly into a C program, why wouldn't it still compile no matter where it went? Does this notion of un-portability just refer to when you really dig in to the specific quirks of a specific processor, to squeeze out every drop of performance from a piece of code? The PC game "Roller Coaster Tycoon"