adeyblue

These functions don't like BITMAP type resource data, only RCDATA type resource data.

 

Change the

IDB_BITMAP1 BITMAP "Image.bmp";

 

bit in the rc file to

IDB_BITMAP1 RCDATA "Image.bmp";
 

The second stores a copy of the file as is; the first one strips off the BITMAPFILEHEADER from the start of the file. The WIC functions the D3DX functions use (specifically CreateDecoderFromStream) seem to require that header be present or they fail. It ain't there, so they fail which make the D3DX function fail.

You could also (ab)use the fact that accumulate is implemented in terms of addition and use that to concat a bunch of strings in a container. The need to provide the starting point takes away some elegance points but it's still serviceable.

// include <numeric>
std::wcout << fieldTitle << L'\t' << std::accumulate(dest.begin(), dest.end(), std::wstring()) << std::endl;

If you add
dumpbin /exports $(TargetPath)
as a post-build event for the dll/exe project generating the lib & exp, the build output will tell you what functions are being exported.

I know VS 2008 has a bug where certain build options will cause the project to export std::_Init_locks which in turn will generate an exp & lib for otherwise non-exporting projects. I don't know if they fixed it though.

There's nothing wrong really. If you convert that number to hex you get:

0x80011000D008E
..8|17| 13| 142

it's just packed into word sized values with the larger value. You can get the individual parts using the high and low parts of the large_integer with the word extraction macros:

std::wostringstream outs;
outs << L"Your computer has " << num_adapters << L" display adapter(s). D3D driver version is " <<
	HIWORD(lrg_int.HighPart) << L'.' <<
	LOWORD(lrg_int.HighPart) << L'.' <<
	HIWORD(lrg_int.LowPart) << L'.' <<
	LOWORD(lrg_int.LowPart);

It would be nice if the CheckInterfaceSupport help page documented this, but maybe it's dependent on what the driver vendor provides so there's no set format for it.

std::get_temporary_buffer & std::return_temporary_buffer.
I am convined nobody has ever used these functions for anything, ever.

You can also set the _NO_DEBUG_HEAP environment variable to a non-zero value to stop it from occuring. You used to be able to set it from the Environment part of Project Properties->Configuration->Debugging but that was in VS2008, it may have changed in more recent versions.

You could install it in a virtual machine, extract the compiler / headers / libs and them blow the VM away or revert it to a previous snapshot. You could also mount the service pack ISO and extract the files from the cabs with 7zip or similar, though that's only worth the effort if you just want the executables.

Thanks chaps. Good to know I haven't done anything obviously wrong. I'm struggling to find an updated dbghelp.dll, though. I've installed VS2010 SP1 and the latest debugging tools, but I still have a dll dated from 2008. I'm on an old 32bit Windows XP, so perhaps that's all I should hope for.

If you've installed the Debugging Tools, the updated dbghelp is in the same directory as WinDbg and them. You have to put it next to your app, it doesn't update the system32 one. You also need to link to dbghelp instead of imagehlp. Imagehlp is a known dll so it and its dependencies are loaded from system32 regardless.

