|
Just in case you haven't already read it, the following is from the documentation of Windows Sockets Error Codes[^] in MSDN:
WSAEACCES
10013
Permission denied.
An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST).
Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4 SP4 or later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4 SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option.
See also: Windows Sockets Network Programming - Appendix C: Error Reference[^]
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Besides, what's the type of filter_path ? Why do you need a cast to (unsigned short*) ?
Hint: if filter_path is a char* , as I suspect, simply casting to (unsigned short*) won't work.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
<br />
PIMAGE_DOS_HEADER pDosHeader;<br />
PIMAGE_NT_HEADERS pNtHeader;<br />
DWORD NewEntryPoint = (DWORD)0x40123456;<br />
<br />
HANDLE hFile;
HANDLE hFileMapping;
<br />
hFile = CreateFile("Example.exe",FILE_ALL_ACCESS,FILE_SHARE_READ,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);<br />
<br />
hFileMapping = CreateFileMapping(hFile,0,PAGE_READWRITE,0,0,0);<br />
<br />
pDosHeader = (PIMAGE_DOS_HEADER)MapViewOfFile(hFileMapping,FILE_MAP_READ | FILE_MAP_WRITE,0,0,0);<br />
<br />
pNtHeader = (PIMAGE_NT_HEADERS)((DWORD)pDosHeader + (DWORD)pDosHeader->e_lfanew);<br />
<br />
char apa[1024];<br />
itoa((DWORD)pNtHeader->OptionalHeader.AddressOfEntryPoint,apa,1024);<br />
MessageBox(0,apa,"a",MB_OK);<br />
<br />
(DWORD)pNtHeader->OptionalHeader.AddressOfEntryPoint = (DWORD) NewEntryPoint;<br />
<br />
this:
<br />
pNtHeader = (PIMAGE_NT_HEADERS)((DWORD)pDosHeader + (DWORD)pDosHeader->e_lfanew);<br />
makes an error like this:
Unhandled exception at 0x00411b52 in pan.exe: 0xC0000005: Access violation reading location 0x0000003c.
how can I make this work right?
|
|
|
|
|
Hi Spirit,
First id like to declare that Ive never used the functions that you're using
in this code snippet but here's my two bobs worth.
1) It looks like MapViewOfFile is returning NULL (which it does in case of error). (so pDosHeader->e_lfanew evaluates to 0x3c... sounds feasible?)
2) Reading to doco it looks like the "dwDesiredAccess" flag isnt "addable"
(Ths do saye "This parameter can be one of the following values").
It also says that FILE_MAP_WRITE by iself gives RW access.
Try playing with the MapViewOfFile args and check the returned value for NULL maybe
Cheers
|
|
|
|
|
Maybe because in MapViewOfFile you left the last parameter at 0 (dwNumberOfBytesToMap) instead of setting it to size of file?
|
|
|
|
|
I’m trying to use a list box control in a windows app I’m writing. I put on the control on my dialog resource, I assign it a member variable: as a control, CListBox. But in my code, when I try to use the function AddString (i.e. dlg.m_variableName.AddString(“Some Letters”) ) I get a debug assertion failure. Maybe I’m missing a step here? Is there more initialization I have to do?
I don’t really need the selectability of a list box. I tried just making it an edit box with a scroll bar, but I can’t get each item on a new line.
Danny
|
|
|
|
|
|
Chris Losinger wrote:
where does the assert happen ?
The simple answer? Somewhere in the AddString method.
The more complicated answer? The debug pop up tells me the assertion failed at afxwin2.inl at line 669.
Danny
|
|
|
|
|
_AFXWIN_INLINE int CListBox::AddString(LPCTSTR lpszItem)
{ ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, LB_ADDSTRING, 0, (LPARAM)lpszItem); }
it's failing because the CListBox isn't a window (yet). i'm guessing you're calling AddString before the dialog has had a chance to create the list box and/or associate it with your member variable.
put a breakpoint on your AddString and one in your dialog's OnInitDialog. if the AddString breakpoint hits first, you need to move it to after the dialog has been initialized.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
|
Alternatively, the release version works, or rather, survives. It works with the exception of the text that I wanted to put in the list box is not there.
Danny
|
|
|
|
|
The debug version ASSERT s because the window hasn't been created yet. In the release version, the ASSERT doesn't fire, and the SendMessage call silently fails. In this case, the control eventually gets created, but the string you're looking for isn't there due to the earlier SendMessage failure.
Software Zen: delete this;
|
|
|
|
|
bugDanny wrote:
But in my code, when I try to use the function AddString
Make sure you are doing this in the dialog's OnInitDialog() method, after the default method has been called.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Im trying to read a large text file with a CStdioFile object (the file's around 2.3 Gb, OS Windows XP, File System NTFS).
After reading for a while an exception is thrown during a CStdioFile::ReadString call which says something like "Controler Invalid"
I simplified the code so that its doing nothing more than loopìng around the ReadString call, and the error persists.
Could there be an inherent limit on the size of a file readable using CStdioFile (I dont belive that 2.3 Gb is too big for NTFS ?!?)
Thanks,
Dave
|
|
|
|
|
You may be running into some unexpected 32bit dword limitations, not necessarily a file os problem, but a file pointer limitation.
|
|
|
|
|
That sounds something like whats happening, but does anybody know of any settable limmitations of this type that exist?
|
|
|
|
|
Are you using VC6? if so then the file pointer used is a 32 bit value, with a limit of 2GB. AFAIK if you are using VC7+ then the file pointer is a 64 bit value.
If you want to get around this limit in VC6 then do not use the MFC classes (which wrap the fopen, fread, etc CRT functions) and use the SDK functions CreateFile, ReadFile etc.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Yes thats it PJ!
I am using VC6.
(I guess its time to shell out for an upgrade!)
Thanks so much for the help
|
|
|
|
|
PJ Arends wrote:
do not use the MFC classes (which wrap the fopen, fread, etc CRT functions)
Seriously? I always though that MFC didn't wrap CRT functions, but rather the WIN API directly! The CRT file API's (I don't know about the others) are just a layer on top of the OS's API's, which are CreateFile, ReadFile, etc..
I don't know about the MFC shipped with VC6, but the newer MFC version 8, does wrap the window's API's...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
From VC 6.0 MFC Source (FILECORE.CPP Line 111)
Yes it wraps Win32 API, not standard C runtime calls...
BOOL CFile::Open(LPCTSTR lpszFileName, UINT nOpenFlags,<br />
CFileException* pException)<br />
{<br />
<br />
...<br />
<br />
HANDLE hFile = ::CreateFile(lpszFileName, dwAccess, dwShareMode, &sa,<br />
dwCreateFlag, FILE_ATTRIBUTE_NORMAL, NULL);<br />
if (hFile == INVALID_HANDLE_VALUE)<br />
{<br />
if (pException != NULL)<br />
{<br />
pException->m_lOsError = ::GetLastError();<br />
pException->m_cause =<br />
CFileException::OsErrorToException(pException->m_lOsError);<br />
<br />
<br />
pException->m_strFileName = lpszFileName;<br />
}<br />
return FALSE;<br />
}<br />
m_hFile = (HFILE)hFile;<br />
m_bCloseOnDelete = TRUE;
|
|
|
|
|
Just as I expected. It would be just silly for MS to use some portable API that is a layer on top of their own API, instead of their own API.
Thanks for the info!
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I guess I should read the MFC source instead of MSDN[^]
[quote]
A CStdioFile object represents a C run-time stream file as opened by the run-time function fopen.
[/quote]
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
So much for the accoutibility of MSDN...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Well, I DID look at the CFile code. Who knows, maybe the CStdioFile object does something different? Not likely, but this IS MFC ...
|
|
|
|
|
Generally what I think that this is referring to is that this object *IS* the C run time and behaves the same. In the open it does call CFile::Open:
0:000> u MFC42!CStdioFile::Open
MFC42!CStdioFile::Open:
73e2c96c 8bff mov edi,edi
73e2c96e 55 push ebp
73e2c96f 8bec mov ebp,esp
73e2c971 53 push ebx
73e2c972 8b5d0c mov ebx,[ebp+0xc]
73e2c975 56 push esi
73e2c976 57 push edi
73e2c977 ff7510 push dword ptr [ebp+0x10]
0:000> u
MFC42!CStdioFile::Open+0xe:
73e2c97a 8bc3 mov eax,ebx
73e2c97c 25ffbfffff and eax,0xffffbfff
73e2c981 50 push eax
73e2c982 ff7508 push dword ptr [ebp+0x8]
73e2c985 8bf9 mov edi,ecx
73e2c987 33f6 xor esi,esi
73e2c989 897710 mov [edi+0x10],esi
73e2c98c e8e043fbff call MFC42!CFile::Open (73de0d71)
And that calls CreateFile, however right afterwards they do create a standard handle:
73e2c9db 75d2 jnz MFC42!CStdioFile::Open+0x43 (73e2c9af)
73e2c9dd ebd7 jmp MFC42!CStdioFile::Open+0x4a (73e2c9b6)
73e2c9df c644050c74 mov byte ptr [ebp+eax+0xc],0x74
73e2c9e4 40 inc eax
73e2c9e5 51 push ecx
0:000>
MFC42!CStdioFile::Open+0x7a:
73e2c9e6 ff7704 push dword ptr [edi+0x4]
73e2c9e9 c644050c00 mov byte ptr [ebp+eax+0xc],0x0
73e2c9ee ff150467e773 call dword ptr [MFC42!_imp___open_osfhandle (73e76704)]
73e2c9f4 83f8ff cmp eax,0xffffffff
73e2c9f7 59 pop ecx
73e2c9f8 59 pop ecx
Look, most other functions are wrappers around C runtime, as an example, look here:
0:000> u MFC42!CStdioFile::WriteString
MFC42!CStdioFile::WriteString:
73e2cb01 8bff mov edi,edi
73e2cb03 56 push esi
73e2cb04 8bf1 mov esi,ecx
73e2cb06 ff7610 push dword ptr [esi+0x10] <-- FILE *
73e2cb09 ff74240c push dword ptr [esp+0xc]
73e2cb0d ff151867e773 call dword ptr [MFC42!_imp__fputs (73e76718)]
73e2cb13 83f8ff cmp eax,0xffffffff
In WriteString, fputs is called and it gets the FILE * from the "this" pointer at offset 16. So, CStdioFile calls some standard APIs, some C runtime APIs and it in itself essentially re-implements some of the functionality that would have been done had you really called fopen() in order to create a compatible FILE *.
Read calls fread:
MFC42!CStdioFile::Read:
73e2ca4b 837c240800 cmp dword ptr [esp+0x8],0x0
73e2ca50 56 push esi
73e2ca51 8bf1 mov esi,ecx
73e2ca53 7504 jnz MFC42!CStdioFile::Read+0xe (73e2ca59)
73e2ca55 33c0 xor eax,eax
73e2ca57 eb62 jmp MFC42!CStdioFile::Read+0x70 (73e2cabb)
73e2ca59 55 push ebp
73e2ca5a 57 push edi
0:000> u
MFC42!CStdioFile::Read+0x10:
73e2ca5b ff7610 push dword ptr [esi+0x10] <-- Again, FILE *
73e2ca5e ff742418 push dword ptr [esp+0x18]
73e2ca62 6a01 push 0x1
73e2ca64 ff74241c push dword ptr [esp+0x1c]
73e2ca68 ff151067e773 call dword ptr [MFC42!_imp__fread (73e76710)]
Notice:
CStdioFile::m_pStream
Remarks
The m_pStream data member is the pointer to an open file as returned by the C run-time function fopen. It is NULL if the file has never been opened or has been closed.
In the documentation. While "fopen" may not have been called, they basically implemented fopen themsevles on top of CFile::Open (that calls CreateFile). Some of their APIs then call standard C Runtime and this public data member (most likely the same one I showed in the dissassembly) is exported as a C runtime compatible pointer. So, whether they use the C Runtime internally or not is not the point, the object itself exports the appropriate data structures and behaves idential to the c runtime implementation.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|