|
Can exceptions in C++ be used without an operating system? How does the compiler implement exceptions with and with out the OS?
|
|
|
|
|
it's up to the compiler's author to implement such choices. BTW, he MUST implement the exceptions system, because as a part of the C++ language, it is something that everyone using this language can excepts to be using.
|
|
|
|
|
If he wants programs to compile for Windows does he have to implement them a certain way?
|
|
|
|
|
No. Windows doesn't force any particular exception mechanism. I would think that processor architecture (call/return and stack implementation, if any) would dictate how exceptions are implemented.
Microsoft built their exception mechanism so that it would co-exist with structured exception handling. SEH was a mechanism built back in the Windows 'C' programming days for critical error handling, which predates compiler-provided exception mechanisms.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: Windows doesn't force any particular exception mechanism.
How does an exception from a thrown from a native .DLL travel up to an application that uses it? Wouldn't it have to go through Windows?
|
|
|
|
|
CataclysmicQuantums wrote: Wouldn't it have to go through Windows?
No. The C runtime (e.g. MSVCRT) ties the exception system together applying filters and calling installed handlers and the like. Internally it's hooked into signals at the OS level but I don't think it needs them to handle C++ exceptions within a User mode process.
Remember exception handling is all to do with stack manipulation so as long as the excepting functions runtime data is on the same call stack as the handler it doesn't matter which module the code is in.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
How do you mean without an operating system. Neither Compiler, nor Computer can work without an Operating System.
The Exception handling mechanism depends on the Compiler and Operating system singing together. Neither will work without the OS. For your own benefit, Just try and investigate 3 points: 1. What's an OS, 2. What do you need to write to make your laptop work whitout Say XP or win95, If all fais Try to run your laptop whitout an Operating System. The best way of trying this is to wipe your hard disk. Do I Get the Point?
I Gave the Long Answer to your question above,
The Short answer is No and NO!
Bram van Kampen
|
|
|
|
|
It’s implementation dependent, as others have alluded to, but on windows it is generally implemented in terms of the OS supplied SEH. All Microsoft compilers (for Windows) layer the compiler’s exception handling code over of OS supplied SEH mechanism. Here’s a link I came across years ago which may be of interest:
A Crash Course on the Depths of Win32™ Structured Exception Handling[^]
Steve
|
|
|
|
|
Thanks that was a good read. I haven't read the entire thing yet but it has already answered some questions I had. Sometimes I get a question stuck in my head and it needs to be answered or else I will obsess.
|
|
|
|
|
Hi this is my first post...
I would like to be lead in the right direction. I'm wanting to take a bitmap that is in the clipboard and look at the pixels in rgb. How can this be done while not using MFC. I am using VC++ express.
|
|
|
|
|
You can read rad values of the clipboard with Clipboards Functions[^] After read bitmap of clipboard you can use of GetPixel() it returns COLORREF value then you can use of GetRvalue/GetGvalue/GetBvalue.
|
|
|
|
|
Hi all,
I have a Dialog Box and in that i have made a picture control. In that picture control i have attached a bitmap through properties, now my problem is that on a button click event i want to change bmp and i don't know how to do it...........
Please anybody could help me with this.......
Thanks in advance
|
|
|
|
|
Why you dont use of CBitmapButton Class?
|
|
|
|
|
A picturebox is a static control. You can use the STM_SETIMAGE[^] message
to change the static control's bitmap.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi all,
Actually i am a VC++(6.0) programmer and recenty started working on vc 2005 and i am not getting Class wizard in VC 2005 like i have got how to add a variable how to add event handler for a particular control but what if i want to add a OnLButtonDown code for my dialog box....
Can anybody please help me with this...
Thanks in advance
|
|
|
|
|
There's no more class wizard (probably the #1 complaint  )
It's now split in 2 windows. From the view menu, open the class view window.
Right-click the dialog class (or highlight and use f4) to get the properties window.
The properties window has tabs for messages, overrides, etc.
On the messages tab, you can scroll to the message you want to handle and click in
the right column to add a handler method.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I got it.....
Thanks for your reply....
It really helped me a lot.
|
|
|
|
|
actually there are 3 ways to achieve that,
1) use the class view tab of ur solution explorer and right click select properties, where all ur control ids exist from which u can add a function. and also u can add function overrides.
2) use the resource view and open the dialog, select control and properties of it and add functions likewise.
3) double click the control, it auto adds the handler.
Prasann
who else.
|
|
|
|
|
Prasann Mayekar wrote: who else.
ME!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Recently, after rewriting a part of my code for multithreading, I noticed that after return from main(), the program doesn't quit. So I added ExitProcess() there. Doesn't work. TerminateThread(). Doesn't work. Doesn't return control. Then I tried to manually kill all the threads I started ( it wasn't necessary before, they should never hang ). Also doesn't return.
Furthermore, the process cannot be killed in any way. Advanced Process Terminator can't do it.
Any clue?
|
|
|
|
|
If you break in the debugger when it's hanging, where is the instruction pointer
and how many threads are still active at that point?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Unable to attach a debugger.
-- modified at 3:18 Saturday 24th November, 2007
Checked the currently running ones with Process Explorer. 19-139 threads. The newer instance-the more threads. How many did I create in total? One for each open file handle, system-wide. I noticed that each running copy of my program leaves some handles unclosed...and number of them is close to the number of threads left...(didn't count precisely, every 5-6 versions I have to restart computer, then I have a problem with resource allocation. And windows (XP SP2 BTW) also has some problems with killing them - closing system is ridiculously slow).
|
|
|
|
|
maciu2020 wrote: Unable to attach a debugger
hmm...why?
It really sounds like you have active threads left running.
Closing a thread handle does not eliminate the thread.
All threads should terminate themselves by returning.
Some thread, usually the "main" thread, should wait for all the threads to terminate.
If you're resorting to TerminateThread() and other abnormal ways of stopping a thread,
chances are you've got a bad design. You shouldn't ever need to terminate a thread or
process forcefully.
Also, make sure you use the proper thread creation functions, depending on what
the thread uses:
straight Win32 APIs, use CreateThread()
C runtime (CRT), which includes using new/delete, use _beginthread[ex]()
MFC (which uses all of the above), use AfxBeginThread()
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: maciu2020 wrote:
Unable to attach a debugger
hmm...why?
This is what OllyDbg tells me..
Mark Salsbery wrote: It really sounds like you have active threads left running.
Closing a thread handle does not eliminate the thread.
All threads should terminate themselves by returning.
Sure. All threads should do it as they have no loops or infinite waits. And when I run one at the time, they all return.
Mark Salsbery wrote: You shouldn't ever need to terminate a thread or
process forcefully.
Yep. And I didn't do it until this strange case.
Mark Salsbery wrote: Also, make sure you use the proper thread creation functions, depending on what
the thread uses:
I use the correct one.
I thing it would be good to post the code. It's a slightly modified part of Zoltan Csizmadia's SystemInfo library.
My ThreadProc just calls GetFileName() as below. For readability, I stripped security checks and cleanup.
<br />
BOOL SystemHandleInformation::GetFileName( HANDLE h, CString& str, DWORD processId ) throw()<br />
{<br />
ULONG size = 0x8000;<br />
UCHAR* lpBuffer = NULL;<br />
BOOL ret = FALSE;<br />
<br />
HANDLE handle;<br />
HANDLE hRemoteProcess;<br />
BOOL remote = processId != GetCurrentProcessId();<br />
DWORD dwId = 0;<br />
HANDLE hHeap;<br />
<br />
<br />
if ( remote )<br />
{<br />
hRemoteProcess = ::OpenProcess( PROCESS_DUP_HANDLE, TRUE, processId );<br />
<br />
handle = DuplicateHandle( hRemoteProcess, h );<br />
}<br />
else<br />
handle = h;<br />
<br />
<br />
ret = GetFileNameHelper( handle, str );<br />
<br />
INtDll::NtQueryObject ( handle, 1, NULL, 0, &size );<br />
<br />
lpBuffer = (UCHAR*)HeapAlloc(hHeap = GetProcessHeap(), 0, sizeof(UCHAR)*size);<br />
<br />
if ( INtDll::NtQueryObject( handle, 1, lpBuffer, size, NULL ) == 0 )<br />
{<br />
SystemInfoUtils::Unicode2CString( (UNICODE_STRING*)lpBuffer, str );<br />
ret = TRUE;<br />
}<br />
<br />
<br />
return ret;<br />
}<br />
<br />
#define FILE_NAME_INFORMATION 9<br />
<br />
void __cdecl SystemHandleInformation::GetFileNameThread( PVOID pParam ) throw()<br />
{<br />
GetFileNameThreadParam* p = (GetFileNameThreadParam*)pParam;<br />
<br />
UCHAR *lpBuffer = (UCHAR*)<br />
VirtualAlloc( NULL, 0x1000*sizeof(UCHAR), MEM_COMMIT, PAGE_READWRITE );<br />
DWORD iob[2];<br />
<br />
p->rc = INtDll::NtQueryInformationFile( p->hFile, iob, lpBuffer, sizeof(lpBuffer), FILE_NAME_INFORMATION );<br />
<br />
if ( p->rc == 0 )<br />
*p->pName = lpBuffer;<br />
<br />
VirtualFree( lpBuffer, 0, MEM_RELEASE );<br />
}<br />
<br />
BOOL SystemHandleInformation::GetFileNameHelper( HANDLE handle, CString& str, DWORD processId ) throw()<br />
{<br />
BOOL ret=FALSE;<br />
HANDLE hThread;<br />
GetFileNameThreadParam tp; <br />
<br />
<br />
tp.hFile = handle;<br />
tp.pName = &str;<br />
tp.rc = 0;<br />
<br />
hThread = (HANDLE)_beginthread( GetFileNameThread, 0, &tp );<br />
<br />
if ( hThread == NULL )<br />
goto cleanup;<br />
<br />
if ( WaitForSingleObject( hThread, 80 ) == WAIT_TIMEOUT )<br />
{ <br />
TerminateThread( hThread, 0 );<br />
<br />
str = _T("");<br />
<br />
ret = TRUE;<br />
<br />
}<br />
else<br />
ret = ( tp.rc == 0 );<br />
<br />
return ret;<br />
}<br />
|
|
|
|
|
maciu2020 wrote: Sure. All threads should do it as they have no loops or infinite waits. And when I run one at the time, they all return.
"Should"?? No, they MUST. Your process cannot exit until they do.
maciu2020 wrote: // Wait for finishing the thread
if ( WaitForSingleObject( hThread, 80 ) == WAIT_TIMEOUT )
{
// Access denied
// Terminate the thread
TerminateThread( hThread, 0 );
Why did you pick 80ms to wait here? What if it takes 81ms?
I'm not sure what to say here, there's just no thread synchronization that I see.
If you have a function that never returns under certain conditions, and this is the
only solution, then all I can think of is trying _endthread() instead of TerminateThread().
Note that even if it works, this is still a kludge - You have no idea what state the system is
left in.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
