|
A common method is to store the checksum in an unused field in the EXE header. To calculate the checksum, you either ignore the EXE header entirely, or start calculating it at the byte following that field.
I can't remember where the field is off the top of my head, but it shouldn't be too hard to find with Google
--Mike--
"So where does that leave us? Well, it leaves us right back where we started, only more confused than before." -- Matt Gullett
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
|
|
|
|
|
So simple and so amazing. Thank you very much for your reply. I never thought about the fact that I can start reading the exe at any location.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
The "normal" way to do it is this:
1.
Write your program, which includes your checksum algorithm.
2.
Put in a constant string of a known length. This string must have an unique identifier (which can later be found, browsing through the exe file).
I.e. "____xyz____zyx____AAAA".
(This string is 22 bytes long + the null, making it 23.)
The "AAAA"-part is later gonna be replaced with the real checksum code (assuming that the checksum will be 4 bytes long).
3.
Write the check code (still in your program), working like this:
Open the exe file, read through it and calculate the checksum, but DON'T count the constant string! Instead, when the string is found, read the "AAAA"-part and interpret it as an integer (likely an unsigned int, depending on the checksum algorithm). Close the exe-file.
4.
Compare the calculated checksum with the checksum from the "AAAA"-part. If a match, the it is OK.
5.
Write another program, a;) checksum generator (re-use the code in step 3), but this time, when the ID is found, save the file offset to the "AAAA"-part. (Remember, don't count the ID-string!)
When the checksum is calculated, seek to the saved offset to the "AAAA"-part, convert the checksum to a string, and write it to the exe-file.
Of course, you must recalculate the checksum every time you compile your program.
Good luck.
kakan
|
|
|
|
|
Wow! That is a brilliant idea. Now, why couldn't I think of that? Thank you very much for your reply.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Your'e welcome. One advantage with this approach is that it works in any operating system, environment, and for all types of progs.
Good luck. Kakan.
|
|
|
|
|
The doc's for AcceptEx() state that :
On _WindowsXP_ or later, once the AcceptEx function completes and the SO_UPDATE_ACCEPT_CONTEXT option is set on the accepted socket, the local address associated with the accepted socket can also be retrieved using the getsockname function. Likewise, the remote address associated with the accepted socket can be retrieved using the getpeername function.
Great, but what do i do on Win2K ?
After setting SO_UPDATE_ACCEPT_CONTEXT getsockname() works but getpeername() doesn't - in fact it doesn't even give an error, just acts as a no-op.
I don't want to save the remote address from GetAcceptExSockaddrs() as state if i can get/set it in the socket.
I would like to be able to do one of the following :
1. Be able to set the peer address in the accepted socket to the remote address obtained from GetAcceptExSockaddrs() - is there a low-level way to do this ?
2. Use a function(s) other than getpeername() that will also give me the peer address.
3. Give up programming and find a remote tropical island where the most advanced piece of technology i have to deal with is the ice-cooler that's keeping my beer cold.
Any suggestions ?
...cmk
|
|
|
|
|
cmk wrote:
3. Give up programming and find a remote tropical island where the most advanced piece of technology i have to deal with is the ice-cooler that's keeping my beer cold.
That sounds like the best one 
Seriously, getpeername() should work, unless there's some obscure reason why it doesn't. Does it work if you don't set SO_UPDATE_ACCEPT_CONTEXT? It only mentions this flag for WinXP, so perhaps it's not necessary for pre-WinXP machines. Certainly, I've used getpeername() successfully on pre-WinXP machines, although I've generally used accept(), not AcceptEx()
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
>>Does it work if you don't set SO_UPDATE_ACCEPT_CONTEXT?
No, if i don't set SO_UPDATE_ACCEPT_CONTEXT then even getsockname() won't work.
I think they mention XP because they finally got around to fixing it there. 
The problem is only with AcceptEx(), not accept() or WSAAccept().
Part of the problem is that accept() and WSAAccept() are sync calls that block until a connection is available and then they create the socket and establish the connection in one shot.
AcceptEx() is async and requires the socket to be created, then an AcceptEx() request posted. When a connection is available the winsock lib (?) attaches the connection to the pre-created socket but does not set any other state information. Setting SO_UPDATE_ACCEPT_CONTEXT copies the state info from the listening socket to the accepted socket (or is supposed to anyways).
It looks like it doesn't do a complete job in Win2K, so i was hoping to find a low-level way of setting it myself, or find another way of obtaining the peer address from the handle (there has to be a way as netstat shows both sides of the connection).
...cmk
|
|
|
|
|
Is there any particular reason why you don't want to save the remote address returned by AcceptEx() (using GetAcceptExSockaddrs() as you mentioned before)? It sounds to me like there's not much choice.
If you can find out how netstat does it, then that would be the way to go, but I'm not sure how it does it, so you'll have to a bit more investigation
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
>> Is there any particular reason why you don't want to save the remote address returned by AcceptEx() (using GetAcceptExSockaddrs() as you mentioned before)?
It bothers me at a very fundamental level to store state that i can get from a cheap function call.
>> It sounds to me like there's not much choice.
<sigh> at this point i expect you're right (was up until 2:30am looking for other workarounds - no joy).
I'll either derive a new socket class for accepted connections, add a peer address field and then overload my GetPeerAddr() method ... what a senseless waste, or go back to sync WSAAccept() (looking like the 'cleaner' solution).
...cmk
|
|
|
|
|
cmk wrote:
It bothers me at a very fundamental level to store state that i can get from a cheap function call.
What's the difference between you storing the address returned by AcceptEx() and referencing it at any time, and the sockets implementation storing the address returned by AcceptEx() and you calling a function to retrieve it. It sounds pretty similar to me, except that the first one is more efficient than the second.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
What's the difference between you storing the address returned by AcceptEx() and referencing it at any time, and the sockets implementation storing the address returned by AcceptEx() and you calling a function to retrieve it.
When i store the address i am duplicating what is already in memory somewhere, that is i am using twice as much memory to store the peer address as i should have to (once in the winsock lib, once in my code).
So when we talk about efficiency it is faster for me to access the address if i store it, but it is less memory if i can use the address that the winsock lib has. As we are talking about connections, if you have a server that deals with 1,000's of simultaneous connections this can add up (ok, not much, but enough that it bothers me ).
Anyways, i've already coded my work around.
Added an #ifdef CKNET_USE_ACCEPTEX that if enabled uses AcceptEx and adds a peer address field to my connection class, #ifndef then tie up one (or more) of the IOCP threads to sit in a loop waiting on accept(). I find both acceptable workarounds for now.
...cmk
|
|
|
|
|
Hi:
how to get the current windows system language name? I want to know if it is English or the other languages(such as chinese, japanese)
|
|
|
|
|
Check out the PRIMARYLANGID macro. I hope that helps you.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Look at the GetLocaleInfo() function, specifying either LOCALE_SYSTEM_DEFAULT or LOCALE_USER_DEFAULT for the first parameter.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Man, I wish I had heard about that function a year ago. Good job Ryan! Your replies never cease to amaze me. I truly learn a lot from your posts.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
Your replies never cease to amaze me. I truly learn a lot from your posts.
so true.
~RaGE();
|
|
|
|
|
Thanks
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
|
You're welcome
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Can we get a handle or icon id of an item which has been inserted in to a ListCtrl?
Example: if we have two icons in our image list and we inserted 100 items in the list can we find out if item 30 has icon #1 displayed with it or icon #2 displayed with it
P.S we are assuming that a image list has been associated to the control.
|
|
|
|
|
If you're using MFC, do this:
LVITEM lvi;
lvi.mask = LVIF_IMAGE;
lvi.iItem = nItemIndex;
m_listCtrl.GetItem(&lvi);
If you're not using MFC, do it this way:
LVITEM lvi;
lvi.mask = LVIF_IMAGE;
lvi.iItem = nItemIndex;
SendMessage(hwndListCtrl, LVM_GETITEM, 0, (LPARAM)&lvi);
Hope this helps,
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
I create a dialog.
And it is not expected to be closed when pressing the "Esc" key.
How to solve this problem?
Thank you in advance
|
|
|
|
|
Try to override CDialog::OnCancel().
Something like
void CMyDialog::OnCancel() { return;}
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
It works well after I do as your directions.
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
