When does WIN64 compilation constant get evaluated in VBA? Will it evaluate only on the developer's machine or it will evaluate on the user's machine as well?
For example what does the following code do when it is developed on 32bit Office Application but is being run on a 64bit Office Application?
#IF WIN64 THEN
MsgBox "A"
#ELSE
MsgBox "B"
#END IF
VBA is compiled to the executable file. Instead, it is parsed and executed on each machine separately. So, on both machines x86 and x64 ones the constant is re-evaluated and the code is run depending on the environment. See 64-bit Visual Basic for Applications overview for more information on that.
Related
Environment.SpecialFolder.ProgramFiles and Environment.SpecialFolder.ProgramFilesX86 returning x86
my pc is 64 bit
so how to get Program Files on Windows 64 in vb.net or #c
Dim ProgramFiles As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)
Dim ProgramFilesX86 As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
ProgramFilesX86 will always return the Program Files (x86) folder path while ProgramFiles will return the same path if your app is running in a 32-bit process and the Program Files folder path if your app is running in a 64-bit process.
If you target the x86 platform then your app will always run in a 32-bit process, meaning that it won't run on an OS that doesn't support 32-bit processes.
If you target the x64 platform then your app will always run in a 64-bit process, meaning that it won't run on an OS that doesn't support 64-bit processes.
If you target the AnyCPU platform and check the Prefer 32-bit box then your app will run in a 32-bit process if it can, otherwise it will run in a 64-bit process.
If you target the AnyCPU platform and uncheck the Prefer 32-bit box then your app will run in a 64-bit process if it can, otherwise it will run in a 32-bit process.
Your app would have been running in a 32-bit process because you checked the Prefer 32-bit box - note that it is checked by default - so your app could only see the Program Files (x86) folder, regardless of the OS. It doesn't make sense for 32-bit apps to do anything related to 64-bit processes.
Im developing continually an inventor Addin in VB.Net in visual studio 2019 ,
i have multiple machine different builds , but once in a while some machine just don't want to load the Addin f.e. the current version i have now works on all machines except one AMD machine .
When i compile the same project with the same settings no changes at all on the AMD machine with ANY CPU build option it runs without problem . When i do it on my primary developing machine it does not work on this other computer.
I checked dependencies with dependency walker , i do not get any error messages .
When i make breakpoints in DEBUG mode and debug dll compilation in the first methods called in the "StandardAddInServer.vb" file it does not reach it on the AMD machine when it is compiled on the Intel machine. But in reverse it runs smoothly .
I have no idea what this could be and I'm only speculating that is has to do with AMD/Intel difference of the machines . Any help would be appreciated to come to a solution.
Inventor 2018.3.7 Professional Build 287 is on the Intel i7-4771 machine Visual Studio Community 2019 16.3.9 , .NET 4.8.03761
Inventor 2018 Professional build 112 is on the AMD Ryzen 7 3700X machine Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Any more information which could be helpful will be provided gladly .
Well.... i tought lets make the maschines identical in regards to software .. i started installing inventor updates one by one at Version 2018.3.1 the Addin magically was working .... so i hope i help somebody if the , addin automatically unloads without any error , its probably autodesk inventors fault ...
Are you using ANY CPU ,or are you forcing the project to a given bit size?
If you don't set this, and leave it at ANY CPU? Well, if you launch the application from Visual Studio (such as installing on that target machine), then the application will run as x32 bits.
HOWEVER if you launch the program from the windows command line (command prompt).
Well, if you use the x64 bit command prompt, you get a x64 bit running - in-process program. If any of your external .dll's or libraryes are x32 (or not compiled with ANY cpu), or you using any un-manage code libraies (say like ghostscript or some such)? Then your program will run (or try to) as x64 bits.
However, if you launch a x32 bit windows command prompt (there are two of them - one is x32, and one is x64). So, if you launch the .net exe (your program) from a windows x32 bit prompt, then your program will run in-process as x32 bits.
So, be careful here. Using ANY CPU from Visual Studio will ALWAYS get you a x32 bit program - including debugging. But RUNNING the program (launching outside of VS) will not always be x32 bits.
And the above behaviours seems to explain your issues/problems on the AMD machine. It was NOT that you installed VS on that machine, but that using VS to launch your program in fact FORCED it to run as x32 bits.
Bottom line:
do NOT use ANY CPU unless that is exactly what you need, and that you are VERY sure any external libraries are also compiled as ANY CPU, or in fact that any external libraries doe NOT USE any un-managed code.
All in all? I would config your project to force run as x86 ALWAYS, and thus you not get some surprises of code not working.
I doubt very much that the AMD CPU is the issue, and installing VS only worked because of forcing your project to run as x32 as opposed to x64 bits. It has zero to do with AMD here.
You could try with a former framework version like 4.6.2. That should fix the problem. It could be that the newer service packs of Inventor can deal with addins created with newer .net versions. When 2018 Inventor was released, .net 4.8 was not available.
Was Albert wrote is true as well. If the architecture of your dll doesn't meet that of your host process, it can't be loaded. A 64bit process can use 64bit dlls only whereas a 32bit one can deal with 32bit dll only. A .Net project won't be compiled by Studio into fully functional machine code (nowadays you can do this as well), but intermediate code only, which will be compiled finally by the .net framework on the target machine. If anyCPU is selected, you don't have to provide different versions for different hardware because of this behaviour.
I have a LV program that calls an external library via wrapper functions that I downloaded via VI package manager (libxml2). This program works fine on computer A (Win7, LV2015 32-bit). Since it is meant to be portable, I have installed it on various computers (Win7) where it runs well, except for computer B. There, it throws an Error 1097 when calling the external library. The libxml2 package is obviously installed and I can see it on the Functions palette. Could it be due to the differing versions of Windows, or due to conflicts between Labview 32- and 64-bit? I open and run my program with LV 32-bit.
Computer A:
Labview 2015 (32-bit)
Windows 7
Computer B:
Labview 2015 (32-bit)
and Labview 2015 (64-bit)
Windows 10
It is very likely that the call parameters to the dll need to be changed between the 32bit and 64bit labview vi, this is indicative of the error 1097. If you have pointers or need to reserve memory these can have different size between the 64bit and 32bit variants.
For more help code needs to be shown also a more detailed error description if that is provided.
I was able to solve the problem: probably, there were race conditions and sometimes the DLL was getting illogical random input. It had nothing to do with the system.
In MS Word, there are previously written, fully functional, 32-bit VBA commands that contain Unicode characters coded such as this: ChrW(&H2191). Now in 64-bit Windows with the 64-bit version of Microsoft Office, such code triggers this error message:
Compile error: Can't find project or library.
ChrW$(&H2191) returns the same message.
Why is this error occurring?
In VBA "Tools > References" there's nothing listed as missing.
Despite much sleuthing, I can't pinpoint the problem although I sense the 64-bit environment is involved somehow.
a few years ago I was a Windows application developer.
In the last years I am dealing with kernel and system software.
Now:
I have a customer who tells me that he has a 64bit C/C++ application with
specific functionality. This functionality is a dongle request
and comes from an external 32bit dll.
He says that this functionality is given although I can not see the
DLL in memory.
If I delete the DLL, the 64bit application is still loaded.
That means the 32bit DLL is somehow a static part of the 64bit application.
Can that be true nowadays?
And if so how can I achieve that with Visual Studio?
Best regards
Burkhardt
Based on what I have found on StackOverflow.com it is not possible to load a 32-bit DLL from a 64-bit application (or vice versa) dynamically or statically. There are however a few workarounds.
See the following:
https://stackoverflow.com/a/12938217/184528
https://stackoverflow.com/a/5720902/184528
https://stackoverflow.com/a/11642165/184528