Couldnt an evil app on the client's side simply obtain the key and decrypt as well?

Hello, Sorry if this is a completely lame question, but is there a approach that allows info to be securely sent server->client->server such that only the client application, and no other application on the client's side, can intercept it? This would be useful in situations where the client application only wants certain parts of the incomming data to be available to the client's user, and can not assume the client is not peeking (monitoring incoming traffic). Thanks, KnaveWave Oi! Oi! Oi!

I am an upcoming Dec '05 grad from a top tier university with a BS in CS, and have reached the initial stages of salary negotiation with a company in San Jose. At this point, no numbers have been mentioned, but the company is asking me to fill out a form with what I have in mind. I have a rough idea with what I would make in my own area, but when I try using income conversion tools to calculate an equivalent salary in the San Jose are, the numbers are so much larger that I am skeptical about their results. Im assuming these tools account for the costs of owning a house, which to my understanding is not realistic in the San Jose area. I have also looked into different salary statistics reports for both areas, and have found these reports to be very missleading: contradictions, old data, and no clues as to what a grad from a top univerisity should expect when starting out. So, for those of you familiar with the San Jose area, what should I expect? :)

Hello All, I have an application that runs without error on my own system. Even in release mode :-D. However, when i run the application on other systems, my app reports to me that it was undable to aquire a crypt context (CryptAcquireContext) due to an invalid param. This code is called in a simple C worker thread. Any Ideas? UINT stringHash(byte* message, char* hash){ DWORD hashLen = 16; HCRYPTPROV hCryptProv; HCRYPTHASH hHash; // zeroing just in case CryptAquireContext is getting garbage somehow ZeroMemory(&hCryptProv, sizeof(hCryptProv)); ZeroMemory(&hHash,sizeof(hHash)); BYTE hashedBytes[16]; // Aquire Crypto Handle - fails if (!CryptAcquireContext(&hCryptProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0)){ CryptReleaseContext(hCryptProv,0); return GetLastError(); } ...

Hello all, I recently compiled a release build of a project and ran into initial problems that would cause the application to fail. After correcting these problems (program appears to function properly w/ no crashes), I decided to send it to some friends to test out. On the first attempt, my friend reported he receive a msg asking for MSVCPP70. Thinking that this might be a MFC dll issue i went into my project settings and set the option to use mfc in a static library. After doing this, my program will run, except for a feature which communicates w/ a server via a worker thread. The odd thing is... the application runs flawlessly on my own system. What issues do you think I am running into? Are there dlls that i should be coupling w/ my release build?

Hey all, Im having a problem with passing a var to a function via AfxBeginThread. It appears the function is being called properly, but my data, which is in the form of a pointer to one of my ServerData classes, appears corrupted in the eyes of the thread function (debugger shows data as it should be before call, inside thread function, everything is chaotic). This is the code the starts the thread (triggered by a CListView message): LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]); ServerData* sdat = (ServerData*)ptr; // debugger shows sdat to be intact CWinThread* thread = AfxBeginThread(&queryServer, ptr); This is performed at the begining of my thread func: UINT queryServer(LPVOID pParam ){ ServerData* server = ((ServerData*)pParam); // the var server has bad data ... } ServerData's LPVOID cast operator is simply defined as: return this; Any ideas?

You are Da Man!!! A million thnx!!! Have you just tried returning FALSE instead of other processing, as per this note... Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc. Originally I was returning FALSE, but was not using IsDialogMessage. Hope that this helps someone in the future.

