|
|
Use GetWindowLong/SetWindowLong to change the Dialog proc to ur own custome made window proc. U can handle messages of ur interest, let the rest will be handled by defaultwindowproc
|
|
|
|
|
Hi,
I have a strange problem about GetNamedSecurityInfo() API to retrieve DACL of a network share folder.
I created a net share for the same folder respectively with the Steps A and Steps B as below in Explorer. My OS is Win2K Pro.
I do not know the result difference between Steps A and Steps B! In fact, I think they just did the SAME thing:
share the folder and grant 'Full Control' to 'Everyone'.
But, the same API call gets DACL with NULL for the former while a correct value for the latter!!!
It's so strange! 
Any helps? Thank you for your comments very much!
David
=============================================================================
Steps A:
Right click the folder,
Select 'Share',
Click 'Share this folder',
Click 'Apply' to close the properties window.
Steps B:
Right click the folder,
Select 'Share',
Click 'Share this folder',
Click 'Permission' button to open a new window,
For the default 'Everyone', click 'Full Control' TWICE,
Click 'Apply' to close the new window.
Click 'Apply' to close the properties window.
my code as below:
PSECURITY_DESCRIPTOR pSD;
PACL pDACL;
ULONG result = GetNamedSecurityInfo(pszShareFullName, SE_LMSHARE, DACL_SECURITY_INFORMATION, NULL,NULL, &pDACL, NULL, &pSD);
if( result == ERROR_SUCCESS )
{
ACL_SIZE_INFORMATION aclSize = {0};
if( pDACL != NULL )
{
// here
// why different result?
//
}
}
|
|
|
|
|
Could it be in the first case it gets default properties from its parent, but if you ask for them explicitly, then nothing is returned?
In the second case, you applied security against the object explicitly.
It would be curious to test the DCAL against a share one level higher (its parent)?
That is, create a share with the properties you want. Repeat your steps for a share embedded within the first share. Get the DACL for each, the parent and the child, and see what are your results.
|
|
|
|
|
hi All, How to restrict access to folder in
windows XP, only my application (developed in VB)
can read and write to folder, nobody can copy
from that folder, is it possible??
restricted folder got files need for my
application (.txt, .conf, .ddl and .ocx files)
Any suggestion to achieve the above will be
greatly appreciated
-bala-
|
|
|
|
|
I think Windows XP doesnt have this function. You can restrict access to folder if you run a special application, but in default, Windows XP cant help you. If you log on an admin account, you have all access, but if you log on an limited account, you will be limited (sure). So, you can install ur program with admin acc, and then run the program with limited acc. I think this's not what you want, but that is the only way (with my knowlegde). If you using Unix (or Linux), you can chmod 755 thefile (^_^), only root can copy it. Good luck.
|
|
|
|
|
Administrators (Administrator in Windows, root in *nix) always can gain access to all files.
It is, however, possible to "hide" files. That is, for example, what Sony did with their copy protection system. And it got them to court, because hiding a folder through tricks means that someone else can "adapt" to your folder and use it for dark purposes.
When you hide a folder (other than with File-Systems means of setting a "hide" attribute) you always will create a vulnerability.
If I was you, I would include an "important information" file in your folder and ask the user in the manual NOT to change, create or delete files in that folder.
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
|
I try to use named pipes with problem. I test following code:
HANDLE hPipe;<br />
LPVOID lpvMessage;<br />
CHAR chBuf[512];<br />
BOOL fSuccess;<br />
DWORD cbRead, cbWritten, dwMode;<br />
LPTSTR lpszPipename = "\\\\.\\pipe\\mynamedpipe";<br />
<br />
while (1) <br />
{ <br />
hPipe = CreateFile( <br />
lpszPipename,
GENERIC_READ |
GENERIC_WRITE, <br />
0,
NULL,
OPEN_EXISTING,
0,
NULL);
<br />
<br />
if (hPipe != INVALID_HANDLE_VALUE) <br />
break; <br />
<br />
<br />
if (GetLastError() != ERROR_PIPE_BUSY) <br />
cout <<"Could not open pipe"; <br />
<br />
<br />
if (! WaitNamedPipe(lpszPipename, 20000) ) <br />
cout <<"Could not open pipe"; <br />
}<br />
And I only get “Could not open pipe” from both CreateFile and WaitNamedPipe.
The error I get from GetLastError() is 2, "The system cannot find the file specified."
I can give the pipe any name and I get the same error.
|
|
|
|
|
Since you try to open the existing pipe \\\\.\\pipe\\mynamedpipe, does it really exist?
Where do you create the pipe?
|
|
|
|
|
I have 2 applications App1 and App2 in the same folder. App1 is a dialog. OnButton1 of Dialog of App1 i want to start the App2 and OnButton2 of App1 i want to close App2.
Can someone pls suggest any functions for this.
-- modified at 4:32 Friday 13th January, 2006
|
|
|
|
|
Try the following.
Use CreateProcess to start App2 and save the process information struct to be able to close the handles in it when you close either application.
Post WM_QUIT to the main thread of App2 when you want it to close. The thread ID is provided in the process information struct.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Use FindWindow() and postmessage function to send message to other app
|
|
|
|
|
That's one more solution.
I would choose the one I suggested earlier since I can post a WM_QUIT message using ::PostThreadMessage and I already have the thread ID which was given me in the process information parameter calling ::CreateProcess.
I would have everything I need to ask the second process to shutdown nicely, wait for it to end by waiting on the process handle and, if the process failed to close nicely after a desired timeout, I could terminate it using ::TerminateProcess.
I consider FindWindow an unnecessary round-trip, but it should work in most cases provided that the window name is known.
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Hello Everybody...
I had some confusion.
1.What are the basic diffence in building a program in Debug and Release in VC++ 6.0.
2.Is there any affect to the logic of the code in this two versions.
thanx in advance
birajendu
CyberG India
Delhi
India
|
|
|
|
|
|
the simpler you can do to see a difference is simply looking at the generated .exe files sizes.
in debug mode compilation, the file is more "heavy" because the compiler don't perform some optimizations, and the more important, it does insert some functions into the generated code to perform the debugging thing...
if you are able to use a breakpoint, a step by step debugging, etc, is thanks to these.
in release mode, the compiler tries to make the exe the more performant as possible... when you make a delivery version of a project, provide the release mode compiled version.
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
|
|
|
|
|
Very basic answer:
In Debug you can set breakpoints and step through the code to see how each line is executed. The code size is bigger (all symbols are loaded for debugging) and it is also slower. All code in ASSERT(), macros (which is usually checking if everything oes OK) is executed, letting you point out where exactely a program crashes.
In Release, compiler optimisations are turned on, and the code is smaller and usually much quicker. If the program crashes, all you get is a messagebox notification, and it is more difficult, if not impossible, to find out what instruction crashed.
As the names suggest, debug compilation is for debugging purposes, and the release compilation is used for building software released to your users/customers/rest of the world.
~RaGE();
|
|
|
|
|
thanx....to all of you
birajendu
CyberG India
Delhi
India
|
|
|
|
|
One important point which is mentioned in various articles on code project (eg. Survive the Release Build - see first reply) but has not appeared in the replies to you is that the debug build tends to initialise local variable storage to 0 when a function is called, while with Relese builds, you gvet whatever the contents were.
As long as your warning level checks for "variables used before being assigned values", this should not be a problem.
|
|
|
|
|
thanx Norman,
ya i was confused only due to the local variable issue,which behaved differently in debug and release versions.I had gone thru the code project article also.
Now I feel somewhat comfortable in understanding these problems..
Thanx a lot...
birajendu
CyberG India
Delhi
India
|
|
|
|
|
... initialise local variable storage to 0
Not that I have noticed. In fact, Visual C++ 6.0 and .NET 2002 both set unassigned variables to something like 0xCDCDCDCD.
Also in Debug mofe, apart from the preprocessor variable _DEBUG being defined, changes are made to several system functions, including new and delete to help catch problems with memory allocation. Allocated blocks of memory have guard bands around them. All user-written functions have code added at the beginning and end to look for problems.
If you release a Debug build, beware - there is debugging information in the .EXE file, a wonderful opportunity for hackers. Makes life so much easier for people to disassemble your program. Try writing a program that WILL crash, and compile it both in Debug mode and in Releae mode. Run the Release version outside the Visual C++ environment, as if it was an ordinary program being run. When it crashes, the system will offer to help debug it. Accept the defaults offered, and you will find yourself back in Visual C++, wondering what on earth you are looking at. Do the same with the Debug build and you will see the difference.
Note that the checks for unassigned variables are not foolproof, unfortunately. I have sometimes have the Debug version work perfectly, and the Release version of the same code crashes due to unasigned variables not being detected.
Shraddhan
|
|
|
|
|
i have to send messages between two applications. the communication should be synchronised. i.e the sender should wait till it gets a acknowledgement from the receiver. how can i proceed. please help..
|
|
|
|
|
|
To complete Mr Dunn' post, this is a code snippet that may help you. It is an answer to one of my questions on this forum, one or two years ago, where I tried to exchange CStrings between two apps. (Thanks to jhwurmbach and peterchen).
Another option is a WM_COPYDATA message. You will receive a copy of the data (but this is valid only while the message is processed, so create your own copy on the client side)
for a CString:
Sender:
CString myString = ...
COPYDATASTRUCT cds;
cds.dwData = 0;
cds.cbSize = (myString.GetLength()+1) * sizeof(TCHAR);
cds.lpData = (LPCTSTR) myString;
::SendMessage(hwndReceiver, WM_COPYDATA, (WPARAM) hwndSender, (LPARAM) &cds);
Receiver - WM_COPYDATA handler:
HWND sender = (HWND) wParam;
COPYDATASTRUCT & cds = *(COPYDATASTRUCT *)cds.lpData;
CString receivedString = (LPCTSTR) cds.lpData;
Note: this does not handle passing from UNICODE app to ASCII/MBCS app (or vice versa) correctly
~RaGE();
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
