|
I wouldn't consider it a trojan im trying to make. More of a monitering program. A trojan would be something where your think its something, but not. The monitering program I have made just needs a few adjustments. Like i would like others to use it, so instead of them having to edit the source code they can build a server from the client. That way they can put there ip in so that the server(more like a client since its reverse connecting)knows what to connect to. Also thx for the response Zac. You helped put me in the right direction.
|
|
|
|
|
I need to look at the HTTP packets for GET and POST transmitals to a web server, from a browser (IE, etc), in the case where a User is cliking on the SUBMIT button within a web page that has a Form on it.
We can use any browser, if that makes the job easier.
What I am trying to ultimately do is to mimic that action with my own C/C++ application.
Any help would be much appreciated. 
Thanks,
Robert
|
|
|
|
|
It would be implemented in the way of a proxy application. Just listen in a free port and using it as a internet proxy
|
|
|
|
|
Thanks! Got it working.
Robert
|
|
|
|
|
Hello everybody, i have a SDI application and i need to call a window to display view of a database, i know CRecordView, but i want to call a new window inside my application to display a database view. how can i accomplish this? anyone got any suggestions?
|
|
|
|
|
ivanris wrote: ...i want to call a new window...
To create a new window, use the Create() function. Otherwise, be a bit more specific.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
thanks for your answer, but what are the arguments for this function, if any?
|
|
|
|
|
ivanris wrote: what are the arguments for this function, if any?
That all depends on what CWnd object it is created in the context of. For example:
BOOL CComboBox::Create( DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID );
BOOL CButton::Create( LPCTSTR lpszCaption, DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID );
BOOL CSplitterWnd::Create( CWnd* pParentWnd, int nMaxRows,
int nMaxCols, SIZE sizeMin,
CCreateContext* pContext, DWORD dwStyle = WS_CHILD | WS_VISIBLE |WS_HSCROLL | WS_VSCROLL | SPLS_DYNAMIC_SPLIT,
UINT nID = AFX_IDW_PANE_FIRST );
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Pattern brush on Win98 can be created from a bitmap larger than 8x8 pixels.
The brush can be used by simple draw function, such as FillRect().
But, Region functions on Win98 use only first 8x8 pixels of the brush to paint, such as FillRgn(), other part of the brush is ignored.
There is no problem on XP, which uses whole brush to paint.
Many my customers still use Win98, so I want to create a FillRgn() function for Win98, which can use whole brush to paint any region as XP does.
Do you have any idea to help me to create the function?
|
|
|
|
|
the standard brute-force flood-fill algorithm is:
floodfill(x, y)
{
if (pixel(x,y)==searchColor)
{
paint(x,y,fillColor)
floodfill(x+1, y+1)
floodfill(x+1, y-1)
floodfill(x-1, y+1)
floodfill(x-1, y-1)
}
}
(even better, use a stack to eliminate the recursion - just push the 4 points onto the stack instead of doing the recursion, then loop and pop)
a patterned fill would replace paint(...) with a function to copy a pixel from the brush to the output pixelout = pixelBrush(x % brushW, y % brushH).
the fact that your brush could contain 'targetColor' complicates things, however - the standard algorithm would loop forever if you painted the output pixel the same color as the search color. one way to handle this would be to make a copy of your source image and do the standard floodfill on it, in memory, while also doing the patterned fill on the original image:
if (pixel(x,y)==searchColor)
{
paint(x,y,fillColor)
patternpaint_output_image(x,y)
...
}
if memory is an issue, you could use a monochrome/grayscale 'mask' image for the copy - set all searchColor pixels set to 0 and all others to 1. then do the standard floodfill on that image, while also putting brush pixels on your output image.
and, for speed, you'll need to do this on the actual pixels (with a DIB), and not using DC functions.
|
|
|
|
|
Hi Guys
Can anyone explain when it will quit from following loop
while(*d++=*s++); please explain whats it doing
|
|
|
|
|
The ++ is an increment, and is being used as a post-increment.
*d++ = *s++
is semantically equivalent to
*d = *s;
d = d + 1;
s = s + 1;
It is performing a copy.
It will stop copying when it has copied a zero value for the basic type, since in C/C++ you can use most expressions as values. If what s and d point to is a non-simple type (such as a class), then it may also invoke a conversion cast operator.
The basics of this is explained in the C Programming reference by Kernighan & Ritchie, and in many C++ beginner's books.
Steve S
Developer for hire
|
|
|
|
|
NitinPatil wrote: please explain whats it doing
It is creating a potential buffer overflow vulnerability. 
led mike
|
|
|
|
|
From the looks of it, it is doing a C-style string copy operation. I imagine your code looks something like the following:
void f(char* const s, char* d)
{
while (*d++ = *s++);
}
which is pretty much the same as writing strcpy(d, s);, and suffers from the same memory issues (say, if s does not have a terminating null character, or d is smaller than s).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
To put it simply, the loop will end when the expression "(*d++=*s++)" becomes zero. It will be zero when *d++ becomes zero. The *d++ will become zero when a zero is written to its address (which means that a zero will be copied from the *s++ source).
This code copies data from the address pointed to by "s" into the address pointed to by "d". After using both addresses "s" an "d" they will be incremented, thus pointing to the next element to copy.
The loop will stop after copying a null byte. So, most probably, it is an algorithm to copy null-terminated strings.
|
|
|
|
|
how i can send text from my program to testbox in external program
|
|
|
|
|
Have you looked at SetWindowText()?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Do you mean like keystrokes ( keyboard emulator ) ?
Do you want to send any data ( text or whatever kind of data ) to another application / program that running ?
AFAIK, there is a library on .NET to do it, called SendKeys.
But if you do not use any .NET then you may have to search on WINAPI documentation.
|
|
|
|
|
Why don't you store your text into an ASCII-file and read this file in the external program?
Good luck, Gerard
|
|
|
|
|
He can send his text direct to a program
|
|
|
|
|
|
yes it solved but some program didnt recive the text so i ahve its handle
|
|
|
|
|
As a security measure, we're trying to stop an application of our own creation having access to explicitly linked DLLs unless those DLLs are "licensed" for the particular installation of the application on a single PC. Each DLL typically exports the same basic functionality.
Thought occurs that a sneaky user could, knowing the name of a licensed DLL, rename another DLL to that name and get around the licence issue.
From looking at the binary of a DLL, the compiled name of the DLL is embedded therein, just before the list of exported functions. Is there a method for accessing this name programmatically, to check that it matches the actual physical filename (otherwise, the application will refuse to load the DLL)?
|
|
|
|
|
I have a problem related to a window that in some cases owns a context/popup menu.
Here is the code for the creation and tracking of the popup menu:
LRESULT
MyWindowClass::OnCreateAndTrackPopupMenu(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
HMENU aMenu = ::LoadMenu(_Module.GetResourceInstance(),(LPCTSTR)IDR_CONTEXT_MENU);
if(aMenu != NULL)
{
HMENU hSubMenu = ::GetSubMenu(aMenu,0);
if(hSubMenu != NULL)
{
SetForegroundWindow(m_hWnd);
TrackPopupMenuEx(hSubMenu,TPM_LEFTALIGN|TPM_TOPALIGN,pt.x,pt.y,m_hWnd,NULL);
::PostMessage(m_hWnd, WM_NULL, 0, 0);
}
::DestroyMenu(aMenu);
}
return 0;
}
My application response to a window message that should deal with the destruction of the window above:
LRESULT
MyMainClass::OnDestroyWindow(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
::PostMessage(MyWindowClass->m_hWnd,WM_CANCELMODE,0,0);
MyWindowClass->DestroyWindow();
delete MyWindowClass;
MyWindowClass= NULL;
return 0;
}
The problem: If the popup menu is present when the destruction (DestroyWindow()) takes place, the application will crash ("ERROR - Object deleted before window was destroyed"), because the popup menu still is active (still waiting for TrackPopupMenuEx() to return because WM_CANCELMODE never reach the window before it is destroyed).
So the question is, how can I make sure that the OnCreateAndTrackPopupMenu-function return before DestroyWindow() is executed?
john
|
|
|
|
|
you can do something like :
You call DestroyWindow ( to delete the Window object ), this will eventually call PostNcDestroy, in which you will do a delete this, to delete the C++ object,and before that, send a message ( SendMessage ) to the caller of the window to set its pointer to NULL.
For example :
void MyAutoDeleteDialog::PostNcDestroy()
{
BaseDialog::PostNcDestroy();
AfxGetMainWnd()->SendMessage( WM_AUTO_DELETE_DIALOG_CLOSED, 0, 0 );
delete this;
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
