- 19 Sep, 2010 1 commit
-
-
Alexandre Julliard authored
-
- 16 Sep, 2010 1 commit
-
-
Marcus Meissner authored
-
- 08 Sep, 2010 1 commit
-
-
Vincent Povirk authored
Apparently, it's valid for the last block in a file to be incomplete.
-
- 31 Aug, 2010 1 commit
-
-
Alexandre Julliard authored
-
- 26 Aug, 2010 2 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
-
- 28 Jul, 2010 1 commit
-
-
Huw Davies authored
-
- 23 Jul, 2010 1 commit
-
-
Michael Stefaniuc authored
-
- 22 Jul, 2010 2 commits
-
-
Huw Davies authored
-
Huw Davies authored
ole32/tests: Relax the reference counting tests a bit. We only care whether references are held or not.
-
- 21 Jul, 2010 5 commits
-
-
Nikolay Sivov authored
-
Nikolay Sivov authored
-
Nikolay Sivov authored
-
Nikolay Sivov authored
-
Alexandre Julliard authored
-
- 19 Jul, 2010 6 commits
-
-
Vincent Povirk authored
Some ILockBytes objects will not really write changes until their Flush method is called. Also, further optimizations to the storage implementation will involve caching writes, which will have to be flushed at times.
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
These fields are needed for the MS storage implementation to load files that were created by Wine with a block size of 4096.
-
- 28 May, 2010 1 commit
-
-
Vincent Povirk authored
In some storage files, the size of this stream is not a multiple of the big block size. This means that we may need to enlarge the stream even when we don't really have to allocate more space for it.
-
- 27 May, 2010 2 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
-
- 26 May, 2010 1 commit
-
-
Michael Stefaniuc authored
-
- 25 May, 2010 3 commits
-
-
Alexandre Julliard authored
Based on a patch by Rob Shearman.
-
Juan Lang authored
-
Juan Lang authored
-
- 21 May, 2010 2 commits
-
-
Andrew Nguyen authored
-
Andrew Nguyen authored
-
- 18 May, 2010 1 commit
-
-
Nikolay Sivov authored
-
- 13 May, 2010 1 commit
-
-
Vincent Povirk authored
CreateStubEntry can change the value of This->entries, in which case the assignment can go to the wrong place. So instead, assign to a temporary variable, and copy the data back after all CreateStubEntry calls are finished.
-
- 10 May, 2010 1 commit
-
-
Marcus Meissner authored
-
- 07 May, 2010 2 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
-
- 06 May, 2010 3 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
When creating a new transacted storage object (or reverting an existing one), rather than copy the original storage, we simply create a "stub directory entry" for the root. As stub entries are accessed, we fill in their data from the parent and create new stubs for any linked entries. The streams have copy on write semantics - reads are from the original entry until a change is made, then we make a copy in the scratch file. When committing transacted storages, we have to create a new tree with the new data so that the storage entry can be modified in one step, but unmodified sections of the tree can now be shared between the new tree and the old. An entry can be shared if it and all entries reachable from it are unmodified. In the trivial case where nothing has been modified, we don't have to make a new tree at all.
-
Nikolay Sivov authored
-
- 05 May, 2010 2 commits
-
-
Vincent Povirk authored
A big block chain is a linked list, and we pretty much need random access to them. This should theoretically make accessing a random point in the chain O(log2 n) instead of O(n) (with disk access scaling based on the size of the read/write, not its location). It theoretically takes O(n) memory based on the size, but it can do better if the chain isn't very fragmented (which I believe will generally be the case for long chains). It also involves fetching all the big block locations when we open the chain, but we already do that anyway (and it should be faster to read it all in one go than piecemeal).
-
Vincent Povirk authored
-