In my Qt 4.7.4 x64 C++ app I'm building in Qt Creator 2.5.0, I want to give full access to everyone for a file. I'm using QFile::setPermissions, which I believe works fine for Mac and Linux, but it doesn't work for Windows. According to Qt setPermissions not setting permisions, I should use
SetNamedSecurityInfoA("C:\file.txt", SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, NULL, NULL);
But I don't know what to #include to make it work. I tried:
#ifdef Q_WS_WIN
#include "Windows.h"
#endif
based on what I found here. But when I compile, I get C3861: 'SetNamedSecurityInfo': identifier not found (among some other new errors).
When I mouse over my #include "Windows.h", I get the tooltip: C:\Program Files\Microsoft SDKs\Windows\v7.0\include\Windows.h, and I can press F2 and jump to that file. We have other files in our project that include that same Windows.h, and they compile fine.
How do I set file permissions on Windows for everyone to read/write? If SetNamedSecurityInfo is what I want (I guess SetNamedSecurityInfoW in my case since my users may be running OS's in any language), what do I #include to be able to use it? Better yet, how do I figure out what to #include, so I know for next time I need to use the Windows API?
SetNamedSecurityInfo
Header
Aclapi.h
Library
Advapi32.lib
DLL
Advapi32.dll
A quick search on Google would probably have had this page among it top hits. There you can see which header file and library you need.
Related
I want to programmatically create a Windows shortcut (.lnk file) to a folder. To do this, I tried this code snippet. However, I get the compilation error C2371 'WebBrowser': redefinition; different basic types in C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\um\exdisp.h line 2367.
Is there a C++17 std::filesystem API for this? If not, how can I fix the compilation error from above? Even with cleaned up includes, the error persists:
#include <Windows.h>
#include <shlguid.h>
#include <shobjidl_core.h>
Using the mklink command yields:
The device does not support symbolic links.
So that doesn't work either, maybe because this is an external SSD.
What else could I try?
The first answer you linked to is the correct way. And it does not rely on WebBrowser at all. It will probably help to define some of the NO_XXX macros before including windows.h.
In my version of ShlGuid.h which is slightly older than yours, I see
#ifndef NO_SHDOCVW_GUIDS
#ifndef GUID_DEFS_ONLY
#include <exdisp.h>
#include <shldisp.h>
#endif
so you can use NO_SHDOCVW_GUIDS to excise the troublesome header that you weren't wanting anyway.
If you wanted support for WebBrowser and the kitchen sink, another fix might be moving #include <windows.h> after ShlGuid.h, as shown e.g. here: https://stackoverflow.com/a/73422757/103167
Links are something that differ a fair amount from filesystem to filesystem, so difficult to standardize. Shell links (.lnk files) are filesystem-independent, but only work on MS Windows (completely non-portable) which also is a strike against finding support in a standard API.
I'm trying to include a query of AD group members to an (ancient) C++ MFC application, and the only way I've figured out it could be done is using ADsOpenObject, which requires me to do #include <iads.h>, and that doesn't work well at all:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE\afxv_w32.h
(16): fatal error C1189: #error: WINDOWS.H already included. MFC apps must not #include <windows.h>
Am I just missing a #define that I need to add or is something else in the app causing this to go terribly wrong?
Or am I even trying to do this using totally wrong libraries?
The problem was just as simple as described in the comments -- changing inclusion order fixed the problem.
In visual community 2015 I have a c++ project.
In the cpp file top I have
#include "stdafx.h"
#include "VideoCaptureFilterSample.h"
#include "VideoCaptureFilterSampleDlg.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
I also set when entering the project properties > VC++ Directories I added this directory in include: C:\Program Files %28x86%29\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
The problem is when I type in my code this:
hr = CoCreateInstance(CLSID_SampleGrabber, NULL, CLSCTX_INPROC_SERVER,
IID_PPV_ARGS(&pGrabberF));
The CLSID_SampleGrabber not defined.
What I tried so far ? Downloaded directx sdk 9 and 6 and Microsoft sdk 7.1 and searched in google for qedit.h but I didn't find the file. Can't figure out how to define the CLSID_SampleGrabber
CLSID_SampleGrabber was removed from Windows SDK long ago, you need as old as version 6.1 Windows SDK to find the declaration. The implementation was removed from Windows operating system only recently (Windows Server 2012?).
You can get it back to your project following this example:
#pragma region Re-Adding Removed from Windows SDK qedit.h
struct __declspec(uuid("0579154a-2b53-4994-b0d0-e773148eff85"))
ISampleGrabberCB : IUnknown
...
struct __declspec(uuid("c1f400a0-3f08-11d3-9f0b-006008039e37"))
SampleGrabber;
// [ default ] interface ISampleGrabber
...
CComPtr<IBaseFilter> pSgBaseFilter;
ATLENSURE_SUCCEEDED(pSgBaseFilter.CoCreateInstance(__uuidof(SampleGrabber)));
Linking amstrmid.lib is a good hint, but you almost never need CLSID_SampleGrabber alone, you also need ISampleGrabber and friends as well, and the library still hosting (as a side effect) the GUIDs don't get you that.
See also:
ISampleGrabber deprecated: where can I find alternatives?
Declare it as follows: extern "C" { extern GUID CLSID_SampleGrabber; }
Then be sure to link to amstrmid.lib. You can grep the symbol out of the libs directories, in case you need others.
I didn't test this completely as I didn't have the dshow sample files handy, but when I debugged it, it had resolved to c1f400a0-3f08-11d3-9f0b-006008039e37 or something like that; you can now find a lot more about it if you google for the first part of that GUID: sometimes with magic guids all you need is a tiny hook and then you can dig up the rest easily.
This is the first question I have found myself not being able to get to the bottom of using my normal googling/stack overflowing/youtubing routine.
I am trying to compile a minimal Lua program inside of a C++ environment just to ensure my environment is ready to development. The Lua language will be later used for User Interface programming for my C++ game.
First some basic information on my environment:
Windows 7 64-bit
Visual studio 2010
Lua for Windows 5.1 (latest build I could download from google code)
Here is the code I am trying to compile:
// UserInt.cpp : Defines the entry point for the console application.
//
#pragma comment(lib,"lua5.1.dll")
#include "stdafx.h"
#ifndef __LUA_INC_H__
#define __LUA_INC_H__
extern "C"
{
#include "lua.h"
#include "lauxlib.h"
#include "lualib.h"
}
int _tmain(int argc, _TCHAR* argv[])
{
lua_State * ls = luaL_newstate();
return 0;
}
#endif // __LUA_INC_H__
Here is the Error I am getting:
1>UserInt.obj : error LNK2019: unresolved external symbol _luaL_newstate referenced in function _wmain
1>c:\users\deank\documents\visual studio 2010\Projects\UserInt\Debug\UserInt.exe : fatal error LNK1120: 1 unresolved externals
Things I have tried:
I have read about lua_open()(and several other functions) no longer being used so I tried the newstate function instead. I get the same error. This was more of a sanity check than anything. I am using 5.1 and not 5.2 so I do not think this really matters.
I have also read this thread Cannot link a minimal Lua program but it does not seem to help me because I am not running the same environment as that OP. I am on a simple windows 7 and visual studio environment.
The top pragma comment line was something I saw in yet another thread. I get the same error with or without it.
I have gone into my visual studio C++ directories area and added the lua include to the includes and the lua lib to the libraries.
So it seems like my program is seeing the .h and seeing the symbol. But for some reason it is not getting the .cpp implementation for the functions. This is why I was hoping including that .dll directly would help fix the problem, but it hasn't.
So, I feel like I have exhausted all of my options solving this on my own. I hope someone is able to help me move forward here. Lua looks like an awesome language to script in and I would like to get my environment squared away for development.
I hope it is just some silly error on my part. I believe I have provided as much information as I can. If you need more specifics I will update with info if I can provide it.
Edit1
Tried the solution in this Can't build lua a project with lua in VS2010, library issue suspected
That did not work either.
You'll need to have the library (.LIB) file and add that to VS. Use Project > Properties and go to Linker > Input and add the full .lib filename to the "Additional Dependencies" line. Note that the .LIB is different from the .DLL.
Personally, I prefer adding the source code to my project, over referencing the dynamic link library. The following procedure will let you do as such.
Download the source code ( http://www.lua.org/ftp/ ), uncompress it.
In Visual Studio, choose File > New > Project and choose Visual C++, Win32, "Win32 Console Application".
In your project in Visual Studio, add all the source code, except luac.c. Also delete the main() function out of the file that VS created for you. This is usually given the name of the project you specified with the .cpp file extension. You could just remove this file all-together from the project.
Build and Run.
This is the Lua console
I'm compiling my application on a new box (vista 64) and now it doesn't compile anymore. The compiler gives me the error in the title. The problem seems(?) to be that HWINEVENTHOOK is defined twice in
windef.h
#if(WINVER >= 0x0400)
DECLARE_HANDLE(HWINEVENTHOOK);
#endif /* WINVER >= 0x0400 */
and then in winable.h it's
#if WINVER < 0x0500 // these structures and functions
// are in NT 5.00 and above winuser.h
typedef DWORD HWINEVENTHOOK;
However, I just looked up WINVER for vista and it is 0x0600 and windows XP is 0x0501 so why is DWORD being defined? I'm at a loss. Anyone help?
According to this MSDN forum thread:
winable.h was moved from the Windows
SDK in July 2005 because functionality
was duplicated in winuser.h. It was
determined at that time that efforts
would be better spent on updating
winuser.h to Windows Vista-level
functionality rather than updating the
functionality of both files.
What version of the Windows SDK are you using, and what Windows version is your code targetting? The target Windows version may be specified in a makefile, project file, or header file. Compiling your code on Vista doesn't necessarily mean that the target version is Vista.
Also, have you tried switching from winable.h to winuser.h?
You might need to explicitly set WINVER to the version corresponding to the minimum version of Windows you are targeting. I suspect its default value is not much above Win2K...
You could check its default value with a quick (untested) hack like this:
#include <windows.h>
#include <stdio.h>
int main(int argc, char **argv) {
printf("WINVER=0x%04x\n", WINVER);
return 0;
}
Compiled as a console app and run at the command prompt it might provide a clue. Otherwise, you'll spend ages chasing through include files trying to identify where it set the default.
Edit: In general, it is safest to always specify WINVER for a project. Either do it in the project settings in Visual Studio (and for all builds, not just the current build!) or do it in a common header file included by every module in the project. Doing so explicitly will reduce the chance that different build environment might have a different assumption.