The problem with the 'no-name incremental link' is that old versions of the DIA code (used in 2000/XP versions of dbghelp.dll) treated the incremental link table (the ILT in SiCrane's result) stubs as unnamed Thunk symbols. The non incremental version just has function symbols, which obviously do have names. The newer versions interpret the ILT as Public Symbols, which do have a name.

It's anybody's guess as to whether the old versions had a pdb parsing bug in regards to the ILT symbols, or whether modern PDB's have an incompatible format with that version of the parsing code.

The MSDN text is slightly misleading. It's not a number of indexes between 64 and 1,088. It's either 64 or 1,088 indexes for all post Win2k editions of Windows. You get 64 guaranteed as that space is included with the TEB. When you request the 65th index, Windows allocates 1,024 more spaces for the requesting thread only. The additional 1,024 spaces are allocated for other threads when they either call TlsAlloc or TlsSetValue with an index of 64 or greater.

Sp depending on your programs' usage of the process heap, you'll either be able to afford the 4/8K for 1,088 slots for all threads, only some of your threads, or for none of them.

Did you CoInitialize() or CoInitializeEx(COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE, NULL) before running this code? You'll also need CoUninitialize() after you've finished with the COM stuff.

This code also leaks either the IFileOpenDialog or both it and the IShellItem on those returns (just incase you haven't ellided the cleanup).

I've been doing this too and as I had some almost def-creating tool code already written, I glued it to dlltool and link to automate the two manual methods outlined above. It's here if anybody wishes to use it. You give deflibcreator.exe <name>.dll and an optional output dir, and should get <name>.def, lib<name>.a, <name>.lib & <name>-x64.lib. The source is in there too in case somebody desperately needs Itanium libs or support for another compiler suite.

Unless they radically change what they ship in the release version of Express vs the RC that's currently downloadable, enabling the IDE to build non-metro native projects is very simple..

StringCchLength(src, maxSrcLength, &length);
*dstPtr = (TCHAR *)malloc(length);

You ask for the length in characters, you alloc the length in bytes. With TCHAR you have a 50% chance these are not the same. If they are not, you only allocate half of what you need. The code needs to add 1 to length as it doesn't account for a null terminator, and multiply the result by sizeof(TCHAR), or it needs to use the sane C++ default of std::(w)string as Endurion suggested.

Phantom's nailed your immediate problem, but there are a few other things with the code

// Attempt to open the actual file.
FileHandle = CreateFile( FileName, dwDesiredAccess, dwShareMode, NULL, dwCreationDisposition,
FILE_FLAG_RANDOM_ACCESS|FILE_FLAG_OVERLAPPED, 0 );
if( !FileHandle )
{
return GetLastError();
}

CreateFile doesn't return NULL on failure.

DataPtr = new BYTE[FileSize];
if( !DataPtr )
{
return E_OUTOFMEMORY;
}

You may have overloaded new so this doesn't apply, but new doesn't return NULL on failure, it throws std::bad_alloc

// The thread is still searching? Return with a pending error message.
if( dwResult == WAIT_TIMEOUT )
{
return E_PENDING;
}
...
// If the thread failed somehow, return the detailed error code...
else
{
return GetLastError();
}

You're mixing error code genuses (Win errors and COM HRESULT errors). Mixing these only works if you explicitly text against 0 as success/failure conditions, you're using FAILED() which checks for negative values. This will catch E_PENDING and suchlike (since those are negative), but will not catch any error returned from GetLastError() (which aren't). You can transform Windows errors to COM errors with HRESULT_FROM_WIN32(). If you do this, change the return type of your functions to HRESULT for clarity.

DWORD async_io::CAsyncIO<ptrType>::LocateFile( CHAR *szFileName, bool bFullPathIncluded )

Since you're already tied to Windows, consider using something like PathIsRelative or checking whether the second character of szFileName is a colon instead of asking the user to tell you whether it is a full path or not. I'd also explicitly document the lifetime requirements of the szFileName parameter. As it's passed to a different thread, if you do something like this:

std::ostringstream fileNameStream;
fileNameStream << someNonRootSelectedFolder << "myFile.cpp";
FileIO->LocateFile(fileNameStream.str().c_str(), false);

The thread could potentially end up working on deleted data.

SearchThreadHandle = (HANDLE) _beginthreadex( NULL, 0, this->FileSearchThread, szFileName, CREATE_SUSPENDED, NULL );
if( !SearchThreadHandle )
return GetLastError();
// Create the event used to signal the end of this thread's existence.
SearchEventHandle = CreateEvent( NULL, FALSE, FALSE, NULL );
if( !SearchEventHandle )
{
CloseHandle( SearchThreadHandle );
return GetLastError();
}

CancelIoEx ties you to Vista+ so it's worth cleaning up the allocated thread stack and removing the thread from your process with TerminateThread() before closing the handle.

// Test the status of this thread
DWORD dwResult = WaitForSingleObject( SearchThreadHandle, WAIT_OBJECT_0 );

This is semantic but WAIT_OBJECT_0 is generally used as to check against the return value to see if the handle is signalled. It works as intended here since it has a value of 0, but it's not terribly usual.

Cancel();
...
SAFE_DELETE_ARRAY(DataPtr);

After cancelling the IO, you have to wait for the IO operation to complete before you start deallocating all the buffers used in the operation.

On 64-bit computers, Process Explorer is a 64-bit program so it exists outside the 'emulator' and can see into it.

To get the full user-mode call stack of a WoW64 thread, call GetThreadContext and StackWalk64(IMAGE_FILE_MACHINE_X64, ...) (for the 64-bit code), then call Wow64GetContextThread and StackWalk64(IMAGE_FILE_MACHINE_I386, ...) (for the 32-bit code)

To get the kernel side stacks that Process Explorer also displays requires a driver and peeking into documented-but-not-officially-so structures.