|
Hi all, would anyone know what WinAPI you call to delete a file? Or is it standard C++ ? Just curious, thanx in advance!
|
|
|
|
|
Use the DeleteFile() API  see MSDN for the documentation
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
|
Heck I will throw in _rmdir( ) which is implemented in the C run-time library and possibly more portable
|
|
|
|
|
Or remove() to remove a FILE 
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the letter Z
|
|
|
|
|
Note though that adding C run-time commands increases the file size of the executable as these functions actually get compiled into the exe.. If you use Win32 API commands they are stored in a DLL somewhere (kernel32.dll for the DeleteFile() API), which are packaged with Windows anyway.. hence you save space and make the program more efficient
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
Hugh? 
You statically linking too the C runtime libs while dynamically linking to Win32 APIs?!?!. You know the C-RTL also comes in DLL flavours like msvcr80.dll, or msvcrt.dll.
|
|
|
|
|
Well, yes, dynamically linking to msvcrt.dll would solve this problem but otherwise the linker links the CRT functions into the executable (i believe anyway :p)..
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
In pure c++ or c,there's no such function can delete file,u must use API to do this.
|
|
|
|
|
I have a C++ dll (native using MFC), it is used from a few different applications. It works much of the time and has no memory issues that Purify can see. But the dll sometimes exits for no reason. No error is reported, it is not a crash or lockup. Since the Dll exits, it causes the application that uses it to exit too. Having no error reported, closing the forms, and being intermitant makes this difficult to debug. Any advise about what to look for in the code that typically causes this type of behaviour (other than forgetting to return)? Yes, the debugger could help but I have not been able to reproduce on a development PC yet.
TBC
|
|
|
|
|
Sorry if this is pretty unhelpful  but you could (and this would be PRETTY laborious) open a file stream and write data to it when certain tasks are performed in the DLL and also (if you can) write a message to the file when the DLL exits to determine what has happened..
I'm pretty sure it's not a memory buffer overload.. This would result in the application crashing, not just exiting.. However I'm not certain so a memory issue could be the problem.
Sorry I can't be of more help, but I don't have any of the source code to see for myself..
Hope this helps!
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
Thanks PerspX for the quick reply. That's what I needed to hear. I thought maybe I was missing another obvious cause of this symptom. File logging was a last resort. It's a fairly complicated dll with only a few public functions. Sorry I can't post any code, but I'm not permitted.
TBC
|
|
|
|
|
Yeah that's fine it also may help you to sort out any other bugs and even possibly make your coding more efficient
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
Are you using Threads in your DLL?
Unexplainable phenomenon - The try-catch in main function did not catch exceptions in a dll's thread. The exact same *complete- and silent exit* happened to my app.
It turned out that if a thread in the dll has an AccessViolation, accessing a NULL-element on a primitive-type array or other dangling reference problem, the exception catch of the host-app do not catch the execption in the dll's thread.
I think you should evaluate all array accessing routines and life-span of objects and its pointer contexts. -Or implement a errorlog. But I think by the time you find the faulty pointer or array, you well could've implemented a errorlog.
You should take this problem as a wake-up call for *your code is too complicated*. Debugging Spaghetti is not fun and a errorlog would help.
Hope this helps.
|
|
|
|
|
1) What is the difference between handle and pointer in terms of memory. Can my other process(non releated) see a handle/pointer. Lets say if my application has a pointer pointing to some data at at that memory location. Will it be possible for the other application to access that data? How?
2) What will one try to use LoadLibrary which shall load a exe and not execute it?
3) The return value from WinExec, which is a stripped-down version of CreateProcess, is a handle to a Windows NT executive object, whereas an instance handle, the value returned from LoadLibrary, is a virtual pointer.
|
|
|
|
|
tom groezer wrote: What is the difference between handle and pointer in terms of memory.
A handle is an "opaque" data type. You can't make any assumptions about what it is and the
implementation can be changed (in future versions) at any time. A handle could be a pointer, an
index, an atom, etc. A handle is NOT always a pointer.
tom groezer wrote: Can my other process(non releated) see a handle/pointer. Lets say if my application has a pointer
pointing to some data at at that memory location. Will it be possible for the other application
to access that data?
Each process has its own address space. You could pass a pointer to another process but the
pointer would be useless to the other process. To share memory between processes you could use
something like GlobalAlloc, which allocates memory on the global heap.
tom groezer wrote: The return value from WinExec, which is a stripped-down version of CreateProcess, is a handle to a
Windows NT executive object, whereas an instance handle, the value returned from LoadLibrary, is
a virtual pointer.
You seem to know alot about internal details like that Who cares, both functions are holdovers
from 16-bit Windows.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the letter Z
|
|
|
|
|
Is GlobalAlloc still valid in 32 bit systems. Also what is the transition of heap from 16 bit to 32 bits systems done to get rid of a global heap. Another offshoot of this question is where do the global objects and staic objects kept. Is it kept in a special area in memory.
The question was what is meant by a virtual pointer.
|
|
|
|
|
tom groezer wrote: The question was what is meant by a virtual pointer.
tom groezer wrote: whereas an instance handle, the value returned from LoadLibrary, is a virtual pointer
I thought LoadLibrary returned a handle. That's why I stated you seem to know the internals
Maybe the first few sentences at this link explain it?
Virtual Address Space[^]
And more on global/local 16/32-bit... Global and Local Functions[^]
tom groezer wrote: where do the global objects and staic objects kept.
In the object files? The EXE file? in memory when the process is created and the exe is loaded?
More great reading Peering Inside the PE: A Tour of the Win32 Portable Executable File Format[^]
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
|
Volatile type qualifier. The keyword declares a variable that's accessible by other processes. I don't know much about the subject and not many books talk about it. I think theres reason for it being a discreet matter .
Check out http://msdn2.microsoft.com/en-us/library/888bfst6(VS.80).aspx it gives an overview - you need to dig more for implantation examples.
Hope it helps.
|
|
|
|
|
InOut.NET wrote: The keyword declares a variable that's accessible by other processes
I'm going to respectfully disagree.
While volatile tells the compiler that variable may be changed by an external "process"
(something going on outside the scope of the variable like another thread, etc.) I don't
believe it makes a variable accessible by other executing processes.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
|
You're probably right.
It does seem a bit far-fetched that another EXE can change your variable.
|
|
|
|
|
InOut.NET wrote: It does seem a bit far-fetched that another EXE can change your variable.
In Windows, yes. On other systems it's entirely possible
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
|
I'm working on a program that requires a system tray icon, as it exists almost entirely in the background. I've been working off of the MSDN documentation, and I can get a tray icon to appear when I run the program. However, the window I gave doesn't receive any messages from the icon - I tried putting a call to Beep() in there just to see if it even got to that point, and nothing happens.
Here is the important parts of my code:
<br />
#define MSG_STATUSICON (WM_USER + 101)<br />
<br />
...<br />
<br />
<br />
NOTIFYICONDATA request;<br />
request.cbSize = sizeof(NOTIFYICONDATA);<br />
request.hWnd = HiddenWindow;<br />
request.uID = 0;<br />
request.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_ICONSCREEN_SMALL));<br />
strcpy((char *)&request.szTip, "Screen Monitor");<br />
request.uCallbackMessage = MSG_STATUSICON;<br />
request.uFlags = NIF_ICON | NIF_TIP | NIF_MESSAGE;<br />
<br />
<br />
BOOL result;<br />
result = Shell_NotifyIcon(NIM_ADD, &request);<br />
if (result != TRUE) {<br />
<br />
return -1;<br />
}<br />
<br />
...<br />
<br />
<br />
case WM_STATUSICON:<br />
<br />
switch (lParam) {<br />
case WM_RBUTTONUP:<br />
<br />
TaskbarIcon::ShowPopupMenu();<br />
break;<br />
case WM_CONTEXTMENU:<br />
<br />
TaskbarIcon::ShowPopupMenu();<br />
break;<br />
default:<br />
break;<br />
}<br />
return 0;<br />
break;<br />
So, yeah. I've told it that I'm using a message ID equal to WM_USER + 101, and I'm checking for that in the callback, but I'm not getting any messages when I right-click the icon. Any ideas?
|
|
|
|
|
|
No... I'm not using MFC, just the Windows API. Thanks, though.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
