Since Ubuntu 13.10 no longer has ia32-libs I cannot get my android development environment running on a clean install of 13.10.

The error is ~/android-studio/sdk/build-tools/android-4.2.2/aapt&quot;: error=2, No such file or directory

This file does exist and is executable but it is a 32bit executable.

In previous installs I just installed ia32-libs to fix this but this solution no longer works for Ubuntu 13.10.

I have tried solutions proposed by askubuntu questions eg. this one https://askubuntu.com/questions/107230/what-happened-to-the-ia32-libs-package

but it isn&#39;t working for me. 
From that askubuntu.com answer I see I should install separate packages with 

    sudo apt-get install package:i386 

but I don&#39;t know which packages to install to make the android tools work again.

Has anyone else solved this problem and or does anyone have a list of packages which need to be installed for the android tools?

How to make Android&#39;s aapt and adb work on 64-bit Ubuntu without ia32-libs (works for versions 12, 13 and 14)

My version output is:

    &gt; version
                   _                            
    platform       x86_64-w64-mingw32           
    arch           x86_64                       
    os             mingw32                      
    system         x86_64, mingw32              
    status                                      
    major          2                            
    minor          15.2                         
    year           2012                         
    month          10                           
    day            26                           
    svn rev        61015                        
    language       R                            
    version.string R version 2.15.2 (2012-10-26)
    nickname       Trick or Treat    

where os is mingw32. Does that mean I&#39;m using only 32 bits? How can I change that?



How can I know if R is running on 64 bits versus 32?

Our C++ library currently uses time_t for storing time values. I&#39;m beginning to need sub-second precision in some places, so a larger data type will be necessary there anyway. Also, it might be useful to get around the Year-2038 problem in some places. So I&#39;m thinking about completely switching to a single Time class with an underlying int64_t value, to replace the time_t value in all places.

Now I&#39;m wondering about the performance impact of such a change when running this code on a 32-bit operating system or 32-bit CPU. IIUC the compiler will generate code to perform 64-bit arithmetic using 32-bit registers. But if this is too slow, I might have to use a more differentiated way for dealing with time values, which might make the software more difficult to maintain.

What I&#39;m interested in:

* which factors influence performance of these operations? Probably the compiler and compiler version; but does the operating system or the CPU make/model influence this as well? Will a normal 32-bit system use the 64-bit registers of modern CPUs?
* which operations will be especially slow when emulated on 32-bit? Or which will have nearly no slowdown?
* are there any existing benchmark results for using int64_t/uint64_t on 32-bit systems?
* does anyone have own experience about this performance impact?

I&#39;m mostly interested in g++ 4.1 and 4.4 on Linux 2.6 (RHEL5, RHEL6) on Intel Core 2 systems; but it would also be nice to know about the situation for other systems (like Sparc Solaris + Solaris CC, Windows + MSVC).

what is the performance impact of using int64_t instead of int32_t on 32-bit systems?

