Pass NULL for the section handle and 0 for the offset, and the system will allocate memory for you - parameter #4, ppvBits, is a pointer to a dword that will point to the buffer.
Posted on 2005-06-14 13:45:27 by f0dder
Thanks, but I'm already aware of that. The problem is that BitBlt will write to the system-allocated memory, and then the entire buffer will have to be re-written to a separate VirtualAlloc buffer if I am to call WriteFile(Ex) later for more than one frame.

As I mentionned, I would really like to avoid copying large buffers as much as possible and still be able to save frames in batches.
Posted on 2005-06-15 12:49:00 by Big Red
Uhm, having maybe 4 DIBs (with 4 DCs, to hold each),  BitBlt to the current DIB, overlapped WriteFile. - no big buffers being copied too many times :). Been my idea since the start, but I guess I haven't conducted it well enough.
If with DDraw there's a way to speed the Blt up, it'll be neat, but yet I don't know if this is possible
Posted on 2005-06-15 14:03:41 by Ultrano
That would work, however, since the DIBs could only be saved to separate system-allocated memory locations (from CreateDIBSection), they wouldn't be in the same buffer, which would, in turn, still require 4 calls to WriteFileEx.

I guess there probably isn't an easy way around this. Thanks for the input, though.
Posted on 2005-06-16 09:35:53 by Big Red
Anyhow, if anybody cares, this project will be finalized soon and will be released within the next month. There will be a recording cheat for the game and a separate utility to compress the large raw dumps (separate for compatibility reasons). The current version of the mod is available at the address in my sig; the next will be uploaded as specified. You apply the mod to the demo version of Trespasser (download at

For the moment, I'll be using a standard non-overlapped call to WriteFile to store the frames. As it turns out, this is faster than passing a file mapping object to CreateDIBSection (so yes, I wasted a lot of time and argument on that). I was hoping to use overlapped calls, but I'm not sure I'll have enough thread access to manage that (or programming practice, for that matter).

Also, according to the Win32 API reference, Windows 95 does not support asynchronous operation on disk files. Does anyone know definitely if this applies to Win98 and WinME as well?

Just to finish off, thanks for your help and suggestions; it will be noted.

Posted on 2005-06-20 10:21:40 by Big Red
Nice ;)
My MSDN copies specify that overlapped writefile cannot be done only in Windows CE.
It is clearly specified in the docs that overlapped writing is supported in Win95 and Win95.
Posted on 2005-06-20 12:07:48 by Ultrano
My documentation specifies that overlapped writing can be done for some objects in Win95 such as pipes and communication, but not for disk files, which was what I was referring to. Would you know if overlapped operation for disk files is supported in Win9X/ME?
Posted on 2005-06-21 15:01:53 by Big Red




Windows 95/98/Me:? For operations on files, disks, pipes, or mailslots, this parameter must be NULL; a pointer to an OVERLAPPED structure causes the call to fail. However, you can perform overlapped I/O on serial and parallel ports.

So neither of you were right :P


It is clearly specified in the docs that overlapped writing is supported in Win95 and Win95.


Both the WriteFile and ReadFile say what i quoted above :|
Posted on 2005-06-21 15:41:23 by ti_mo_n
That is _basically_ what my documentation specified, but a lot less clearly. Thank you for clearing things up (thus I will not be implementing an overlapped writefile due to my operating system being WinME).
Posted on 2005-06-21 16:23:40 by Big Red
Sorry for the mislead, I had not read the docs well enough. Have been very tired, I guess - having written "in Win95 and Win95" is a proof :)
Posted on 2005-06-22 04:20:37 by Ultrano
This might be interesting...  ;)

Anyway .. you can use MS Media Player SDK or Apple QTime SDK for some rather cool stuff
Posted on 2005-06-22 04:46:49 by Azrim
That might have been useful, indeed.
Posted on 2005-06-22 08:57:34 by Big Red