UPDATE*
I made a excell addin (.xll file), with some math functions, compiled in c++, and it works normally in my computer. Well, when i try send to other person, isnt work. Excel's show a message like the file is corrupted, and when we try open it, open a sheet with some codes/words/symbols
I've tried to find a solution, but to no avail. But I found out what's the really problem.
After install Visual Studio (full version) in this machine wasn't working, the xll addin works!
So, I think I have a program, feature, component that I installed together with the visual studio (full version) that made the program run. I tried the SDK but was unsuccessful.
Could you help me please? I attached 3 images, one with the addin working and 2 with erros.
PS: i tried compiling version 32 bits and x64, for both excells, and happens in both excels (32 & 64 bits)
erro 1
erro 2
working
A colleague ask me to uptdate with the results of -dumpbin /dependents Addin.xll
Follow bellow:
File Type: DLL
Image has the following dependencies:
KERNEL32.dll
USER32.dll
MSVCP140D.dll
VCRUNTIME140_1D.dll
VCRUNTIME140D.dll
ucrtbased.dll
Summary
1000 .00cfg
3000 .data
4000 .idata
1000 .msvcjmc
A000 .pdata
29000 .rdata
2000 .reloc
1000 .rsrc
70000 .text
32000 .textbss
1000 .tls
1) Make sure what you send out to other persons are release builds, not debug ones.
2) Users who do not have the VC++ runtimes installed already will need to install the appropriate x86 (32-bit) or x64 (64-bit) redistributables from The latest supported Visual C++ downloads page (where the bitness depends on which x86 vs. x64 version of the XLL you send them, not on the bitness of their Windows installation).
MSVCP140D.dll
VCRUNTIME140_1D.dll
VCRUNTIME140D.dll
ucrtbased.dll
The 'D' suffix in those DLL names stands for "Debug". Those are the debug C/C++ runtime DLLs, which are used by the Configuration = Debug builds, and are installed as part of the Visual Studio setup. They are to be used during development, but not otherwise deployed, per Determining Which DLLs to Redistribute:
Debug versions of applications and the various Visual C++ debug DLLs are not redistributable.
Related
I have code for an excel add-in I wrote over 20 years ago that I find myself needing again. It works fine in Windows XP and Excel 2003 in a virtualbox. In the VB6.0 IDE, I can load the code and make the dll which I can register as an excel add-in and use it in Excel 2003 within the virtual box. I can also use the VB6 IDE to debug it. I am looking to do the minimum to rewrite this for a short-term need to share with a small set of people in an organization using a current 64 bit version of Excel. They are in a locked-down environment so having them all run an old 32 bit version of Excel for this functionality is not an option.
Is there a version of Visual Basic which allows compiling for 64bit? I find references to what sounds like a VB7 IDE that would allow this. If it does exist, is it possible to get ahold of that anywhere? And will it actually make an add-in that will work with a current 64-bit version of Excel?
You can set registry entries to allow x64 to load x32 libraries.
So COM ignores bitness in EXE files. So any EXE file can be loaded by any COM client (and vice versa though no one cares). By setting registry entries you force your DLL into DLLHOST.exe.
COM loads a 64 bit stub into Excel and communicates to the stub. As far as Excel can tell it has loaded a 64 bit dll.
One problem is that one registry key you don't have permission to change. You must take ownership and give yourself permission to add an entry. There is no inbuilt tool to do this automatically, unlike for files.
This following reg file enables the MSScript Control, which allows you to execute VBScript and JScript as macro languages. Microsoft wants to kill VBScript and JScript and MS Script Control. So it is only available as a 32 bit dll for compatibility. It takes under a minute to add macro languages to any program. Contrast to VBA which you have to pay to use. Note the one line that requires TakeOwnership.
Windows Registry Editor Version 5.00
;MSScript.reg
[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
#="ScriptControl Object"
"AppID"="{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}"
[HKEY_CURRENT_USER\SOFTWARE\Classes\Wow6432Node\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
#="ScriptControl Object"
"AppID"="{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}"
;This one needs to be done manually
[HKEY_CURRENT_USER\SOFTWARE\Classes\Wow6432Node\AppID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
"DllSurrogate"=""
[HKEY_CURRENT_USER\SOFTWARE\Classes\AppID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
"DllSurrogate"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
#="ScriptControl Object"
"AppID"="{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
#="ScriptControl Object"
"AppID"="{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\AppID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
"DllSurrogate"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}]
"DllSurrogate"=""
The reference is here but only DLLSurrogate is of interest to you - https://learn.microsoft.com/en-us/windows/win32/com/appid-key.
A more of a background reference - https://learn.microsoft.com/en-us/windows/win32/winprog64/process-interoperability.
I'm using a Windows 7 64-bit machine. I downloaded the express version of VC++ and the Windows SDK. I need to compile my code in a 64-bit compiler. When compiling, I get the following error:
"CL.exe" exited with code -1073741515
What does this error mean?
The value -1073741515 is 0xC0000135 in hex, which basically means "some dll not found". (http://www.qtcentre.org/threads/57083-1073741515-problem)
I found a very useful & generic guide to convert these cl.exe exit codes to human meaningful messages here:
Visual Studio 2010 C native compilation problem
To summarize:
convert the negative decimal exit code to a hexadecimal number (you can use the Windows built in calculator in the Programmer mode for this)
take the last 8 hexadecimal digits and search them in the table on the Microsoft NT status codes web page
One way I produced this return code with the full version of Visual Studio is to run the vcvarsall.bat script once for 32-bit and later for 64-bit. In this case, start a fresh command prompt instead.
The question here specifically refers to the Express edition. Express only supports compiling 32-bit executables, even on 64-bit Windows.
This error code is mostly due to missing dlls that are required by your program. There can be two solutions.
Locate the primary dlls that are required by your program. In my case specifically, I pasted SDL.dll in the binary directory.
After step 1, I still got the error saying packet.dll not found. So I installed WinPcap the main source of packet.dll
This is the procedure that I followed to resolve this error. Thanks
I have an Excel add-in that I developed using Excel 2007 SDK, it works fine on Excel 2007 and Excel 2010 32 bit version
More recently I noticed that Office 2010 or Excel 2010 is also made available as 64bit software as compared to 32 bit version in Excel 2007 and its counterpart in Excel 2010
I understand it would require Excel 2010 SDK and Visual Studio 2008 to be able to compile the XLL as a 64bit version so it will run in Excel 2010 64 bit on Win7
Are there any specific options I need to set in Visual Studio 2008 so that I can compile the code as 64 bit version
I looked at the sample code in Excel 2010 SDK and it uses the same XLOPER12 data type and the example code looks quite like the one for samples in Excel 2007 SDK
This leads to me ask whether the code from the previous version would require any changes before it is to run in a 64bit Excel environment
Many Thanks in Advance
If your code compiles - you should be good to go. That said - if you are doing any pointer arithematic with the XLOPER12s - you will of course need to keep in mind pointers are 8 bytes in a 64 bit build.
Also - if you are dynamically linking to the CRT make sure you provide the redistributable. Alternatively - statically link to the 64 bit crt.
You don't have to do anything special to get your code to work. Have a look at http://xll.codeplex.com if you want an easy way to create add-ins.
I've been Googling around but without any luck. Can anyone tell me how to set the target platform to x86 only rather than any CPU, on the command line for Vc++ 2010? I am using Code::Blocks and it doesn't present this option in the gui from what I can see because it doesn't seem to know about vc++ 2010. The highest it goes is 2008, at least in my version.
I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.