I have been trying to read up on 32-bit and 64-bit processors ([http://en.wikipedia.org/wiki/32-bit_processing][1]). My understanding is that a 32-bit processor (like x86) has registers 32-bits wide. I&#39;m not sure what that means. So it has special &quot;memory spaces&quot; that can store integer values up to 2^32?

I don&#39;t want to sound stupid, but I have no idea about processors. I&#39;m assuming 64-bits is, in general, better than 32-bits. Although my computer now (one year old, Win 7, Intel Atom) has a 32-bit processor. 


  [1]: http://en.wikipedia.org/wiki/32-bit_processing

What is the difference between a 32-bit and 64-bit processor?

I developed a Windows service using C#.NET to generate PDF report. To generate PDF file I am using a third party dll. The application is running in my Windows XP platform. When I deployed the service in [Windows Server 2008][1] 64 bit version, I got this error: 

&gt; Retrieving the COM class factory for
&gt; component with CLSID
&gt; {46521B1F-0A5B-4871-A4C2-FD5C9276F4C6}
&gt; failed due to the following error:
&gt; 80040154.

I registered the DLL using the regsvr32 command. I able to see this CLSID in the registry. But the problem persists.

What could be the problem?

  [1]: http://en.wikipedia.org/wiki/Windows_Server_2008


Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154

Now that Office also comes in a 64bit install, where in the registry do you find out if the version of Office installed is 32bit or 64bit?

Detect whether Office is 32bit or 64bit via the registry

The usual check to differentiate between running Python-application on Windows and on other OSes (Linux typically) is to use conditional:

    if sys.platform == &#39;win32&#39;:
        ...

But I wonder is it safe to use today when 64-bit Python is more widely used in last years? Does 32 really means 32-bit, or basically it refers to Win32 API?

If there is possibility to have one day sys.platform as &#39;win64&#39; maybe such condition would be more universal?

    if sys.platform.startswith(&#39;win&#39;):
        ...

There is also another way to detect Windows I&#39;m aware of:

    if os.name == &#39;nt&#39;:
        ...

But I really never saw in other code the use of the latter.

What is the best way then?

**UPD**: I&#39;d like to avoid using extra libraries if I can. Requiring installing extra library to check that I&#39;m work not in the Windows may be annoying for Linux users. 

Is it safe to use sys.platform==&#39;win32&#39; check on 64-bit Python?

I want to detect whether the current Windows OS is 32-bit or 64-bit. How to achieve it using C++? I don&#39;t want processor type I want OS&#39;s bit type. This is because you can install 32-bit OS on 64-bit processor.



Detect 32-bit or 64-bit of Windows

I&#39;d like to write a test script or program that asserts that all DLL files in a given directory are of a particular build type.

I would use this as a sanity check at the end of a build process on an SDK to make sure that the 64-bit version hasn&#39;t somehow got some 32-bit DLL files in it and vice versa.

Is there an easy way to look at a DLL file and determine its type?

The solution should work on both xp32 and xp64.


How can I test a Windows DLL file to determine if it is 32 bit or 64 bit?

I am trying to get my first taste of Android development using Eclipse. I ran into this problem when trying to run Eclipse, having installed version 4.2 only minutes ago.

After first trying to start `Eclipse` without any parameters to specify the Java VM, I got an error message saying it `couldn&#39;t find a Java VM called javaw.exe inside the Eclipse folder`, so I found where Java was installed and specified that location as the parameter in the shortcut&#39;s target. Now I get a different error, `Java was started but returned exit code=13`.

Similar questions seem to indicate that it&#39;s a 32-bit/64-bit conflict, but I&#39;m 99% positive that I downloaded 64-bit versions of both Eclipse and `Java (RE 7u5)`, which I chose because I have 64-bit Windows 7. 

 - If anyone knows how to confirm that my Eclipse and Java are 64-bit,
   that&#39;d be appreciated.
 - If you think my problem is a different one, please help!
 - Please speak as plainly as you can, as I am totally new to Eclipse
   and Java.

&gt;Shortcut Target: &quot;C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\eclipse.exe&quot; -vm &quot;C:\Program Files (x86)\Java\jre7\bin\javaw.exe&quot;

**Full error code...:**

    Java was started but returned exit code=13
    C:\Program Files (x86)\Java\jre7\bin\javaw.exe
    -Xms40m
    -Xmx512m
    -XX:MaxPermSize=256m
    -jar C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher_1.30v20120522-1813.jar
    -os win32
    -ws win32
    -arch x86_64
    -showsplash C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\\plugins\org.eclipse.platform_4.2.0.v201206081400\splash.bmp
    -launcher C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\eclipse.exe
    -name Eclipse
    --launcher.library C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.200.v201205221813\eclipse_1503.dll
    -startup C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher_1.30v20120522-1813.jar
    --launcher.overrideVmargs
    -exitdata 1e30_5c
    -vm C:\Program Files (x86)\Java\jre7\bin\javaw.exe
    -vmargs
    -Xms40m
    -Xmx512m
    -XX:MaxPermSize=256m
    -jar C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\eclipse\\plugins/org.eclipse.equinox.launcher_1.30v20120522-1813.jar

Can&#39;t start Eclipse - Java was started but returned exit code=13

I would like to know when do we need to place a file under 

C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.

I had two DLL&#39;s, one for 32-bit, one for 64-bit.

Logically, I thought I&#39;d place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.

To my surprise, it&#39;s **the other way around**! The **32**-bit one goes into C:\Windows\SysWOW&lt;b&gt;64&lt;/b&gt;, and the **64**-bit DLL goes into C:\Windows\System&lt;b&gt;32&lt;/b&gt;.

Very confusing stuff. What&#39;s the reason behind this?

Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows?

I created a windows application developed in .NET 3.5 in a 32 bit Windows 2008 server. When deployed the application in a 64 bit server it shows the error &quot;Microsoft.Jet.OLEDB.4.0&#39; provider is not registered on the local machine &quot;.

So as a solution to this issue, i have changed the build property of the project to X86, so that it will build in 32 bit mode, and rebuild the project in the 32bit machine. But, the same project uses other DB drivers (DB2, SQL etc.) to connect to other databases. So when i deployed my app again in the 64 bit OS, it throws the exception &quot; Attempted to load a 64-bit assembly on a 32-bit platform. &quot;

I am using the Microsoft.Jet.OLEDB.4.0 driver to read and write to the Excel (.xls)

Microsoft.Jet.OLEDB.4.0&#39; provider is not registered on the local machine

I am running the 32bit version of Ubuntu 10.10 and trying to cross compile to a 64 bit target. Based on my research, I have installed the g++-multilib package.

The program is a very simple hello world:

    #include &lt;iostream&gt;
    
    int main( int argc, char** argv )
    {
      std::cout &lt;&lt; &quot;hello world&quot; &lt;&lt; std::endl;
      return 0;
    }

Compile:

    g++ -m64 main.cpp

Error:

    In file included from main.cpp:1:
    /usr/include/c++/4.4/iostream:39: fatal error: bits/c++config.h: No such file or directory
    compilation terminated.

I have found a `c++config.h` file but they reside under the `i486-linux-gnu` and `i686-linux-gnu` directories in `/usr/include/c++/4.4/` There is not `c++config.h` in `/usr/include/c++/bits`.

Any ideas on what I am missing? Compiling without the `-m64` flag works fine (a.out is created and runs correctly).

**Edit** Thanks to the hint from @nightcracker, I did a little more investigation into the include structure on the 32 and 64 bit systems. I have added an [answer][1] below that &quot;fixes&quot; the problem temporarily but I think it will break on the next update. Basically, I am missing a directory called `/usr/include/c++/4.4/i686-linux-gnu/64` that should contain a subdirectory called `bits` that has the missing include file. Any idea what package should be taking care of this?


  [1]: https://stackoverflow.com/questions/4643197/missing-include-bits-cconfig-h-when-cross-compiling-64-bit-program-on-32-bit/4643464#4643464

Missing include &quot;bits/c++config.h&quot; when cross compiling 64 bit program on 32 bit in Ubuntu

I have just installed CentOS 6 64bit version, I&#39;m trying to install a 32-bit application on a 64-bit machine and got this error:

&gt; /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

I&#39;m new to linux.  How do I resolve this?


CentOS 64 bit bad ELF interpreter

I&#39;m looking for a way to reliably determine whether C++ code is being compiled in 32 vs 64 bit. We&#39;ve come up with what we think is a reasonable solution using macros, but was curious to know if people could think of cases where this might fail or if there is a better way to do this. Please note we are trying to do this in a cross-platform, multiple compiler environment.

    #if ((ULONG_MAX) == (UINT_MAX))
    # define IS32BIT
    #else
    # define IS64BIT
    #endif

    #ifdef IS64BIT
    DoMy64BitOperation()
    #else
    DoMy32BitOperation()
    #endif

Thanks.




Determining 32 vs 64 bit in C++

I have a win7 64bit installation. Must I use Python 64bit? What are the differences between the 32bit and 64bit Python versions anyway? Do different Python packages (such as south, django, mysqldb etc) support only 32bit/64bit?


Should I use Python 32bit or Python 64bit

How can I find out if a specific Eclipse instance on my (Windows 7) PC is the 32-bit or 64-bit version?

I&#39;ve checked the About screen and the maze of dialogs one can call from there, but I didn&#39;t find any clues.

Also, right-clicking eclipse.exe in Windows explorer and opening the properties dialog box didn&#39;t give any hints.

How to find out if an installed Eclipse is 32 or 64 bit version?

A `NSInteger` is 32 bits on 32-bit platforms, and 64 bits on 64-bit platforms. Is there a `NSLog` specifier that always matches the size of `NSInteger`?

Setup

- Xcode 3.2.5
- llvm 1.6 compiler **(this is important; gcc doesn&#39;t do this)**
- `GCC_WARN_TYPECHECK_CALLS_TO_PRINTF` turned on

That&#39;s causing me some grief here:

    #import &lt;Foundation/Foundation.h&gt;

    int main (int argc, const char * argv[]) {
        @autoreleasepool {
            NSInteger i = 0;
            NSLog(@&quot;%d&quot;, i);
        }
        return 0;
    }

For 32 bit code, I need the `%d` specifier. But if I use the `%d` specifier, I get a warning when compiling for 64 bit suggesting I use `%ld` instead.

If I use `%ld` to match the 64 bit size, when compiling for 32 bit code I get a warning suggesting I use `%d` instead.

How do I fix both warnings at once? Is there a specifier I can use that works on either?

This also impacts `[NSString stringWithFormat:]` and `[[NSString alloc] initWithFormat:]`.

NSLog/printf specifier for NSInteger?

I have a project that builds in 32/64-bit and has corresponding 32/64-bit dependencies.  I want to be able to switch configurations and have the correct reference used, but I don&#39;t know how to tell Visual Studio to use the architecture-appropriate dependency.

Maybe I&#39;m going about this the wrong way, but I want to be able to switch between x86 and x64 in the configuration dropdown, and have the referenced DLL be the right bitness.

Conditionally use 32/64 bit reference when building in Visual Studio

How can my C# application check whether a particular application/process (note: not the current process) is running in 32-bit or 64-bit mode?  

For example, I might want to query a particular process by name, i.e, &#39;abc.exe&#39;, or based on the process ID number.

How to determine programmatically whether a particular process is 32-bit or 64-bit

When I type `uname -a`, it gives the following output.

    Linux mars 2.6.9-67.0.15.ELsmp #1 SMP Tue Apr 22 13:50:33 EDT 2008 i686 i686 i386 GNU/Linux

How can I know from this that the given OS is 32 or 64 bit?

This is useful when writing `configure` scripts, for example: what architecture am I building for?




How to determine whether a given Linux is 32 bit or 64 bit?

I&#39;m running Windows 8.1 x64 with Java 7 update 45 x64 (no 32 bit Java installed) on a Surface Pro 2 tablet.

The code below takes 1688ms when the type of i is a long and 109ms when i is an int. Why is long (a 64 bit type) an order of magnitude slower than int on a 64 bit platform with a 64 bit JVM?

My only speculation is that the CPU takes longer to add a 64 bit integer than a 32 bit one, but that seems unlikely. I suspect Haswell doesn&#39;t use ripple-carry adders.

I&#39;m running this in Eclipse Kepler SR1, btw.


    public class Main {
    
        private static long i = Integer.MAX_VALUE;
    
        public static void main(String[] args) {	
            System.out.println(&quot;Starting the loop&quot;);
            long startTime = System.currentTimeMillis();
            while(!decrementAndCheck()){
            }
            long endTime = System.currentTimeMillis();
            System.out.println(&quot;Finished the loop in &quot; + (endTime - startTime) + &quot;ms&quot;);
        }

        private static boolean decrementAndCheck() {
            return --i &lt; 0;
        }

    }


Edit: Here are the results from equivalent C++ code compiled by VS 2013 (below), same system. &lt;del&gt;long: 72265ms int: 74656ms&lt;/del&gt;  Those results were in debug 32 bit mode.

In 64 bit release mode: &lt;del&gt;long: 875ms&lt;/del&gt; long long:  906ms int: 1047ms


This suggests that the result I observed is JVM optimization weirdness rather than CPU limitations.




    #include &quot;stdafx.h&quot;
    #include &quot;iostream&quot;
    #include &quot;windows.h&quot;
    #include &quot;limits.h&quot;

    long long i = INT_MAX;

    using namespace std;


    boolean decrementAndCheck() {
	return --i &lt; 0;
    }


    int _tmain(int argc, _TCHAR* argv[])
    {


	cout &lt;&lt; &quot;Starting the loop&quot; &lt;&lt; endl;

	unsigned long startTime = GetTickCount64();
	while (!decrementAndCheck()){
	}
	unsigned long endTime = GetTickCount64();

	cout &lt;&lt; &quot;Finished the loop in &quot; &lt;&lt; (endTime - startTime) &lt;&lt; &quot;ms&quot; &lt;&lt; endl;



    }


Edit: Just tried this again in Java 8 RTM, no significant change.

Why is long slower than int in x64 Java?

We distribute in Linux a static lib in both 64-bit and 32-bit versions.  When troubleshooting a customer, I would like my diagnostic shell script to quickly eliminate the issue by checking the .a archive file to detetmine whether it is 32 or 64 bit.  The methods that occur to me are less than elegant:

1.  extract a .o member and ask the &quot;file&quot; command (e.g., ELF 32-bit etc)  

2.  start including a dummy member coded to indicate, e.g. 32bit.o/64bit.o and use &quot;ar -t&quot; to check

I have tried &quot;strings xyz.a | grep 32&quot; but this doesn&#39;t work well over versions.  Not a heartbreaker problem, but if you know of an elegant solution, I would like to know.


In LINUX determine if a .a library/archive 32-bit or 64-bit?

Is it possible to install both 32bit and 64bit Java on Windows 7?

I have some applications that I can run under 64bit, but there are some that only run under 32bit.

Is it possible to install both 32bit and 64bit Java on Windows 7?

I was trying to measure the difference of using a `for` and a `foreach` when accessing lists of value types and reference types.

I used the following class to do the profiling.

    public static class Benchmarker
    {
        public static void Profile(string description, int iterations, Action func)
        {
            Console.Write(description);

            // Warm up
            func();

            Stopwatch watch = new Stopwatch();

            // Clean up
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();

            watch.Start();
            for (int i = 0; i &lt; iterations; i++)
            {
                func();
            }
            watch.Stop();

            Console.WriteLine(&quot; average time: {0} ms&quot;, watch.Elapsed.TotalMilliseconds / iterations);
        }
    }

I used `double` for my value type.
And I created this &#39;fake class&#39; to test reference types:

    class DoubleWrapper
    {
        public double Value { get; set; }

        public DoubleWrapper(double value)
        {
            Value = value;
        }
    }

Finally I ran this code and compared the time differences.

    static void Main(string[] args)
    {
        int size = 1000000;
        int iterationCount = 100;

        var valueList = new List&lt;double&gt;(size);
        for (int i = 0; i &lt; size; i++) 
            valueList.Add(i);

        var refList = new List&lt;DoubleWrapper&gt;(size);
        for (int i = 0; i &lt; size; i++) 
            refList.Add(new DoubleWrapper(i));

        double dummy;

        Benchmarker.Profile(&quot;valueList for: &quot;, iterationCount, () =&gt;
        {
            double result = 0;
            for (int i = 0; i &lt; valueList.Count; i++)
            {
                 unchecked
                 {
                     var temp = valueList[i];
                     result *= temp;
                     result += temp;
                     result /= temp;
                     result -= temp;
                 }
            }
            dummy = result;
        });

        Benchmarker.Profile(&quot;valueList foreach: &quot;, iterationCount, () =&gt;
        {
            double result = 0;
            foreach (var v in valueList)
            {
                var temp = v;
                result *= temp;
                result += temp;
                result /= temp;
                result -= temp;
            }
            dummy = result;
        });

        Benchmarker.Profile(&quot;refList for: &quot;, iterationCount, () =&gt;
        {
            double result = 0;
            for (int i = 0; i &lt; refList.Count; i++)
            {
                unchecked
                {
                    var temp = refList[i].Value;
                    result *= temp;
                    result += temp;
                    result /= temp;
                    result -= temp;
                }
            }
            dummy = result;
        });

        Benchmarker.Profile(&quot;refList foreach: &quot;, iterationCount, () =&gt;
        {
            double result = 0;
            foreach (var v in refList)
            {
                unchecked
                {
                    var temp = v.Value;
                    result *= temp;
                    result += temp;
                    result /= temp;
                    result -= temp;
                }
            }

            dummy = result;
        });

        SafeExit();
    }

I selected `Release` and `Any CPU` options, ran the program and got the following times:

&lt;!-- language: none --&gt;

    valueList for:  average time: 483,967938 ms
    valueList foreach:  average time: 477,873079 ms
    refList for:  average time: 490,524197 ms
    refList foreach:  average time: 485,659557 ms
    Done!

Then I selected Release and x64 options, ran the program and got the following times:

&lt;!-- language: none --&gt;

    valueList for:  average time: 16,720209 ms
    valueList foreach:  average time: 15,953483 ms
    refList for:  average time: 19,381077 ms
    refList foreach:  average time: 18,636781 ms
    Done!

Why is x64 bit version so much faster? I expected some difference, but not something this big.

I do not have access to other computers. Could you please run this on your machines and tell me the results? I&#39;m using Visual Studio 2015 and I have an Intel [Core&amp;nbsp;i7][1] 930.

Here&#39;s the `SafeExit()` method, so you can compile/run by yourself:

    private static void SafeExit()
    {
        Console.WriteLine(&quot;Done!&quot;);
        Console.ReadLine();
        System.Environment.Exit(1);
    }

As requested, using `double?` instead of my `DoubleWrapper`:

Any CPU

&lt;!-- language: none --&gt;

    valueList for:  average time: 482,98116 ms
    valueList foreach:  average time: 478,837701 ms
    refList for:  average time: 491,075915 ms
    refList foreach:  average time: 483,206072 ms
    Done!

x64

&lt;!-- language: none --&gt;

    valueList for:  average time: 16,393947 ms
    valueList foreach:  average time: 15,87007 ms
    refList for:  average time: 18,267736 ms
    refList foreach:  average time: 16,496038 ms
    Done!

**Last but not least: creating a `x86` profile gives me almost the same results of using `Any CPU`**.

  [1]: https://en.wikipedia.org/wiki/Intel_Core#Core_i7


Huge performance difference (26x faster) when compiling for 32 and 64 bits

&gt; **Possible Duplicate:**  
&gt; [Visual Studio &amp;ldquo;Any CPU&amp;rdquo; target](https://stackoverflow.com/questions/516730/visual-studio-any-cpu-target)  

&lt;!-- End of automatically inserted text --&gt;

I&#39;ve noticed that when compiling C# code in VS, there&#39;s typically options for compiling for 32/64 bit systems, and there&#39;s also one for compiling for any cpu.

What&#39;s the difference between the two options? Does choosing any CPU only compile down to an intermediate byte code while the first option compiles down to machine code (this sounds unlikely to me)? Or something else?

C# compiling for 32/64 bit, or for any cpu?

The Windows operating system can be either 32 bit or 64 bit. The **64 bit** version is called **Windows x64** but the **32 bit** version is called **Windows x86**. Why isn&#39;t it called **Windows x32**? What is the reason?

Why is Windows 32-bit called Windows x86 and not Windows x32?

Here is the situation, I&#39;m using a C based dll in my dot.net application. There are 2 dlls, one is 32bit called MyDll32.dll and the other is a 64bit version called MyDll64.dll.

There is a static variable holding the DLL file name: string DLL_FILE_NAME.

and it is used in the following way:

    [DllImport(DLL_FILE_NAME, CallingConvention=CallingConvention.Cdecl, EntryPoint=Func1&quot;)]
    private static extern int is_Func1(int var1, int var2);

Simple so far.

As you can imagine, the software is compiled with &quot;Any CPU&quot; turned on.

I also have the following code to determine if the system should use the 64bit file or the 32bit file.

    #if WIN64
            public const string DLL_FILE_NAME = &quot;MyDll64.dll&quot;;
    #else
            public const string DLL_FILE_NAME = &quot;MyDll32.dll&quot;;        
    #endif

By now you should see the problem.. DLL_FILE_NAME is defined in compilation time and not in execution time so the right dll isn&#39;t loaded according to the execution context.

What would be the correct way to deal with this issue? I do not want two execution files (one for 32bit and the other for 64bit)? How can I set DLL_FILE_NAME *before* it is used in the DllImport statement?

Using a 32bit or 64bit dll in C# DllImport

What is meant by 32bit or 64 bit machine?

It’s the processor architecture…a 32 bit machine can read and write 32bit data at a time same way with 64 bit machine….


whats the maximum memory that a 32 bit machine can access?

It is `2^32=4Gb` (4Gigabit = 0.5 GigaByte)

That means 4Gb ram?

If  I consider the same way for a 64 bit machine then I can have a ram of 16ExbiBytes ..is that possible?

Are my concepts right?

how much memory can be accessed by a 32 bit machine?

This question: https://stackoverflow.com/questions/5295903/how-many-bits-does-a-word-contain-in-32-64-bit-os-respectively, mentions that word size refers to the bit size of a processor register - which i take to mean the number of bits that a computer processor operates on / i.e. the smallest &#39;indivisible&#39; amount of bits that a processor operates on.

Is that correct? Using software like Word/Excel/etc, the installers have the option for a 32bit or a 64bit installation. What is the difference?

Since the computer architecture is fixed, it would seem to me that software that is &#39;32 bit&#39; would be designed to align with a computer architecture that has a 32 bit architecture. And a 64 bit program would make efforts to align instruction sets with 64 bit word sizes.

Is that correct?

A very similar question is asked here: https://stackoverflow.com/questions/19704544/from-a-programming-point-of-view-what-does-it-mean-when-a-program-is-32-or-64-b - and the accepted answer mentions that the difference is the amount of memory that can be allocated to an application. But this is too vague - unless 32 bit / 64 bit software as a concept is completely unrelated to 32 bit / 64 bit word processor size?

What does it mean for a program to be 32 or 64 bit?

Is there any tool that can directly test if a library is made for 32 or 64 bit?

Have a static lib, is there a simple way to know it is for 32 bit or 64 bit?

&gt; **Possible Duplicate:**  
&gt; [How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode](https://stackoverflow.com/questions/1568685/how-to-also-prepare-for-64-bits-when-migrating-to-delphi-2010-and-unicode)  

&lt;!-- End of automatically inserted text --&gt;

Since I believe that **64bit** Delphi compiler will appear soon,
I am curious if anybody knows what kind of programs
that are now **32bit** will compile and work without any changes
when using **64bit** compiler.

And if there is a general rule what kind of changes should we 
systematically make in our old programs to be compiled
as **64bit**?

It is good to be prepared when the  **64bit** compiler will suddenly be here...

Any suggestion will be much appreciated. 
 



How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?

A great programming resource, Bit Twiddling Hacks, proposes ([here][1]) the following method to compute log2 of a 32-bit integer:

    #define LT(n) n, n, n, n, n, n, n, n, n, n, n, n, n, n, n, n
    static const char LogTable256[256] = 
    {
        -1, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3,
        LT(4), LT(5), LT(5), LT(6), LT(6), LT(6), LT(6),
        LT(7), LT(7), LT(7), LT(7), LT(7), LT(7), LT(7), LT(7)
    };

    unsigned int v; // 32-bit word to find the log of
    unsigned r;     // r will be lg(v)
    register unsigned int t, tt; // temporaries
    if (tt = v &gt;&gt; 16)
    {
        r = (t = tt &gt;&gt; 8) ? 24 + LogTable256[t] : 16 + LogTable256[tt];
    }
    else 
    {
        r = (t = v &gt;&gt; 8) ? 8 + LogTable256[t] : LogTable256[v];
    }

and mentions that

&gt; The lookup table method takes only about 7 operations to find the log
&gt; of a 32-bit value. If extended for 64-bit quantities, it would take
&gt; roughly 9 operations.

but, alas, doesn&#39;t give any additional info about which way one should actually go to extend the algorithm to 64-bit integers.

Any hints about how a 64-bit algorithm of this kind would look like?


  [1]: http://graphics.stanford.edu/~seander/bithacks.html#IntegerLogLookup

Fast computing of log2 for 64-bit integers

I&#39;ve been using [Cygwin][1] (for a long time). Specifically, I use it (including gcc/g++) on Win7 for development work. I&#39;ve just recently noticed there now exists a [64-bit version][2]. 

I don&#39;t have a specific need which requires that I make the transition to 64-bit, but I was wondering whether to do it anyway. Is it advisable? What are the pros and cons? Are there known over-arcing issues when making the transition?


  [1]: http://www.cygwin.com/
  [2]: http://cygwin.com/install.html

Is it advisable to switch from Cygwin 32bit to Cygwin 64bit?

Sorry that there are many similar questions, but I do find that Googling for CMake queries always yields similar-but-not-the-same scenarios, conflicting CMake commands and so on!

I need to force my project to build 32-bit binaries because I have to link with a library which is only available as 32-bit.  I diagnosed this based on error messages such as:

    /usr/bin/ld: i386 architecture of input file `*external-32bit-lib*&#39; is incompatible with i386:x86-64 output

From what I gather, I should therefore use:

    set (CMAKE_CXX_FLAGS &quot;-m32&quot;)

This does change things - I now get several errors like:

    /usr/bin/ld: i386 architecture of input file `*project-output-lib*&#39; is incompatible with i386:x86-64 output

AND still get the same errors for the external library too.  I *think* this is because the `-m32` made gcc generate 32-bit binaries, but ld is still trying for 64-bit output?  Further Googling for this problem didn&#39;t give any success, so if anyone could verify that I am right and give the correct way of doing this, I would be very grateful!

Many thanks!

All 32bit 64bit Solutions on Gang of Coders

Total of 35 32bit 64bit Solutions

How to make Android's aapt and adb work on 64-bit Ubuntu without ia32-libs (works for versions 12, 13 and 14)