I use Windows and Visual Studio 10.0 now.
I was wondering where the object files for C standard library functions declared in stdio.h, string.h, etc. are located in Windows, so searched for an object file for 'stdio.h' but failed.
As below,
Files in library folder
These are all in C:\Program Files\Microsoft Visual Studio 10.0\VC\lib.
Which one is the object file for 'stdio.h'?
Or is the object file for 'stdio.h' in another path?
Are there the object files for C standard library only in that path?
That header declares functions that are part of the C standard library so they are found in the different libc* files (static linking) or msvcrt* files (dynamic linking). MT is multithreaded, D is debug.
See Microsoft's documentation.
Related
I have no MATLAB experience. I inherited a piece of Labview code that uses a Matlab complied .dll
Problem is the .dll had a memory leak that I was able to detect and remove.
Now I have no idea how to recompile the c File to produce the .dll file.
The c file has a comment that I believe relates to how the file must be compiled, see below:-
// MATLAB Compiler: 4.3 (R14SP3)
//Arguments: "-B" "macro_default" "link:lib" "reverse_wrapper.m"
The c File is in a folder that has a number of other files including ranging from .dll .m .exports and .m files
Searching the development PC, I see MATLAB Component Runtime version 7.3 is installed.
Please help me with a detailed step by step procedure to get compile my .c file into a .dll do I need to download a compiler and other tools?
https://drive.google.com/drive/folders/1NMV07uslBJey0wlkzthO2krmY5g1BWWQ?usp=sharing
in the above file there is folder named complier, I wonder if this is useful.
I have a Visual Studio 2010 solution that contains a library of functions, and I would like to be able to use MATLAB as one of several possible front-ends to this library. Therefore, I would like Visual Studio to automatically generate a mex file when I build the solution, without having to export all my build options and paths to mexopts.bat and open MATLAB to build the file from there. I have seen several suggestions to achieve something similar, for example in these posts:
Matlab 7.1+ and Visual Studio 2005
Compiling a MEX file with Visual Studio
How to use CMake and Visual Studio 2010 (64 bit) to build a MATLAB R2011a (64 bit) mex file?
However, they either seem a bit outdated (making references to files that are no longer to be found) or make use of external tools (eg. CMake). Does anyone know how to set up a new project (within the existing solution) in Visual Studio (2010 and newer) that will build a mex file for contemporary MATLAB releases?
After some experimenting with guidance from this page mentioned in the question, it seems like starting with an empty C++ project the following settings in the project's Property Pages are necessary and sufficient to build a working .mexw64 from Visual Studio 2010:
Configuration properties -> General:
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add libmx.lib;libmex.lib;libmat.lib; to Additional Dependencies
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
$(MATLAB_ROOT) is the path to Matlab's root folder, eg. C:\Program Files\MATLAB\R2013a.
So far this has only been tried from a solution created from scratch and built for Matlab 2013a 64-bit. I assume that to build for 32-bit one only needs to change both occurrences of 64 to 32. I will update the post when I have confirmed that this works for an existing solution.
EDIT: As expected this works for projects added to existing solutions. Remember to set the new project to be dependent on the project that creates the library.
Edit 2: Following this question I can confirm that the above steps work in Visual Studio 2012, 2013, and 2017 too.
Quickly Setting up Visual Studio Projects for MEX files with a Property Sheet
All of the settings can be applied via property sheets, a mechanism for rapidly applying Visual Studio project configurations.
Steps:
Download the property sheet (MATLAB.props) from this GitHib repo.
It's short and sweet. I'd actual urge you to make your own to learn what's involved in the process. See the Property Sheet Details section below for a description.
Set the MATLAB root environment variables: MATLAB_ROOT for your 64-bit MATLAB installation, and MATLAB32_ROOT for any 32-bit MATLAB installations (e.g. C:\Program Files\MATLAB\R2014b\). This folder has the subdirectories bin, extern, sys, etc. Restart VS if it's opened.
Create an empty DLL project in Visual Studio, optionally creating a x64 solution platform. Do this by choosing "Win32 Project" and selecting DLL as follows:
In "Property Manager" (select from the View menu), for each project's build configuration, right click and choose "Add Existing Property Sheet...", and select the appropriate property sheet (32 or 64 bit). (See screenshot below)
That's it!
Just remember that when going between MATLAB to use your MEX file and Visual Studio to build a new version, it will be necessary to run a clear mex or clear specificMEXFileName to be able to overwrite it.
I build almost all my MEX files this way.
UPDATE (05/22/15): The file MATLAB.props now supports the Parallel Computing Toolbox for using mxGPUArray objects. If the toolbox path and library (gpu.lib) exist on your machine, they can be used. Just include the CUDA SDK "Build Customization" (that should be installed if you've installed the CUDA SDK and installed the Visual Studio integrations) to include cuda_runtime.h, etc. Finally, link with cudart_static.lib (but keep Inherit... checked or you will get other linker errors).
Property Sheet Details
There are only a few important settings in the property sheet:
Adding $(MATLAB_ROOT)\extern\include to the AdditionalIncludeDirectories paths (with inherited paths from parent configurations) -- the location of mex.h.
Adding $(MATLAB_ROOT)\extern\lib\win64\microsoft to the AdditionalLibraryDirectories paths -- the location of libmex.lib, etc.
Listing the libraries: libut.lib;libmx.lib;libmex.lib;libmat.lib.
Exporting mexFunction (it's a shared library): /EXPORT:mexFunction.
Setting the output file extention (e.g. .mexw64 for x64).
Not necessary, but it also specifies an output manifest that is NOT embedded in the library, sets MATLAB_MEX_FILE, and turns on generation of data required for profiling.
For completeness, note that there is a more formal "build configuration" system for project configuration, which includes a property sheet, but a loose property sheet is sufficient for setting up a simple MEX project.
A Note About -largeArrayDims
The -largeArrayDims option is a switch to the mex command in MATLAB that simply indicates not to define MX_COMPAT_32. So, in Visual Studio, you don't have to do anything since this is not defined by default. If you want the opposite behavior (-compatibleArrayDims), then define MX_COMPAT_32 in the Preprocessor section.
What's libut.lib for?
I include libut.lib, which provides a few nice functions for detecting a break (CTRL-C) from within a MEX file. The relevant declarations (although this is getting off topic):
// prototype the break handling functions in libut (C library)
extern "C" bool utIsInterruptPending();
extern "C" void utSetInterruptPending(bool);
For building/linking/compiling, automate visual studio with an extension or macro to
start a thin Matlab client (using -nojvm -noawt -nodesktop -nosplash commandline options, this starts in less than a second on my machine)
generate the binary by calling mex (including the other dependencies etc).
if debugging is activated, attached the visual studio debugger to your newly started thin matlab client(any break points you click in VS will be active).
I have automated this for visual studio 2010. This way, you work with your mex-wrapper entirely from the visual studio IDE, have 4 extra pushbuttons for debugging etc. Compile errors are echoed from a matlab terminal window instead of within Visual Studio. Find the Macros uploaded here:
http://www.mathworks.se/matlabcentral/fileexchange/39549-visual-studio-toolbar-for-mex-interface-with-video-tutorial
I'm writing a script to copy and move DLLs from the bin folder to a mapped drive, and I need to register/unregister the DLLs during the process. I've figured out how to do all of this, but there's a catch. The program I'm working on utilizes VB6 COM DLLs and VB.NET .NET DLLs. I understand that COM DLLs use regsvr32.exe, and .NET DLLs use regasm.exe, but I am interested in programmatically calling the correct function, based upon the DLL I am moving. Is there a way to determine what time I am using in Powershell?
Call
[Reflection.Assembly]::LoadFile( `mydll.dll`)
It should raise a BadImageFormatException if it is not a .Net dll.
As per MSDN:
"This exception is thrown when the file format of a dynamic link library (.dll file) or an executable (.exe file) does not conform to the format that is expected by the common language runtime. In particular, the exception is thrown under the following conditions:
...
An attempt is made to load an unmanaged dynamic link library or executable (such as a Windows system DLL) as if it were a .NET Framework assembly. The following example illustrates this by using the Assembly.LoadFile method to load Kernel32.dll."
How can I generate the code for both x86 and x64 using MIDL?
I've created an IDL file in Visual Studio 2010, and when I compile the product as in x86 mode and afterwards in x64 I've got to "touch" the IDL file so it will regenerate the code relevant for x64. Can I somehow tell MIDL to generate both codes into the same file?
An IDL file defines an interface, that interface could use 64-bit platform features or 32-bit platform features. An IDL can be used to generate a stub; if an interface doesn't have 32-bit-platform-specific definitions or 64-bit-platform-specific definitions, supposedly on stub can be generated (i.e. one IDL file). But, that depends on the interfaces that you're exposing. Short answer: if you define you interfaces to be 32-bit and 64-bit compatible you shouldn't need two different IDL files--otherwise you need two different IDL files.
Without knowing what "touch" (which generally means updating the date/time of a file, w.r.t. software engineering) means, it's hard to say specifically what you need to do.
If you're referring to the files under the Generated Files folder, you won't see them change if all you change is the target platform (well, unless you've placed #ifdef blocks in the IDL that use platform-specific defines). Remember, the output of MIDL is source code, not binaries. The names of the datatypes used in the generated code won't change, so the output from MIDL will be the same even though the machine architecture the compiler is targeting is different.
You can verify this by making copies of the XXX_i.h and XXX_i.c files and comparing them between platforms. To do this, Build, make copies, Rebuild, then compare the files; the only thing that should be different is the timestamp.
So, to get back to your original question: you're already doing it!
I know this is an old question, but should anyone else hit this here is how I solved it.
In the project containing the IDL file, I added a pre-build event to all platforms and configurations that deleted the MIDL output files like this...
if exist $(ProjectName).h del $(ProjectName).h
if exist $(ProjectName)_i.c del $(ProjectName)_i.c
if exist $(ProjectName)_p.c del $(ProjectName)_p.c
I could have gotten away with just deleting the proxy (_p) file as that's the only platform specific MIDL generated file.
If your proxy stub source files have different names or extensions, use those.
I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.