I am writing a c++/CUDA code with Visual Studio 2015 to generate a mex file to integrate with MATLAB.
When I run the mex file through the MATLAB console and then try to compile it again on VS I get this error:
LINK : fatal error LNK1168: cannot open filename.mexw64 for writing
Closing the MATLAB and opening the programme again solves the problem.
Does anyone know any solution which not involves closing the MATLAB?
MEX-files are DLLs (on Windows, shared objects on other systems). When first run, MATLAB links to them, but doesn't unlink unless explicitly told to (or quitting MATLAB of course).
Typing
clear mex
in MATLAB will unlink all MEX-files. See the relevant documentation.
But note that your MEX-file can call mxLock, which will cause it to be locked in memory and then it will not be cleared by clear mex. If you use this function in your MEX-file, you need to include a facility to have your MEX-file call mxUnlock. I usually add a syntax such as mymexfile --unlock: the MEX-file checks to see if it is called with one argument, and that argument is a string, and the string matches "--unlock", then it calls mxUnlock.
I have written a c++ program by using UIAutomation on windows. The libraries I have used are windows.h and Uiautomation.h. It works well. However, I want to convert the program to C program. (There is no classes). When I try to do it, I have taken an error which is error: unknown type name 'IUIAutomationElement'. Even file included libraries are enough in the cpp program, why the C version does not run?
Thank you...
After a quick look into Microsoft doc., it is clear that IUIAutomationElement element is a C++ class and cannot be directly used from a C program. Your own code can be plain C, but you will have to use an wrapper module in C++ that declares some extern "C" functions. They will be callable from C and will be able to use IUIAutomationElement.
Environment: Windows 7, Visual Studio 2012, Pepper_34
We have an application that requires parallel processing. We used to use TBB for that. Now porting to PNaCl, we wanted to use this opportunity to switch to using a thread pool built around std::thread in C++11.
Before making the switch, the application (not using TBB) builds for PNaCl without errors.
We know that we will need C++11 for the new thread pool so I enabled C++11 with the command line -std=c++11.
Now I get several errors similar to:
T:\nacl_sdk\pepper_34\toolchain\win_pnacl\usr\include\c++\v1\cstdio(138,9): error : no member named 'snprintf' in the global namespace
So I'm surely missing a compile flag, a command line argument, a pathname or something because this error is generated from compiling cstdio.
Same kind of error when compiling
T:\nacl_sdk\pepper_34\toolchain\win_pnacl\usr\include\c++\v1\__locale and
T:\nacl_sdk\pepper_34\toolchain\win_pnacl\usr\include\c++\v1\locale
Are those pathnames correct?
So my question is what am I missing here to get rid of those errors?
I am facing linker error with my code. I am trying to compile with Visual Studio command Prompt (2010) in Win-7 X64 bit m/c.
The error which i see are as below.
dust2.obj
dust2.obj : error LNK2019: unresolved external symbol _NtOpenFile#24 referenced
in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlAnsiStringToUnicodeStr
ing#12 referenced in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlInitAnsiString#8 refer
enced in function _main
dust2.exe : fatal error LNK1120: 3 unresolved externals
The simplified version of my code is like this:
#include <windows.h>
#include <iostream>
#include <Winternl.h>
using namespace std;
int main()
{
NTSTATUS Status;
OBJECT_ATTRIBUTES Obja;
HANDLE SourceFile;
PUNICODE_STRING PathName=0;
PANSI_STRING p_path=0;
const char* ccp_path = "D:\\txt.txt";
RtlInitAnsiString( p_path,ccp_path );
RtlAnsiStringToUnicodeString( PathName, p_path, true );
IO_STATUS_BLOCK IoStatusBlock;
wprintf(L"%s", PathName->Buffer);
InitializeObjectAttributes(
&Obja,
PathName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL
);
Status = NtOpenFile(
&SourceFile,
FILE_LIST_DIRECTORY | FILE_READ_EA | FILE_READ_ATTRIBUTES,
&Obja,
&IoStatusBlock,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_DIRECTORY_FILE | FILE_OPEN_FOR_BACKUP_INTENT | FILE_OPEN_REPARSE_POINT
);
if(SourceFile == INVALID_HANDLE_VALUE){
printf("\nError: Could not open file\n");
return 0;
}
cout<<endl<<endl;
system("pause");
return 0;
}
In another post in this forum the solution of these kind of problem was mention to include a #pragma.
I tried this solution by adding #pragma like this
#pragma comment(lib, "ntdll")
but on compilation i see another error that says "LINK : fatal error LNK1104: cannot open file 'ntdll.lib'".
I will much appreciate your help to resolve this problem. Thanks..
Can't let this question go unanswered like this. Because although the remark by Mladen is largely right for this particular native API, the whole topic deserves an in-depth discussion.
Preliminary cautionary note
Up front I should note that in many many cases it is neither desirable nor necessary to use one of the native API functions on Windows. However, there are a few cases where the Win32 API doesn't provide the means to query information or even manipulate data and so on. One such case would be several of the information classes available for NtQueryInformationFile/ZwQueryInformationFile.
One good example is the enumeration of alternate data streams on files and directories, which can be done using the Win32 API, in particular by using the backup APIs, but will require special privileges in that case. Not so if you resort to the native API. The same used to be true for hard links until Windows 2000, which introduced CreateHardLink to the Win32 API. Although in this particular case if you knew your way around you could have used MoveFileEx with MOVEFILE_CREATE_HARDLINK ever since it got introduced (although Microsoft still as of this writing marks it as Reserved for future use ... meh).
The canonical books about the native API are these two:
Windows NT/2000 Native API Reference, Gary Nebbett
Undocumented Windows 2000 Secrets: A Programmer's Cookbook, Sven B. Schreiber (free version from the author's website here)
... there are more, including one that discusses NT 4 and preceded Nebbett's book. But Nebbett's book used to start the hype around the native API, much like Hoglund's book started the hype around Windows rootkits. Not a reference regarding the Native API topic but still good:
Windows Internals, Mark Russinovich et. al.
Check out this website for a huge number of native API functions "documented":
http://undocumented.ntinternals.net/
So remember: the inherent risk when using these functions is that they go away in a future Windows version or their semantics change without prior notice. So be careful when you use them, if you use them.
On to glory ...
How to call native API functions
Actually there are two ways to call these functions. Microsoft was forced to disclose some of the native API functions in one of the antitrust law suits some years ago. These were shoved into winternl.h of the SDK. Microsoft expresses it thus:
The NtOpenFile documentation is provided for the sake of full API
coverage. NtOpenFile is equivalent to the ZwOpenFile function
documented in the DDK. For more information on the ZwOpenFile and
related functions, go to http://msdn.microsoft.com/library. In the
left-hand pane, click Windows Development, then click Driver
Development Kit.
However, there is no accompanying ntdll.lib file in the SDK. Microsoft suggests you link those functions dynamically (second option below).
You have several options:
The most common is to do as you did. But the ntdll.lib import library is only part of the WDKs, not the DDKs.
Use GetProcAddress to find the function pointer and call it. GetModuleHandle is sufficient for the Win32 subsystem since every Win32 program is guaranteed to have loaded ntdll.dll.
Method 1: ntdll.lib
If you have the DDK/WDK - for Driver Development Kit and Windows Driver Kit respectively - you get a full set of ntdll.lib files already. On my system (Windows 7 WDK 7600.16385.1):
C:\WINDDK\7600.16385.1\lib\win7\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wxp\i386\ntdll.lib
Create your own makeshift ntdll.lib
Otherwise you have to generate ntdll.lib yourself from the output of dumpbin (or by other means that allow to parse the exports of the DLL) which you can then output into a module definition file from which you can build an export .lib. Sounds convoluted? Not so much, let's see ;)
Using Ero Carrera's pefile Python module, we can do this:
import os, re, sys
from os.path import basename, dirname, join, realpath
try:
import pefile
except ImportError:
try:
sys.path.append(join(realpath(dirname(__file__)), "pefile"))
import pefile
except:
raise
def main(pename):
from pefile import PE
print "Parsing %s" % pename
pe = PE(pename)
if not getattr(pe, "DIRECTORY_ENTRY_EXPORT", None):
return "ERROR: given file has no exports."
modname = basename(pename)
libname = re.sub(r"(?i)^.*?([^\\/]+)\.(?:dll|exe|sys|ocx)$", r"\1.lib", modname)
defname = libname.replace(".lib", ".def")
print "Writing module definition file %s for %s" % (defname, modname)
with open(defname, "w") as f: # want it to throw, no sophisticated error handling here
print >>f, "LIBRARY %s\n" % (modname)
print >>f, "EXPORTS"
numexp = 0
for exp in [x for x in pe.DIRECTORY_ENTRY_EXPORT.symbols if x.name]:
numexp += 1
print >>f, "\t%s" % (exp.name)
print "Wrote %s with %d exports" % (defname, numexp)
print "\n\nUse this to create the export lib:\n\tlib /def:%s /out:%s" % (defname, libname)
if __name__ == '__main__':
if len(sys.argv) != 2:
sys.exit("ERROR:\n\tSyntax: fakelib <dllfile>\n")
sys.exit(main(sys.argv[1]))
A sample output of running this script (when named fakelib.py) would be:
> fakelib.py ntdll.dll
Parsing ntdll.dll
Writing module definition file ntdll.def for ntdll.dll
Wrote ntdll.def with 1984 exports
Use this to create the export lib:
lib /def:ntdll.def /out:ntdll.lib
Then we run the command as given on the last line. It is even better to give the /machine: parameter, of course. This is left as an "exercise" (*cough* *cough*) to the reader. The output with VS 2012 will be:
> lib /def:ntdll.def /out:ntdll.lib
Microsoft (R) Library Manager Version 11.00.51106.1
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
Creating library ntdll.lib and object ntdll.exp
Congratulations. You can now use the ntdll.lib created by Microsoft's own lib.exe to statically import from ntdll.dll, even without having the "real" (original) .lib on your system.
Adjust the path and file names to your needs and tastes.
When using MinGW
Damon pointed out in a comment that the toolchain included with MinGW contains a tool gendef that can do the job of above Python script and that the output can be fed to dlltool.
Issues
The above method works perfectly when targeting x64 (64-bit), but for x86 (32-bit) I have encountered linker errors at times.
The issue is that the name decoration for __stdcall differs between x64 and x86. The former doesn't really use the same __stdcall as x86 and therefore just prepends an underscore. However, the latter also appends a the number of arguments times sizeof(void*) (i.e. 4). So for one argument the decorated function name for a function int __stdcall foo(int); becomes _foo#4.
This KB article from Microsoft outlines a way to get around the issue.
Method 2: dynamically imported, using GetProcAddress
Documentation in MSDN states (for NtOpenFile):
Note that the DDK header file Ntdef.h is necessary for many constant
definitions as well as the InitializeObjectAttributes macro. The
associated import library, Ntdll.lib is also available in the DDK. You
can also use the LoadLibrary and GetProcAddress functions to
dynamically link to Ntdll.dll.
Declare a function type, e.g. here we declare the type TFNNtOpenFile suitable in your case:
typedef NTSTATUS (NTAPI *TFNNtOpenFile)(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
);
... and then retrieve the function pointer and call it:
TFNNtOpenFile pfnNtOpenFile = (TFNNtOpenFile)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
status = pfnNtOpenFile(...); // can't be bothered to type out all parameters ;)
an alternative way of retrieving the function pointer could be this one:
static NTSTATUS (NTAPI *NtOpenFile)(
OUT PHANDLE,
IN ACCESS_MASK,
IN POBJECT_ATTRIBUTES,
OUT PIO_STATUS_BLOCK,
IN ULONG,
IN ULONG
);
(FARPROC)&NtOpenFile = GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
which could be condensed even further by using the preprocessor stringification operator (#). The choice is yours.
These functions cannot be called directly because they belong to internal API and are not exposed through any of the libraries. You need to obtain addresses of these function using GetProcAddress.
For more information look here.
I am trying to move an OpenGL app to Windows.
It was my understanding that Windows had a decent OpenGL implementation. But I'm starting to think that it doesn't...
Specifically, I use array buffers and glDrawArrays.
When I tried to compile my code in Visual Studio 2008 Pro, I received the following errors:
vertexbuffers.cpp(31) : error C3861: 'glGenBuffers': identifier not found
vertexbuffers.cpp(32) : error C2065: 'GL_ARRAY_BUFFER' : undeclared identifier
vertexbuffers.cpp(32) : error C3861: 'glBindBuffer': identifier not found
vertexbuffers.cpp(33) : error C2065: 'GL_ARRAY_BUFFER' : undeclared identifier
vertexbuffers.cpp(33) : error C2065: 'GL_STATIC_DRAW' : undeclared identifier
vertexbuffers.cpp(33) : error C3861: 'glBufferData': identifier not found
When I examined <GL\gl.h> (contained in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\gl), I saw:
/* ClientArrayType */
/* GL_VERTEX_ARRAY */
/* GL_NORMAL_ARRAY */
/* GL_COLOR_ARRAY */
Update but it would seem that those contants get defined elsewhere.
How am I supposed to generate buffers if I don't have access to those functions?
The documentation doesn't say that those array types are disabled. How do I get access to the real implementation on OpenGL on Windows?
You might give GLEW a shot:
http://glew.sourceforge.net/
I'm pretty sure I used it at some time in the past, and makes this sort of thing a little easier and more portable.
The #defines are commented out in the header file whenever they would otherwise be repeated. Look at line 1054 of gl.h:
/* vertex_array */
#define GL_VERTEX_ARRAY 0x8074
If this #define is actually missing then you should probably replace the file with a fresh copy.
If you look at the documentation for glGenBuffers you will see that it is only available in OpenGL 1.5 and higher. The header file for Windows only comes with OpenGL 1.2 and you should use the extension mechanism to access the newer functionality. If you call wglGetProcAddress with the function name, e.g.
void (__stdcall *glGenBuffers)(GLsizei,GLuint*) =
wglGetProcAddress("glGenBuffers");
then you have a pointer to the function.
It would seem that the buffer functions are only available on Windows as extension methods.
OpenGL provides glext.h that declares pointers to all of these functions. It is then up to my app to use wglGetProcAddress to get pointers to the functions.
For example:
PFNGLGENBUFFERSPROC myglBindBuffers =
(PFNGLGENBUFFERSPROC)wglGetProcAddress("glGenBuffersARB");
Thankfully, I only have to do it for about 4 functions. Unfortunately, I now have to add platform-dependent code to my app.
Microsoft's support for OpenGL stretches only as far as OpenGL-1.1 up to Windows XP, and OpenGL-1.4 starting with Vista. Any OpenGL functionality beyond those must be delivered and supported by the installable client driver (ICD), i.e. the GPU driver's OpenGL implmenentation. To access the advanced functionality, OpenGL provides the so called Extension System, formed by wglGetProcAddress, which is kind of like GetProcAddress for DLLs, but gives access to functions of the OpenGL implementation (=driver).
To make things easier, nice wrapper libraries like GLEW have been developed, which do all the grunt work initializing all the available OpenGL extensions, providing them to the end user.