I have build my code with 32 bit support. In 32 bit machine my app works fine but in 64 bit machine exists function give false.
std::path::Path::new("C:/Windows/System32/Recovery/Winre.wim").exists().
Above is line I am using to check if file exists.I read on google that in 64 bit machine we have some file redirections still couldn't come up with an solution.
I tried running this on 64 bit machine and exists is giving false whereas it should give true.
Related
This question already has answers here:
Can 32-bit and 64-bit code be mixed? [duplicate]
(2 answers)
Closed 9 years ago.
I have a library that compiled in 64 bit and aligned to it.
The problem is that this library should work with 32 bit processes as well (now it will link only with 64 bit processes) and should be aligned to 32 bit as well.
is there a way to make it be aligned to both 32 and 64 bit?
Basically no, not without a recompile.
A DLL compiled in 64-bit uses CPU features (extra instructions/extra registers/...) available in 64-bit mode only, which means a CPU in 32-bit mode cannot execute the code.
There is something called FatELF... But I don't know how much far it went. Basically in an executable/library you put multiple versions of the program (one for 32 bits, one for 64 bits, one for Arm, ...) (the "technique" is called Fat binary)
Sadly I think it's dead... The last commit to their repository is Thu, 22 Nov 2012 12:39:53 -0500...
Does anyone know what the prlimit64() C function does? I don't seem to have it on my x86_64 Ubuntu machine but it exists in Arch, and I can't seem to find anyone or thing who knows what it does.
prlimit allows you to set or get rlimit resource restrictions (such as number of file handles, memory, etc.) for another process. It is Linux-specific.
Normally, the restrictions you can set depend on the _FILE_OFFSET_BITS macro, which is 64 on all modern systems. Therefore, the members of the structures used by prlimit and friends are always 64 bit wide, no matter whether you're on a 32 or 64 bit system.
However, in the obscure case that _FILE_OFFSET_BITS is 32 (which means you can't correctly work with files larger than 2GiB), you need the alternative prlimit64 syscall to use 64 bit rlimits nonetheless.
This is a tricky one; but it's the 64-bit version (whatever that means) of prlimit(); a Linux-specific function in the getrlimit(2) family.
It does not appear to be useful for 64-bit applications, as it relates to emulation of a 64-bit environment when one isn't available.
Is there a simple way to compile 32-bit C code into a 64-bit application, with minimal modification? The code was not setup to use fixed type sizes.
I am not interested in taking advantage of 64-bit memory addressing. I just need to compile into a 64-bit binary while maintaining 4 byte longs and pointers.
Something like:
#define long int32_t
But of course that breaks a number of long use cases and doesn't deal with pointers. I thought there might be some standard procedure here.
There seem to be two orthogonal notions of "portability":
My code compiles everywhere out of the box. Its general behaviour is the same on all platforms, but details of available features vary depending on the platform's characteristics.
My code contains a folder for architecture-dependent stuff. I guarantee that MYINT32 is always 32 bit no matter what. I successfully ported the notion of 32 bits to the nine-fingered furry lummoxes of Mars.
In the first approach, we write unsigned int n; and printf("%u", n) and we know that the code always works, but details like the numeric range of unsigned int are up to the platform and not of our concern. (Wchar_t comes in here, too.) This is what I would call the genuinely portable style.
In the second approach, we typedef everything and use types like uint32_t. Formatted output with printf triggers tons of warnings, and we must resort to monsters like PRI32. In this approach we derive a strange sense of power and control from knowing that our integer is always 32 bits wide, but I hesitate to call this "portable" -- it's just stubborn.
The fundamental concept that requires a specific representation is serialization: The document you write on one platform should be readable on all other platforms. Serialization is naturally where we forgo the type system, must worry about endianness and need to decide on a fixed representation (including things like text encoding).
The upshot is this:
Write your main program core in portable style using standard language primitives.
Write well-defined, clean I/O interfaces for serialization.
If you stick to that, you should never even have to think about whether your platform is 32 or 64 bit, big or little endian, Mac or PC, Windows or Linux. Stick to the standard, and the standard will stick with you.
No, this is not, in general, possible. Consider, for example, malloc(). What is supposed to happen when it returns a pointer value that cannot be represented in 32 bits? How can that pointer value possibly be passed to your code as a 32 bit value, that will work fine when dereferenced?
This is just one example - there are numerous other similar ones.
Well-written C code isn't inherently "32-bit" or "64-bit" anyway - it should work fine when recompiled as a 64 bit binary with no modifications necessary.
Your actual problem is wanting to load a 32 bit library into a 64 bit application. One way to do this is to write a 32 bit helper application that loads your 32 bit library, and a 64 bit shim library that is loaded into the 64 bit application. Your 64 bit shim library communicates with your 32 bit helper using some IPC mechanism, requesting the helper application to perform operations on its behalf, and returning the results.
The specific case - a Matlab MEX file - might be a bit complicated (you'll need two-way function calling, so that the 64 bit shim library can perform calls like mexGetVariable() on behalf of the 32 bit helper), but it should still be doable.
The one area that will probably bite you is if any of your 32-bit integers are manipulated bit-wise. If you assume that some status flags are stored in a 32-bit register (for example), or if you are doing bit shifting, then you'll need to focus on those.
Another place to look would be any networking code that assumes the size (and endian) of integers passed on the wire. Once those get moved into 64-bit ints you'll need to make sure that you don't lose sign bits or precision.
Structures that contain integers will no longer be the same size. Any assumptions about size and alignment need to be cleaned out.
i am going to read a TDMS file in matlab using Mexfunction in C language in a 64 bit windows machine, but i will develop the app in 32 bit windows machine. i know in there is a difference between 32 bit machine and 64 bits with the size of variables. i used a lot of fread(.. sizeof(type)..). is it going to be a problem when it is running in 64 bit machine? if so, how can i make it portable to 64 bits mahince?
thanks
ISO C99 provides the header <stdint.h>, which defines, amongst others, types of the form intN_t and uintN_t, where N is the width of the corresponding integer or unsigned integer type. If an implementation provides integer types of width 8, 16, 32 or 64, it should provide the corresponding typedefs.
The more general problem is that you will have to know what the size of the variables were on the machine that WROTE the file, not the machine that is reading them. In other words, you can say sizeof(int) and get say 8 on some crazy 64 bit system, but if the file was saved on a normal 32 bit machine, sizeof(int) may be 4 (or even 2, according to ansi c, I think). The sizeof command will tell you the size of an int, or whatever, on your local machine at the time of compile. But it can't tell you anything about the machine that saved the file.
Your best bet is to see if the TDMS standard (I'm not familiar with it) defines variable sizes. If so, you should use those, rather than sizeof.
A poor second alternative is to have a test sequence at the beginning of the file and dynamically adjust your variable sizes until you can read the test sequence correctly.
Yes, there could potentially be an issue depending on what you do. For instance, if you rely on pointer size being 4 bytes or 8 bytes, this will be an issue. However, if you are doing something benign than maybe not. I think we'd have to see the specific code to be able to tell you. In short, there should be a straightforward way to go about this without caring about whether or not you are in a 64-bit or 32-bit architecture.
Is there anyway from a C prog to find whether the OS is currently running in 32bit or 64bit mode. I am using a simple program as below
int main(void){
switch(sizeof(void*)){
case 4: printf("32\n");
break;
case 8: printf("64\n");
break;
}
}
Is this a correct approach ?
Would this code work in all the scenarios like, If the hardware is 64bit and the OS is 32bit what would it return ? I don't have machine to test this in diff configurations.
Thanks for the advice.
In general, a 32 bits executable won't be able to tell if it is running under a 64 bit OS or a 32 bit one (some OS could have a way to tell, I know of none but I haven't searched), a 64 bit executable won't run under a 32 bit OS (if you discount the possibility for the 32 bits OS to emulate a processor running a 64 bits OS...)
sizeof() result is mainly a compile time constant, it won't returns something different depending on the OS version it is running under.
What do you want to know really?
To answer your question strictly as given:
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void) {
long wordBits = sysconf(_SC_WORD_BIT);
if (wordBits == -1 && errno == EINVAL)
return EXIT_FAILURE;
else
printf("%ld\n", wordBits);
return EXIT_SUCCESS;
}
This would work in any situation where glibc is correctly configured, and would print your register size to stdout, or return an exit code of 1 otherwise.
See Also
sysconf
In Windows you could look at the PROCESSOR_ARCHITECTURE environment variable. It will return either "x86" when a program is running in 32 bit mode (either because it is running under a 32 bit OS or because it is running on a 64 bit OS but as a 32 bit program under WOW64) or either "IA64"or "AMD64" if running as native 64 bit program on a 64 bit OS.
In addition to compile-time methods, and if you are running on Windows: a call to IsWow64Process ( http://msdn.microsoft.com/en-us/library/ms684139.aspx ) will return true if a process is a 32-bit one running under a 64-bit Windows.
The only way to answer this question is either:
(1) Use some system-specific feature (API call, environment variable, etc) that would tell you whether the OS is 32 or 64 bit.
or
(2) Use some compiler-provided macro that would tell you the same thing (if available).
There's no way to determine what kind of OS you have by any built-in standard language features. They are provided by the compiler and completely independent from OS.
I think your solution is probably valid in most common cases; certainly in all standard IA64 data models pointers are 64bit. This may not however be true of all architectures in theory. It may be safer to test sizeof(uintptr_t) if the compiler has the C99 header; but again it assumes that address width is indicative of register width; it depends whether by "64bit" you are referring to address range or integer range - they need not be the same.
Since 32bit and 64bit compilation requires either a different compiler or a different compiler switch, the target architecture must be known at build-time, and need not be determined at run-time.
Most compilers provide built-in architecture macros to allow this to be determined at build time. A comprehensive list of such macros for a variety of compilers, OS's and architectures is defined at: http://predef.sourceforge.net/