|
here is a code snippet in Dietels 5th edition that i'm reading for my OOP class. I don't understand what the : x( value ) means in the constructor. The comment says initialize x to value, but can someone explain that to me in more detail please. I know its not inheritance because i haven't got to the chapter yet. Can some one please help. Here is the code snippet.
class Test
8 {
9 public:
10 Test( int = 0 ); // default constructor
11 void print() const;
12 private:
13 int x;
14 }; // end class Test
15
16 // constructor
17 Test::Test( int value )
18 : x( value ) // initialize x to value
19 {
20 // empty body
21 } // end constructor Test
.
.
.
|
|
|
|
|
That is how you initialize the private data member x.
Writing x = value inside the constructor will become assignment and not initialization.
Here is an example of both -
Initialization
int x = 10;
Assignment
int x;
x = 10;
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
i see it's a different way of initializing.
|
|
|
|
|
Initialization and assignment are 2 different things especially when dealing with classes.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Hi Member
Can i get deleted file from system?Can any body give me Algo or concept.How can i get it?Plz Help me
|
|
|
|
|
|
im trying to get RecentDocs registry info and put it in a listctrl the name part works fine but the data part i only get the first letter
#define MAX_KEY_LENGTH 255
#define MAX_VALUE_NAME 16383
TCHAR achValue[MAX_VALUE_NAME];
DWORD cchValue = MAX_VALUE_NAME;
HKEY hKey;
dwData = MAX_VALUE_NAME;
cchValue = MAX_VALUE_NAME;
achValue[0] = '\0';
retCode = RegEnumValue(hKey, i,
achValue,
&cchValue,
NULL,
&dwType,
(BYTE*)lpData,
(LPDWORD)&dwData);
if (retCode == ERROR_SUCCESS )
{
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, lpData);
index++;
}
im using vs 2008 and mfc can anyone tell me where im going wrong? 
|
|
|
|
|
Your attempting to pass a binary string to a function that expects a TCHAR string. You should convert it to some meaningful character string format first. The function will interpret the each byte of the binary value as char (char is a byte).
|
|
|
|
|
i forgot to add these
TCHAR lpData[MAX_VALUE_NAME];
DWORD dwType = REG_BINARY;
DWORD dwData = MAX_VALUE_NAME;
but it is a TCHAR so im still lost as to what to do to fix it 
|
|
|
|
|
Is yours a ANSI build (i.e. not UNICODE)?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
Change:
locoone wrote: if (retCode == ERROR_SUCCESS )
{
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, lpData);
index++;
}
to
if (retCode == ERROR_SUCCESS )
{
CString str = (wchar_t *) lpData;
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, str);
index++;
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
i changed it and i now get this error
error C2440: 'initializing' : cannot convert from 'wchar_t *' to 'ATL::CStringT<BaseType,StringTraits>'
|
|
|
|
|
Try (I haven't ATL here so I may only guess)
if (retCode == ERROR_SUCCESS )
{
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, CW2A(lpData));
index++;
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
that gives the same error 
but why am i only getting the first letter and not the whole value?
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs <--- thats what im tring to get
modified on Sunday, April 12, 2009 11:07 PM
|
|
|
|
|
locoone wrote: that gives the same error
It shouldn't.
locoone wrote: but why am i only getting the first letter and not the whole value?
Because lpData contains a UNICODE string, while you need a ANSI one.
Since seems you've troubles with ATL conversion macros, try using the oldie-goldie WideCharToMultyByte [^] function.
For instance (beware: quick and dirty fix):
if (retCode == ERROR_SUCCESS )
{
char buffer[200];
WideCharToMultiByte(CP_ACP, 0, lpData, -1, buffer, 200, NULL, NULL);
m_list.InsertItem(index, achValue);
m_list.SetItemText(index, 1, buffer);
index++;
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
that worked thanks man 
|
|
|
|
|
i was looking all over the net for that function and i found it in one of the best PE Protectors (yoda's protector)
i tried to strip that function but i cant seem to get it right , it erase alot more than the DOS Stub
if hope some1 can give me some pointers or the solution i would be grateful
IMAGE_DOS_HEADER image_dos_header;<br />
IMAGE_NT_HEADERS image_nt_headers;<br />
HANDLE hFile,hFMap;<br />
LPVOID FBase;<br />
LPBYTE lpFile;<br />
<br />
DWORD bufFileSize,dwBytesRead,dwBytesWritten;<br />
<br />
hFile = CreateFile("C:\\test.exe", GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);<br />
bufFileSize = GetFileSize(hFile, NULL);<br />
lpFile = new BYTE[bufFileSize];<br />
ReadFile(hFile, lpFile, bufFileSize, &dwBytesRead, NULL);<br />
CloseHandle(hFile);<br />
<br />
hFMap = CreateFileMapping(hFile, NULL, FILE_MAP_ALL_ACCESS, 0, 0, NULL);<br />
FBase = MapViewOfFile(hFMap, FILE_MAP_ALL_ACCESS, 0, 0, 0);<br />
<br />
CopyMemory(&image_dos_header,lpFile,sizeof(IMAGE_DOS_HEADER));<br />
CopyMemory(&image_nt_headers,lpFile + image_dos_header.e_lfanew,sizeof(IMAGE_NT_HEADERS));<br />
<br />
<br />
image_dos_header.e_cblp = 0x0040;<br />
image_dos_header.e_cp = 0x0001;<br />
image_dos_header.e_crlc = 0x0000;<br />
image_dos_header.e_cparhdr = 0x0002;<br />
image_dos_header.e_minalloc = 0x0004;<br />
image_dos_header.e_maxalloc = 0xFFFF;<br />
image_dos_header.e_ss = 0x0002;<br />
image_dos_header.e_sp = 0x0040;<br />
image_dos_header.e_csum = 0x0000;<br />
image_dos_header.e_ip = 0x000E;<br />
image_dos_header.e_cs = 0x0000;<br />
image_dos_header.e_lfarlc = 0x001C;<br />
image_dos_header.e_ovno = 0x0000;<br />
image_dos_header.e_res[0] = 0x0000;<br />
image_dos_header.e_res[1] = 0x0000;<br />
image_dos_header.e_res[2] = 0x6957;<br />
image_dos_header.e_res[3] = 0x336E;<br />
image_dos_header.e_oemid = 0x2032;<br />
image_dos_header.e_oeminfo = 0x6E6F;<br />
image_dos_header.e_res2[0] = 0x796C;<br />
image_dos_header.e_res2[1] = 0x0D21;<br />
image_dos_header.e_res2[2] = 0x240A;<br />
image_dos_header.e_res2[3] = 0xB40E;<br />
image_dos_header.e_res2[4] = 0xBA09;<br />
image_dos_header.e_res2[5] = 0x0000;<br />
image_dos_header.e_res2[6] = 0xCD1F;<br />
image_dos_header.e_res2[7] = 0xB821;<br />
image_dos_header.e_res2[8] = 0x4C01;<br />
image_dos_header.e_res2[9] = 0x21CD;<br />
image_dos_header.e_lfanew = 0x40;<br />
<br />
FillMemory(lpFile,image_nt_headers.OptionalHeader.SizeOfHeaders,0x10);<br />
<br />
hFile = CreateFile("C:\\test2.exe",GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);<br />
WriteFile(hFile, lpFile, bufFileSize, &dwBytesWritten, NULL);<br />
<br />
CloseHandle(hFile);<br />
FlushViewOfFile(FBase, 0);<br />
UnmapViewOfFile(FBase);
|
|
|
|
|
There are a number of good explanations of the Portable Executable file format on the Web. Here's one: Structure of the Portable Executable File Format[^]. A more complete description is Matt Pietrek's original article: Peering Inside the PE: A Tour of the Win32 Portable Executable File Format[^].
Are you trying to substitute a new DOS Stub for the existing one, or just eliminate it altogether? And, why? Is this necessary?
In Matt Pietrek's article, he starts out by saying: "The first few hundred bytes of the typical PE file are taken up by the MS-DOS stub. This stub is a tiny program that prints out something to the effect of "This program cannot be run in MS-DOS mode." So if you run a Win32-based program in an environment that doesn't support Win32, you'll get this informative error message."
Actually, the MS DOS Header is located at the beginning of the PE file: The MS-DOS header occupies the first 64 bytes of the PE file. You obviously know that because the structure is listed in your code:
WINNT.H
typedef struct _IMAGE_DOS_HEADER {
USHORT e_magic;
USHORT e_cblp;
USHORT e_cp;
USHORT e_crlc;
USHORT e_cparhdr;
USHORT e_minalloc;
USHORT e_maxalloc;
USHORT e_ss;
USHORT e_sp;
USHORT e_csum;
USHORT e_ip;
USHORT e_cs;
USHORT e_lfarlc;
USHORT e_ovno;
USHORT e_res[4];
USHORT e_oemid;
USHORT e_oeminfo;
USHORT e_res2[10];
LONG e_lfanew;
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
An imporvement on your code would be to read that IMAGE_DOS_HEADER.e_lfanew value, initially, and then attempt to rewrite your file data into the new version. But, your code appears to be correct in that respect, you write the NT Headers at that value without changing it. Your big problem is that you don't move all the rest of the file data forward in the new file, like you did with the initial headers (and change the corresponding header fields to reflect this). Many of these fields are RVAs (Relative Virtual Address, relative to the base loading address), which the Windows loader reads to locate the various PE file sections and their identifying headers.
Also, the CreateFileMapping and MapViewOfFile are executing with a file handle that you just closed. But, you don't seem to be using the address anyway, so it doesn't really matter. When you are initially attempting to get code lke this to work, you should be checking return values (the errors will be obvious).
Just out of curiosity, what happens when the Windows loader attempts to load your new file? Or, are you using a Hex Editor to examine the realigned structure?
|
|
|
|
|
what im trying to do is completely eliminate the DOS header and stub , but when i generate the new file it replace alot more bytes not just the Dos header and stub
Your big problem is that you don't move all the rest of the file data forward in the new file, like you did with the initial headers (and change the corres[ponding header fields to reflect this).
are you referring at the Entry Point? yes im aware than i will need to change the Enty Point so it points to the NT PE instead of the DOS Stub
modified on Saturday, April 11, 2009 4:16 PM
|
|
|
|
|
If you remove the MS DOS header, the Windows loader will fail to load your executable, because (from what the documentation says), the loader reads the IMAGE_DOS_HEADER.e_lfanew field (which contains the file offset of the IMAGE_NT_HEADERS). {Actually, I think it will load the file, it will just fail to execute properly.) I'm just guessing here, but I would guess that the loader checks alot of things to determine if the Portable Executable is valid. You could test this by calling LoadLibrary and providing your new file as a parameter, instead of just attempting to launch it normally ( with CreateProcess).
Actually, I have no idea what will happen when it encounters that space where the original IMAGE_NT_HEADERS used to be.
Did you actually try loading this new file?
In his article, Matt Pietrek states: "Immediately following the PE header in memory is an array of IMAGE_SECTION_HEADERs." This is the Section Table. Since the size of the NT header is known, I would guess that the loader has a problem resolving where to load the Section Table, if it cannot find it at it's normal location. This table contains it's own set of headers, many of it's fields are RVAs, that tell the loader where to find everything else in the file.
Also, (and I just realized this in re-reading your code) you call CopyMemory for the two PE headers, and then initialize a new IMAGE_DOS_HEADER, and you don't write this structure (nor the IMAGE_NT_HEADERS) to LPBYTE lpFile.
You should re-think your entire appraoch to the problem.
|
|
|
|
|
a thanks for the info , that helped alot , also i know its possible to accomplish this as ive seen it in many runtime PE packers/protectros
can you tell me the APIs or the progress to write the new IMAGE_DOS_HEADER back to BYTE?
|
|
|
|
|
If you're compiling and linking the program yourself using MS compilers then the simplest approach would be to put in a custom DOS stub using the linkers /STUB[^] switch. Put in one which simply does nothing and returns immediately.
Steve
|
|
|
|
|
thank you steve, but that function im trying to make is far all PE files, not just the ones i can compile
maybe Ashkbiz Danehkar , the creator of yoda protector , witch is a member here, can help me abit more on this
|
|
|
|
|
Pablo_Escobar,
I wrote a program like this a couple of monthes ago, except that it wasn't supposed to remove the MS DOS stub,...it was just supposed to analyze the structure of the DLL or executable and write an enormous amount of data to text file. It was a very memory-intensive application. There are no standard Microsoft APIs to do this efficiently. And, what you want to do is definately possible, you're just going to have to read through the available documentation and write alot of code.
You will find this reference invaluable: Microsoft Portable Executable and Common Object File Format Specification[^].
...and, YES, read anything you can find that Ashkbiz Danehkar has written CodeProject Articles by Ashkbiz Danehkar[^], he's excellent.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