DefDlgProc will cause infinite recursion if i use it :(

Thnx for pointing that out, but it seems something else might be amiss. I just tried putting my "return DefWindowProc(hwnd, uMsg, wParam, lParam);" statement at the top so that all messages would be handled by the default window proc, thinking that this would allow my dialog to perform basic dragable behavior, but it is still not budging. One other thing i noticed is that if i use my hDlg, which i get from CreateDialog(), inside the DefWindowProc an exception is thrown. Am I wrong in thinking that this should work, as hDlg works with calls to DestroyWindow? I also would like to thank you all for your help, I have spent many days trying to track down what I am doing wrong.

Thnx for this suggestion, I was wondering how GetMessage could could possibly be knowing that the msg was for my dialog... this answered that. However, I am still unable to move the dialog, any suggestions?

Hey all Ive created a API modeless dialog inside of a DLL, and is created whenever the calling program calls the appropriate exported function. In a past thread that i posted, this dialog would cause the application to lock up with the not responding dialog. Thanks to someones tip to use DefWindowProc() I can now get the dialog to work (pops up, and close button properly closes when clicked), only it appears to not be responding to move messages (the message called when i would like to drag the dialog around on the screen). From DLLMain: hDLL = hinstDLL; The exported function that starts the dialog: //mWnd is handle to main window of calling program //aWnd is handle to active window (programm calling is MDI) int __stdcall WINAPI x(HWND mWnd, HWND aWnd, char *data, char *params, BOOL show, BOOL nopause){ MSG msg; hDlg = CreateDialog(hDLL, MAKEINTRESOURCE(IDD_DIALOG1), mWnd, (DLGPROC)DlgCallBack); ShowWindow(hDlg,SW_SHOW); while (GetMessage(&msg, NULL, 0,0)) { TranslateMessage(&msg); DispatchMessage(&msg); } } The DLGPROC: LRESULT CALLBACK x(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam){ switch (uMsg) { case WM_COMMAND: switch(wParam){ case IDOK: DestroyWindow(hDlg); return TRUE; } break; case WM_DESTROY: DestroyWindow(hDlg); PostQuitMessage(0); return TRUE; } return DefWindowProc(hwnd, uMsg, wParam, lParam); }

Thnx to both of you.... Sorry for the late reply Sorry for not properly specifying, but by locking up i ment the infamous " has encountered a problem and needs to close" was poping up. For further clarification on what causes this lock up, this occurs anytime I click on the window of the app (mIRC) that calls my dll or move the mouse into my dialog's window. Anyways, after using DefDlgProc, this problem goes away, but the calling app (mIRC) immediately terminates without notice. Any ideas?

Hello All, I have created a DLL that has an export which calls CreateDialog to make a modeless DLL. CreateDialog(hDLL, MAKEINTRESOURCE(IDD_DIALOG1), mWnd, (DLGPROC)DlgCallBack); When called, the dialog pops up and everything seems to go right... but locks-up as soon as i click or drag mouse into the dialog. My guess is that something might be going wrong with the way I handle messages or something weird caused by using a dll that I am not aware of, but am not sure since i am new to windows programming. Here is the code in my callback switch(uMsg) { case WM_COMMAND: switch(wParam){ case IDOK: return TRUE; } break; case WM_DESTROY: PostQuitMessage(0); return true; case WM_CLOSE: DestroyWindow(hwnd); return TRUE; } return FALSE;

I have been working on a DLL w/ a basic CDialog. At this point, my dialog can be loaded with my testerApp and appears to work (can drag arround click buttons etc), but there appears to be something odd going on when switching to the module state. When the my dll's CWinApp::InitInstance() is called, this is 0x101c8640. In calls to the dll's exported funcs this is 0x0012fdac (the same as my tester app). Any ideas on what I am doing wrong? BOOL CWM_Script_DLLApp::InitInstance() { CWinApp::InitInstance(); dlg = NULL; return TRUE; } extern "C" void CWM_Script_DLLApp::createDialog(void) { AFX_MANAGE_STATE(AfxGetStaticModuleState( )) if(dlg == NULL){ dlg = new CTestDlg(CWnd::GetDesktopWindow(),this); //pass this so dlg can be set to null on close dlg->Create(CTestDlg::IDD); dlg->ShowWindow(SW_SHOW); } else{ dlg->SetActiveWindow(); } } void CWM_Script_DLLApp::killTestDlg(void) { dlg = NULL; }

Hello All, I have been working on a DLL (Regular DLL with MFC statically linked) that contains a CDialog that I would like to run as modeless. In order to reset the CWinApp's ref to the Dialog to NULL when the Dialog closes, I am trying to store a pointer to the CWinApp so that I can m_pApp->setMyDlgNull(). It seems as if this should work, but whenever I try to add the pointer into my CDialog class, the compiler acts like it does not know what my CDLLApp is. I am not sure what is going on as I have #included my CWinApp's header and I can get the popup with my setMyDlgNull() function when using CDLLApp:: (does not happen when i do not #include). I am sure that I have made the most idiotic mistake so go easy on me :)

Hey all, I was wondering how I might go about mixing a C++ dll with C# windows form. I am currently creating a C++ dll to use within another application that allows scripts to call into dlls, for a fun/learning project. Though I have been able to figure out how to perform simple function calls, I am a bit clueless as to how I might go adding GUI components into the mix. In the end I would like to able to add a toolbar to the outside application. Ideally, because it is so simple to create windows forms in C#, I would like to be able to create the toolbar in C# and have it call my dll functions. Though I have done some searching, I am a bit lost on where to even begin. As a first step, I would like to write a simple function in my C++ dll that creates a simple HelloWorld windows form (script calls dll's helloWorld -> dll creates C# form). Though I can do either by itself, I am not sure how to call the form from within the dll, as well as how to go about having C# and C++ in the same visual studio project. If anyone could point me in the right direction, I would be very thankful.

Hello All.. im new to multithreaded programming and have a couple q's. So far ive got a simple test program working that launches a worker thread via Daniel Lohmann's kewl adapter, but i have a few questions. How do i go about passing data w/ the function? Do i need a Class or struct that encapsulates all the data and pass a ptr of it to the function? Then what about my functions that i need to call from within my thread function... should these just go inside the 'Test' struct that my thread function is in... or are they something like static members of my data class?

thnx... i dont know what i was thinking I switched it to a do--while w/ (bytesRecv != SOCKET_ERROR) and now i receive tons of packets and jump out of the loop with bytesRecv == 0. Is this the normal behavior for such a transaction to end? Ive noticed several empty data packets being sent in the sniffer. Are these special packets that singal 'received' and so forth? If so, is my app receiving a special 'transfer done' packet that causes my last recv to unblock and return 0 bytes? I dont know what the server is doing since it is not my app, its a particular games master server with a list of public game servers. I know all of this sounds pretty dumb, but this is a learning experiment where im trying to dive in a learn what is going on at the packet and app level. thnx

Hello! Im fairly new to winsock programing, and am having trouble receiving a response that is spread accross several packets. I have been watching the communications through a packet sniffer, and know that 30 to 40 1500 byte sized packets are comming in with good data, but my program is only executing one recv and reporting a bytes Recv of 9. There must be some concept that im completely missing :( any help would be greatly appreciated. heres my code: bytesRecv = SOCKET_ERROR; char queryRecvBuff[1500] = ""; CString reply = ""; send(m_socket,serverQuery,30,0); TRACE("SENT\nRECEIVING:\n"); while( bytesRecv == SOCKET_ERROR ) { bytesRecv = recv( m_socket, queryRecvBuff, 1500, 0); if ( bytesRecv == 0 || bytesRecv == WSAECONNRESET ) { TRACE( "Connection Closed in Auth.\n"); break; } if (bytesRecv < 0){ TRACE("\tbytes Recv < 0!!!"); return; } reply.Append(queryRecvBuff,bytesRecv); TRACE( "\tBytes Recv: %ld\n", bytesRecv ); } TRACE("\nRECEIVED"); output: WAITING FOR Verification: VERIFIED Sending Query: SENT RECEIVING: Bytes Recv: 9 RECEIVED