|
thank you, very appreciated
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
You may also find that any driver specific questions will have a better chance of being seen by the specialists in this forum[^].
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
|
OSR[^] - These guys are the experts.
Check out their NT Insider articles.
|
|
|
|
|
as superman says, OSR, they do a free mag every two months, its very very good. Their website, osronline, is a must.
http://dumpanalysis.org/ is usefull for analysing dumps, something you are going to be doing a lot of.
Ndis.com is good for network stuff, like firewalls.
Most importantly you want to buy Walter Oneys book, programming the wdm, it is essential.
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: you want to buy Walter Oneys book
Bunch of thanks, downloaded it
Erudite_Eric wrote: OSR, they do a free mag every two months, its very very good.
Already signed up 
Erudite_Eric wrote: http://dumpanalysis.org/
I'll learn that aswell.
Erudite_Eric wrote: Ndis.com is good for network stuff, like firewalls.
Thank you, this could be very helpful in the future (including everything).
Do you suggest me working for a security company like Faronics (ever heard of Deep Freeze)?
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Yes, it will give you a lot of experience. I have worked on similar products, and file system drivers, such as those used by Faronics to control applicaiton execution and so on are some of the most complex to write.
==============================
Nothing to say.
|
|
|
|
|
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games).
Note: I am currently using possibility 2, but I'm not really happy with it.
1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly.
2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of if and/or switch statements.
3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C
So, what do you use/what would you use and what would you recommend for my needs?
Thanks in advance.
PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?
|
|
|
|
|
I think in error handling, performance should not be of concern. So, the "I'm writing a game, everything must be fast!" argument doesn't work here. Errors should always be the exception! 
Exceptions really help you to write smaller code. When using return values, you have to check them every time. If you forget to do so, you might miss an error. So they are really prone to bugs!
Exceptions on the other hand can't be simply ignored, and I think that's good.
|
|
|
|
|
TomasRiker2 wrote: Errors should always be the exception!
Well said! Can I quote you on this? 
|
|
|
|
|
forkbomber wrote: ...but I found out that exceptions can produce heck of a lot of overhead and extra time cost...
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
that sir is an *excellent* link to a great detail of information.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Joe's articles usually are.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Use exceptions for errors you can't recover from e.g:
- Wrong OpenGL version, throw an exception
- No memory - runtime throws an exception for you
- Can't find a critical game resource, a fall back texture, shader or something else that really must be there
- Some muppet's deleted a delay loaded DLL
- Steam doesn't initialise and you're using it for copy protection
- You can't open any file to save the game - throw an exception
Use return values for things you can recover from, e.g:
- Network connection flakey - you don't want your game to crash 'cause your cheap hosting server in Borneo is offline due to Orang-utan attack
- Can't find a game resource that you have a fallback for
- Steam can't share a file, back off and try again
- You can't open a save game file, back off and try again with a different name
If you're code looks ugly you're not using exceptions for critical errors and you've got exception handlers all over the place.
Ideally for yummy, perfect code you should only have exception handlers:
- At the top level of your code - around main, WinMain or whatever for your platform
- Around thread entry/exit functions
- Around window procedures/GUI callbacks
So basically:
- Exceptions are for critical errors
- Exception handlers only appear when your code is about to disapear UP the call stack into the OS, otherwise madness and the end of western civilisation will result.
Exceptions being really expensive is a myth. See one of the previous posts for details, or hey, measure it yourself.
|
|
|
|
|
Hey there and thanks to everybody for clearing things up.
I'm going to use exceptions now.
|
|
|
|
|
Without directly referencing your enumeration, these are the things you should consider:
1. You can't avoid exceptions completely as some DLLs may throw them, so you at least need to be able to catch them
2. Exceptions provide a built-in mechanism to pass messages and an error identifier, and you can easily extend exception objects to hold additional data.
3. Exceptions will pass control to the level of the next higher try block in the call stack, without having to forward a return values up through several function calls.
4. You can't 'forget' to check for an exception like you can forget to check an error return: provided you catch all exceptions in your main function, you can at the very least issue a meaningful error message before having to exit the program. In fact, exceptions are the only way to 100% prevent a 'silent death' of your application, and will prevent most cases of 'hanging' (except for those caused by infinite loops, and then only those cases where you didn't think to check on preconditions and throw an exception if not met...)
Note that the last point (being almost always able to catch an error before the app breaks down) may also allow you to recover sufficient status information for saving the game and resuming at that point! I would say that is a pretty strong point from the PoV of the gamer.
|
|
|
|
|
I have a Delphi application which Creates a shared memory uses CreateFileMapping, OpenFileMapping, MapViewOfFile functions.
Now I wanted to share the same memory for my MFC application. I used the OpenFileMapping, MapViewOfFile functions.
I created a structure exactly same in size as the Delphi application and mapped the structure object.
sample code:
HANDLE hMapObject2;
hMapObject2 = OpenFileMapping( FILE_MAP_ALL_ACCESS, FALSE, "PP101U3_SHARED");
if( !hMapObject2 )
{
AfxMessageBox("Failed to open Simpack DataBase");
return( 0 );
}
Simpack = ( struct SIMPACKDB *) MapViewOfFile( hMapObject2, FILE_MAP_ALL_ACCESS, 0, 0, 0 );
if( !Simpack )
{
AfxMessageBox("Failed to create Simpack File Map View");
return(0);
}
Esim->SPV1 = Simpack->SP_Z;I am able to read the values exactly correct for all the member variables in the structure.
But when I try to write value in the shared memory, its not changing. It shows the previous value immediately.
The value of Simpack->SP_Z[15] is 0.5010 as read
from the shared memory which is set by the Delphi application.
When I set or write the value of the same variable to the shared memory using the code:
Simpack->SP_Z[15] = 0.6123;it shows the previous value 0.5010. When I change the same variables value in the Delphi application it changes and shows the changed value here in the MFC application.
Please help me how to write the values in the shared memory. Is there anything wrong in the code?
|
|
|
|
|
It could be an issue of caching ...
Try to declare the structure instance with "volatile" and see if that helps.
|
|
|
|
|
Hi german "volatile" will not work. The memory must be created without cache. Try to find the "no cache"flat. And there is a better way: you can also use a segment like the following to share data:
#pragma data_seg("Share")
BOOL existed = FALSE;
#pragma data_seg()
#pragma comment(linker, "/section:Share,rws")
IMPORTANT: the no cache flag is also needed here.
please refer to MSDN, to find the flag.
|
|
|
|
|
CreateFileMapping
DWORD flProtect,
or SEC_NOCACHE
And
#pragma comment(linker, "/section:Share,rwsk")
both will work.
|
|
|
|
|
hello guys... I am trying to get and set the data in the combo box using GetItemDataPtr and SetItemDataPtr. I am facing problem when I use the function GetItemDataPtr . It return bad pointer. Here is what I do to add string
int iPosition = 0;
CString sName;
sName = "Ali";
for (int nIndex = 0; nIndex < 5; nIndex++)
{
iPosition = m_ComboNames->AddString(sName);
ASSERT (iPosition != CB_ERR);
ComboNames->SetItemDataPtr(iPosition, (void*)sName);
}
and to get the data from the combo box I do as under.
int index = m_Combo->GetCurSel();
CString str;
LPVOID ptr;
if(index != LB_ERR)
{
ptr = m_Combo->GetItemDataPtr(index);
str = (CString)ptr;
MessageBox(str );
}
As stated ealier, it shows very strange characters. How can I cast my ptr properly in order to get the value right? thnx for any input.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Probably your CString object, to which you store a pointer, doesn't exist any more when you're reading the pointer back. It looks like "sName" is declared locally and will get destroyed once the scope is exited.
Then your pointer points to a region of memory that now contains something else.
You can store a pointer to a CString inside your ComboBox. But you have to create this CString instance with new and not locally on the stack!
And don't forget to delete it later when you don't need it any more.
|
|
|
|
|
you are right this time.
but the problem is simple and basic.
|
|
|
|
|
Is sName a global or member variable?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: Is sName a global or member variable?
Its a local variable within the function.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Which means it goes away when the function ends. Make it a global or member variable.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
