Re: ntdll: try to not raise exceptions when checking for atl thunks
Am 16.06.2010 11:37, schrieb Alexandre Julliard: Markus Amslermarkus.ams...@oribi.org writes: + * Windows checks the following conditions before emulating an ATL thunk: + * - DEP policy allows emulating + * - thunk has memory type MEM_PRIVATE and is readable + * - jmp func is executable + * - thunk signature (movl, jmp) matches + * - a secret flag is set: + *The flag gets set before calling WndProc and cleared after WndProc + *or a thunk was emulated. + *In Windows XP SP 3 this flag is located at TEB+0xfb4. */ Where does that information come from? From my attemp to write a test for atl thunks. I had a hard time to get windows to emulate an atl thunk, so I worked my way backward from a working atl thunk example. I knew there had to be some secret flag, because in the WndProc atl thunks worked, outside not. So I took a hard look at the TEB and found it. It was clean reverse engineered. I put it into to patch, to document it somewhere. Markus
regression: loader: Reserve some more memory to cover the native ole32 addresses.
commit 8d833ee2e7a1d8b82e2dccf51e0cbc20742a0833 Author: Alexandre Julliard julli...@winehq.org Date: Thu Jun 25 14:19:09 2009 +0200 loader: Reserve some more memory to cover the native ole32 addresses. After this commit WoW with mesa/r500 falls back to indirect rendering. libGL tries to mmap 256M for the framebuffer but that fails with libGL error: drmMap of framebuffer failed (Cannot allocate memory) Markus
Re: winedos interrupts getting lost.
Peter Dons Tychsen wrote: Hello. It starting with me trying to figure out why i was loosing keyboard events in winedos. 1) I then traced the keyboard events to a call to signal(SIGUSR2) in function DOSVM_QueueEvent(). 2) The signal() triggers code in ntdll, which generates an exception EXCEPTION_VM86_STI for the current vm86 context. 3) The exception is supposed to trigger exception_handler(), which will then handle the keyboard event, by kicking the event queue. This never happens however, as the mechanism stops working very quickly. I found out the code gets to raise_vm86_sti_exception in ntdll, and then stops. ntdll_get_thread_data()-vm86_ptr is NULL, so the STI exception is never signaled. Does anyone know more about the exception subsystem, and what could be causing this kind of strange behavior? I can mention that the system can generate EXCEPTION_VM86_INTx exceptions successfully, but fails to execute the EXCEPTION_VM86_STI. Thanks, /pedro One issue with dos input is (was?), that since 2.6 linux kernel we should signal the thread not the process. Have a look at [1]. That patch once fixed all my dos input issues, although I haven't looked at this stuff for quite some time. I'm not sure you have the same problem, just a possible hint. Markus [1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html
Re: Alexandre Julliard : wordpad.exe: We can now store binary files in the repository.
So we can also add ttf fonts and get rid of the fontforge dependency? Markus
Re: iTunes 7
Juan Lang wrote:
Folks, I just sent a series of wintrust patches that gets iTunes 7 to
start, at least for me. I expect some will get rejected due to
collision with Francois's patch - I'll resynch and resend. But if you
want to play around with iTunes, grab those patches and give them a
whirl.
Known issues:
1. Your screen will go black when it starts. This is something
QuickTime is doing. You can drag windows around to force some
repainting to work around it
Just a wild guess, does the attached patch fix the problem? Battlefield
1942 shows the same behavior in windowed mode.
diff --git a/dlls/wined3d/surface_gdi.c b/dlls/wined3d/surface_gdi.c
index 2920593..5c829a2 100644
--- a/dlls/wined3d/surface_gdi.c
+++ b/dlls/wined3d/surface_gdi.c
@@ -1505,8 +1505,6 @@ HRESULT WINAPI
IWineGDISurfaceImpl_PrivateSetup(IWineD3DSurface *iface)
{
IWineD3DSurfaceImpl *This = (IWineD3DSurfaceImpl *) iface;
-HRESULT hr;
-HDC hdc;
long oldsize = This-resource.size;
if(This-resource.usage WINED3DUSAGE_OVERLAY)
@@ -1530,24 +1528,6 @@ IWineGDISurfaceImpl_PrivateSetup(IWineD3DSurface *iface)
/* Adjust the opengl mem counter */
globalChangeGlRam(This-resource.size - oldsize);
-/* Call GetDC to create a DIB section. We will use that
- * DIB section for rendering
- *
- * Release the DC afterwards to allow the app to use it
- */
-hr = IWineD3DSurface_GetDC(iface, hdc);
-if(FAILED(hr))
-{
-ERR((%p) IWineD3DSurface::GetDC failed with hr %08x\n, This, hr);
-return hr;
-}
-hr = IWineD3DSurface_ReleaseDC(iface, hdc);
-if(FAILED(hr))
-{
-ERR((%p) IWineD3DSurface::ReleaseDC failed with hr %08x\n, This, hr);
-return hr;
-}
-
return WINED3D_OK;
}
Re: Call for win16 tests
Dan Kegel wrote: As Andreas Mohr pointed out a while back, http://www.winehq.org/pipermail/wine-devel/2005-August/039602.html we really need a win16 test suite to make sure our win16 support doesn't rot. As far as I know, nobody's managed to get win16 tests into the tree, presumably because the build process or maybe stdio for win16 tests hasn't been figured out. So I've asked intern Jennifer Lai to try to merge all the win16 tests people have posted over the years together, and demonstrate how to build them using openwatcom. I've only found three submitted 16 bit tests so far: http://www.winehq.org/pipermail/wine-devel/2006-November/052479.html http://www.winehq.org/pipermail/wine-patches/2004-October/013267.html http://www.winehq.org/pipermail/wine-patches/2004-October/013268.html We have to distinguish between win16 and dos tests. dos functions are called with interrupts, win16 with linked functions (please correct me if I'm wrong). IMO it should be possible to run them with make test like any other test. And if openwatcom/turbo c is available it should be possilbe to run make crosstest to build win16/dos binaries. For dos I had a test (I think I really have lost it) which compiled on linux with gcc and in dos6.2 with turbo C. In linux/wine it emulated an interrupt with DOSVM_EmulateInterruptPM, and in dos it used real interrupts. I'm not sure whether this approach would be acceptable, but I was able to run make test and build dos binaries from the same sources. For win16 I have no idea what thunking/linking voodoo is required. Its perhaps also noteworthy that wines win16 implementation differs fundamentally from the windows one. Wine calls win32 functions, while windows calls dos functions (directly or via vdm). Markus
Re: Call for win16 tests
Dan Kegel wrote: On 7/9/07, Markus Amsler [EMAIL PROTECTED] wrote: We have to distinguish between win16 and dos tests. Absolutely. dos .com executables currently don't work, but win16 .exe's with the same contents do work. I plan to test DOS .com files using very simple pure assembly. (That was the real way to write DOS programs anyway :-) IMO it should be possible to run them with make test like any other test. And if openwatcom/turbo c is available it should be possilbe to run make crosstest to build win16/dos binaries. For dos I had a test (I think I really have lost it) which compiled on linux with gcc and in dos6.2 with turbo C. In linux/wine it emulated an interrupt with DOSVM_EmulateInterruptPM, and in dos it used real interrupts. I'm not sure whether this approach would be acceptable, but I was able to run make test and build dos binaries from the same sources. Sounds like too much magic for me. I would rather simply require openwatcom; it's free software. License fun. It's OSI approved, but it looks it isn't good enough even for debian non-free (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431). For win16 I have no idea what thunking/linking voodoo is required. No voodoo required; openwatcom Just Works. You're right it's a lot simpler. Perhaps we should check for win16 compiler in configure, so if openwatcom is present make test builds/runs also the win16/dos tests. Its perhaps also noteworthy that wines win16 implementation differs fundamentally from the windows one. Wine calls win32 functions, while windows calls dos functions (directly or via vdm). Shouldn't affect our tests, though, should it? I don't think so.
Re: vxd loading is broken last months
Evan Stade wrote: On that note, I have been unable to get Wine to run dos .com programs (including via cmd.exe). It gets stuck in an infinite loop in DOSVM. Is there some trick to getting .com programs running? There's a regression, freecom [1] used to work, now it doesn't. Perhaps it has to do with the signaling stuff [2]. If I find some time/motivation I'll have a look at it. Markus [1] http://freedos.sourceforge.net/freecom/packages/082pl3/ [2] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html
Re: dbghelp performance
Eric Pouech wrote:
Markus Amsler a écrit :
Eric Pouech wrote:
Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was
breaking at an unknown symbol (break gaga) while WoW was loaded in
the debugger (wine winedbg WoW.exe). The time was hand stopped,
memory usage measured with ps -AF and looked at the RSS column.
Test Time(s)Memory Usage(MB)
current git 4.554
pool_heap.patch 4.563
process_heap.patch 4.5126
insert_first.patch 4.554
current git, r300115146
pool_heap.patch, r30017 119
process_heap.patch, r300 17 260
insert_first.patch, r300 27 167
insert_first is the patch from Eric Pouech.
r300 means with the debug version of Mesas r300_dri.so, which has a
total compilation unit size of around 9.2M (compared to the second
biggest Wines user32 with 1.1M).
Hi Markus,
does the slightly modified version of pool_heap improve your
performances (it shouldn't modify the perf for large files(or just a
bit), but should reduce memory consumption for small pools (from 1 to
2M depending on your configuration)
A+
No, performance is exactly the same as pool_heap :( .
I analyzed why your original insert_first version was slower and memory
hungrier then pool_heap. It turned out pool_realloc is the problem, not
pool_alloc. First there's a memory leak, if the memory is moved the old
one is not freed. Second pool_realloc is O(n) that's the reason for the
speed hits. Directly using heap functions for reallocs solves both
problems (but looks to hackish to get commited, perhaps you have a
better idea).
Here the results for pool_realloc on top of insert_first
pool_realloc4.5s54M
pool_realloc,r30017s104M
The next problem is vector_iter_[up|down], because vector_position is
O(n). Explicitly storing the current iter position speeds r300 up to 8s
(from original 115s)! But I'm not sure how to implement it cleanly.
Directly use for() instead of vector_iter_*(), use an iterator, ...
Markus
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index e196143..c3ccaf5 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -73,30 +73,28 @@ void pool_destroy(struct pool* pool)
void* pool_alloc(struct pool* pool, unsigned len)
{
-struct pool_arena** parena;
struct pool_arena* arena;
void* ret;
len = (len + 3) ~3; /* round up size on DWORD boundary */
assert(sizeof(struct pool_arena) + len = pool-arena_size len);
-for (parena = pool-first; *parena; parena = (*parena)-next)
+for (arena = pool-first; arena; arena = arena-next)
{
-if ((char*)(*parena) + pool-arena_size - (*parena)-current = len)
+if ((char*)arena + pool-arena_size - arena-current = len)
{
-ret = (*parena)-current;
-(*parena)-current += len;
+ret = arena-current;
+arena-current += len;
return ret;
}
}
-
+
arena = HeapAlloc(GetProcessHeap(), 0, pool-arena_size);
if (!arena) {FIXME(OOM\n);return NULL;}
-*parena = arena;
-
ret = (char*)arena + sizeof(*arena);
-arena-next = NULL;
+arena-next = pool-first;
+pool-first = arena;
arena-current = (char*)ret + len;
return ret;
}
diff --git a/dlls/dbghelp/dbghelp_private.h b/dlls/dbghelp/dbghelp_private.h
index a84d91c..61b4e48 100644
--- a/dlls/dbghelp/dbghelp_private.h
+++ b/dlls/dbghelp/dbghelp_private.h
@@ -39,6 +39,8 @@ struct pool /* poor's man */
{
struct pool_arena* first;
unsignedarena_size;
+void** reallocs;
+unsignedrealloc_size;
};
void pool_init(struct pool* a, unsigned arena_size);
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index c3ccaf5..a9f6f44 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -42,12 +42,15 @@ void pool_init(struct pool* a, unsigned arena_size)
{
a-arena_size = arena_size;
a-first = NULL;
+a-reallocs = NULL;
+a-realloc_size = 0;
}
void pool_destroy(struct pool* pool)
{
struct pool_arena* arena;
struct pool_arena* next;
+unsignedi;
#ifdef USE_STATS
unsignedalloc, used, num;
@@ -68,6 +71,11 @@ void pool_destroy(struct pool* pool)
next = arena-next;
HeapFree(GetProcessHeap(), 0, arena);
}
+for (i=0; ipool-realloc_size; i++)
+{
+HeapFree(GetProcessHeap(), 0, pool-reallocs[i]);
+}
+if (pool-reallocs) HeapFree(GetProcessHeap(), 0, pool-reallocs);
pool_init(pool, 0);
}
@@ -99,31 +107,39 @@ void* pool_alloc(struct pool* pool, unsigned len)
return ret;
}
-static struct pool_arena* pool_is_last(const struct pool* pool, const void* p, unsigned old_size)
+static void* pool_realloc(struct pool* pool, void* p, unsigned new_size)
{
-struct
Re: dbghelp performance
Eric Pouech wrote: Markus Amsler a écrit : I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column. Test Time(s)Memory Usage(MB) current git 4.554 pool_heap.patch 4.563 process_heap.patch 4.5126 insert_first.patch 4.554 current git, r300115146 pool_heap.patch, r30017 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167 insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M). Conclusions: - current git wins with small debug files (2M or so), pool_heap wins with bigger files. insert_first, process_heap are out. - small pools have less memory overhead than small heaps - big pools have more memory overhead than big heaps. - big pools are a lot slower than big heaps. thanks for the testings timings ! you're also missing a couple of elements: - for the memory overhead, in the first case you consider 50 MB (roughly) over 10 or 20 modules while in your r300 case the impact (and memory difference) is only on a single module I'm not sure what's your point is. - time to unload a module hasn't been computed (it's less used than loading a module) Unloading is more or less instant in all cases. what's also strange is that the pool_heap gets lower memory consumption than the process heap one, which is rather not a natural result... I wonder if some data haven't been swapped out and aren't accounted for in RSS The process_heap is the one I sent to wine-patches, which never frees any memory. I've also tested an improved process_heap, which stores the allocated memory pointer in an array and frees it afterwards. Without luck, it's slower and uses more memory the pool_heap. So I don't see a simple solution which only affects storage.c, is equal or better than the current, and is significantly faster at big debug files. Any ideas? Markus
dbghelp performance
I've played around with dbghelp performance. My test case was breaking
at an unknown symbol (break gaga) while WoW was loaded in the debugger
(wine winedbg WoW.exe). The time was hand stopped, memory usage measured
with ps -AF and looked at the RSS column.
Test Time(s)Memory Usage(MB)
current git 4.554
pool_heap.patch 4.563
process_heap.patch 4.5126
insert_first.patch 4.554
current git, r300115146
pool_heap.patch, r30017 119
process_heap.patch, r300 17 260
insert_first.patch, r300 27 167
insert_first is the patch from Eric Pouech.
r300 means with the debug version of Mesas r300_dri.so, which has a
total compilation unit size of around 9.2M (compared to the second
biggest Wines user32 with 1.1M).
Conclusions:
- current git wins with small debug files (2M or so), pool_heap wins
with bigger files. insert_first, process_heap are out.
- small pools have less memory overhead than small heaps
- big pools have more memory overhead than big heaps.
- big pools are a lot slower than big heaps.
IMO the best results would give removing the pools (like in
process_heap) and freeing unused memory manually, the other way round it
was allocated. But at a first glance it looks like quite a bit of work,
which I'm not sure is worth the result. I think the best approach would
be to code some destroy functions in storage.c which would free the
allocated vector, sparse_array and hash_table memory. And then gradually
replace pool_alloc calls with HeapAlloc/HeapFree pairs.
Markus
diff --git a/dlls/dbghelp/dbghelp_private.h b/dlls/dbghelp/dbghelp_private.h
index a84d91c..8fd3360 100644
--- a/dlls/dbghelp/dbghelp_private.h
+++ b/dlls/dbghelp/dbghelp_private.h
@@ -37,8 +37,7 @@
struct pool /* poor's man */
{
-struct pool_arena* first;
-unsignedarena_size;
+HANDLE heap;
};
void pool_init(struct pool* a, unsigned arena_size);
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index e196143..3b1e909 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -32,100 +32,24 @@
WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
-struct pool_arena
-{
-struct pool_arena* next;
-char* current;
-};
-
void pool_init(struct pool* a, unsigned arena_size)
{
-a-arena_size = arena_size;
-a-first = NULL;
+a-heap = HeapCreate(0, arena_size, 0);
}
void pool_destroy(struct pool* pool)
{
-struct pool_arena* arena;
-struct pool_arena* next;
-
-#ifdef USE_STATS
-unsignedalloc, used, num;
-
-for (alloc = used = num = 0, arena = pool-first; arena; arena = arena-next)
-{
-alloc += pool-arena_size;
-used += arena-current - (char*)arena;
-num++;
-}
-FIXME(STATS: pool %p has allocated %u kbytes, used %u kbytes in %u arenas,\n
- \t\t\t\tnon-allocation ratio: %.2f%%\n,
- pool, alloc 10, used 10, num, 100.0 - (float)used / (float)alloc * 100.0);
-#endif
-
-for (arena = pool-first; arena; arena = next)
-{
-next = arena-next;
-HeapFree(GetProcessHeap(), 0, arena);
-}
-pool_init(pool, 0);
+HeapDestroy(pool-heap);
}
void* pool_alloc(struct pool* pool, unsigned len)
{
-struct pool_arena** parena;
-struct pool_arena* arena;
-void* ret;
-
-len = (len + 3) ~3; /* round up size on DWORD boundary */
-assert(sizeof(struct pool_arena) + len = pool-arena_size len);
-
-for (parena = pool-first; *parena; parena = (*parena)-next)
-{
-if ((char*)(*parena) + pool-arena_size - (*parena)-current = len)
-{
-ret = (*parena)-current;
-(*parena)-current += len;
-return ret;
-}
-}
-
-arena = HeapAlloc(GetProcessHeap(), 0, pool-arena_size);
-if (!arena) {FIXME(OOM\n);return NULL;}
-
-*parena = arena;
-
-ret = (char*)arena + sizeof(*arena);
-arena-next = NULL;
-arena-current = (char*)ret + len;
-return ret;
-}
-
-static struct pool_arena* pool_is_last(const struct pool* pool, const void* p, unsigned old_size)
-{
-struct pool_arena* arena;
-
-for (arena = pool-first; arena; arena = arena-next)
-{
-if (arena-current == (const char*)p + old_size) return arena;
-}
-return NULL;
+return HeapAlloc(pool-heap, 0, len);
}
-static void* pool_realloc(struct pool* pool, void* p, unsigned old_size, unsigned new_size)
+static void* pool_realloc(struct pool* pool, void* p, unsigned len)
{
-struct pool_arena* arena;
-void* new;
-
-if ((arena = pool_is_last(pool, p, old_size))
-(char*)p + new_size = (char*)arena + pool-arena_size)
-{
-arena-current = (char*)p + new_size;
-return p;
-}
-if ((new = pool_alloc(pool, new_size)) old_size)
-memcpy(new, p, min(old_size, new_size));
-return new;
+return
Re: dbghelp: Directly use Heap functions.
Eric Pouech wrote:
Markus Amsler a écrit :
Dmitry Timoshkov wrote:
The old code at least bothered to actually free some memory.
Good point. I wasn't aware that some memory is only temporarily
used. I'm going to rework it.
Markus
does this patch gives you lots of improvements ?
A+
diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c
index e196143..c3ccaf5 100644
--- a/dlls/dbghelp/storage.c
+++ b/dlls/dbghelp/storage.c
@@ -73,30 +73,28 @@ void pool_destroy(struct pool* pool)
void* pool_alloc(struct pool* pool, unsigned len)
{
-struct pool_arena** parena;
struct pool_arena* arena;
void* ret;
len = (len + 3) ~3; /* round up size on DWORD boundary */
assert(sizeof(struct pool_arena) + len = pool-arena_size len);
-for (parena = pool-first; *parena; parena = (*parena)-next)
+for (arena = pool-first; arena; arena = arena-next)
{
-if ((char*)(*parena) + pool-arena_size - (*parena)-current = len)
+if ((char*)arena + pool-arena_size - arena-current = len)
{
-ret = (*parena)-current;
-(*parena)-current += len;
+ret = arena-current;
+arena-current += len;
return ret;
}
}
-
+
arena = HeapAlloc(GetProcessHeap(), 0, pool-arena_size);
if (!arena) {FIXME(OOM\n);return NULL;}
-*parena = arena;
-
ret = (char*)arena + sizeof(*arena);
-arena-next = NULL;
+arena-next = pool-first;
+pool-first = arena;
arena-current = (char*)ret + len;
return ret;
}
I cant try it at the moment, but I tried also the same approach. It went
down from 100s to around 27s compared to 18s with Heap functions. The
other problem here is, not all allocated memory is used, the gaps in not
first nodes never gets filled.
Also IMO memory allocation logic should only coded once.
I will try it with the HeapCreate/HeapDestroy for every
pool_init/pool_destroy as mentioned by Frank. Let's see what the
overhead of HeapCreate is.
Markus
Re: dbghelp: Directly use Heap functions.
Dmitry Timoshkov wrote: The old code at least bothered to actually free some memory. Good point. I wasn't aware that some memory is only temporarily used. I'm going to rework it. Markus
Re: Greenville Revisited, A new look at FontForge
Wierd_w wrote: I am currently shooting to have a full Latin-1, Latin-A, and Latin-B + Greek + Cyrillic glyphset IMO for a first version Latin-1 would be enough, so steam would be useable out of the box. But of course the more glyphs the better. Feedback would be greatly appreciated. Presenting the work often generates more feedback. Could you send your current working version as TTF to wine-devel, so we can play around with it? If it's too big (I'm not sure what's the currently accepted max attachement size, but 200-300k should be fine), upload it to the corresponding bug [1]. If you don't wanna create a bugzilla acount mail it to me, so I can uplaod it. Markus [1] http://bugs.winehq.org/show_bug.cgi?id=4449
Re: GreenVille font, is it still available? I have a question about it.
Louis. Lenders wrote: Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis I neither fully understood it, but here my opinion. It looks like the only problem he has is the TrueType hinting, which affects small font sizes. As long as the kerning (=width of a glyph) is correct, and the font looks somehow similar, it should be suitable for wine's need. So it should be possible to convert Larry's TTF version with fontforge to SDF, and you're done. Adding hinting is IMO a second step.
Re: ntdll/signal_i386.c: __wine_enter_vm86 issue
Christoph Bumiller wrote: I tried to run some DOS games with wine recently and since most of them crashed I would call this a success, since not ALL of them crashed :-). Winedos is far from a complete DOS emulation. In my example (Realms of Arkania: Blade of Destiny) this lets the app continue and I get the initial text box to select difficulty level. But ... the process doesn't handle any input - events are queued but never handled p.e. by DOSVM_Wait or similar ... I can't comment the vm86 stuff, but no input is because the unix process gets the signal and not the unix thread. Try this patch: http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html It's a while back, so you probably have to manually apply it.
Re: ntdll/signal_i386.c: __wine_enter_vm86 issue
Christoph Bumiller wrote: Yep .. it (the patch) works, at least for Blade of Destiny which is now actually playable (!) (without sound yet, though). Why hasn't it been merged? I'm not sure, I didn't ask. Perhaps I did something wrong with the server code, or there's a better way to achieve the same result. Anyway feel free to send an updated patch.
Re: d3d [2]: Optional callback infrastructure for implicit texture surface destruction.
H. Verbeet wrote: I think the callback should be non-optional. I think you're right. I wanted to avoid code duplication for default callbacks in ddraw, d3d8, d3d9, wined3d. But the non-optional way would avoid duplication in wined3d, and it's more elegant = non-optional wins with 1:2. I will rework them.
Re: d3d [2]: Optional callback infrastructure for implicit texture surface destruction.
Stefan Dösinger wrote: Am Sonntag 03 Dezember 2006 21:52 schrieb Markus Amsler: /* IWineD3DTexture */ +IWineD3DTextureImpl_Destroy, Wouldn't it maybe be better to make the destroy method part of IWineD3DBase? They need different callback types as arguments, so I think it's not possible.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
Alexandre Julliard wrote: H. Verbeet [EMAIL PROTECTED] writes: As for the previous patches, I was under the impression at the time that the idea was to get rid of COM in wined3d, otherwise I would have said something earlier. For consistency it would probably be best if they were reverted. That was my impression too, what happened to the idea of getting rid of COM? Because of course if we are keeping COM then we need to follow the rules properly. I wasn't fully aware of the importance of the COM refcount rules, just saw the opportunity for simplification. For removing COM it would be probably better to start with removing the lpVtbl's. I agree it's probably best to revert them for consistency. Should I send patches? Sorry for the inconveniences.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
Stefan Dösinger wrote: I proposed getting rid of COM some time ago, but I didn't consider that we need some features like inheritance. I think we should keep COM, but get rid of the D3D-Specific Addrefs because they are different between the various versions d3d versions. So keep the AddRef in IUnknown methods(QueryInterface namely), and GetParent, but do not AddRef in d3d methods(SetTexture / GetTexture, ...) Opinions? From my point of view (solving d3dx implicit surface refcounts) the GetParent AddRef is ugly. It spreads d3dx refcounting across d3dx and wined3d. It would be easier to only do d3dx refcounting in d3dx. But that's only my pragmatic view, without further COM knowledge.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
H. Verbeet wrote: On 28/11/06, Markus Amsler [EMAIL PROTECTED] wrote: The following patches remove refcounting in wined3d Getters. The Setters/Creaters refcounting can't be removed right now, because of the way implicit surfaces are currently handled. The idea is to simplify the d3dx-wined3d refcount relation. Ideally every wined3d object gets created with refcount=1, never AddRef'ed and destroyed with the first Release call. Rob mentioned this violates COM rules, but wined3d is wine internal. The GetParent patch doesn't remove wined3d refcounting, it seperates d3dx and wined3d refcounting (Which was the reason I started to remove AddRefs). --- I think this is a bad idea, if only for consistency with other COM objects. I don't think wined3d being wine internal is a very good reason to violate COM rules. IMO if we're going to use COM we should stick to its rules. Also see my other mail. One problem is, half of the AddRef patches were commited. Before reverting them, I thought I send the rest again. The other problem is the AddRef in GetParent is ugly, because it AddRefs on a d3dx object. We should do d3dx refcounting only in d3dx. At least this one has to go, or the implicit surface refcount code gets ugly. That was why i removed all of them, to be consistent with GetParent. And to be consistent with other COM objects (like ddraw, d3d8, d3d9), we would have to add some more ugly hacks :-) (like not destroying on count 0, forward refcount of one object to another, ...)
Re: sfd2ttf
[EMAIL PROTECTED] wrote: Hi, From the buglist I gather that the fontforge dependency is still an issue. I've taken a look at the sources and I think a can strip it down to about 5 to 10 pages of code without a major rewrite. If this is acceptable, I'd be happy to spend my time. Are you sure? The problem is TTF generation. There's no library and it's not trivial. With 5 to 10 pages its impossible to generate a valid, non-empty TTF file. I tried it once with dropping all unnecesary features (Apple Advanced Typography, Codpages, ...) and managed to get it down to 500 KB. Without Code obfuscation or comment dropping my guessed minimum was around 350 KB which would be around 150-200 pages of code. And we agreed that's too much, so I stopped my efforts. You can download my latest version from [1]. There was also a sfd2ttf thread some time ago. So sfd2ttf is not feasible, and AJ wonn't commit TTF files so I think we could resolve this bug as WONTFIX. Markus [1] http://oribi.org/download/sfd2ttf.tar.gz
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
H. Verbeet wrote: On 22/11/06, Robert Shearman [EMAIL PROTECTED] wrote: These patches violate COM rules. Is this for performance or other reasons? The plan seems to be to not use COM for wined3d anymore, mainly because the layering of d3d87/8/9 on top of wined3d is causing some problems with reference counts. Those could probably be solved by using eg aggregation, but I think the general feeling is that COM only makes things harder in wined3d. It's about simplifying code, with the side effect of perhaps small performance gains. It's also the first step to drop COM in wined3d, but that's not my intention (it seems Stefan likes the idea). Wined3d refcounting is not causing refcount problems in d3dx, they are completly different. It just makes things easier.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
H. Verbeet wrote: On 22/11/06, Markus Amsler [EMAIL PROTECTED] wrote: It's about simplifying code, with the side effect of perhaps small performance gains. It's also the first step to drop COM in wined3d, but that's not my intention (it seems Stefan likes the idea). Well, you can't half-remove COM. If you start removing refcounts like this you have to follow it all the way through, imo. I'm not half removing COM (at most 3% :-) ). lpVtble, IUnknown, IID_*, ... is still in place. I just simplified some refcount behaviour in wined3d, which happens to make wined3d less dependandt on the refcount COM feature. Which in turn makes it easier to remove COM. I dont' dare even trying to remove COM. That would be far over my skills.
Re: wined3d [3]: Add IsImplicit/SetImplicit surface functions.
Stefan Dösinger wrote: Does wined3d have to know if the surface is implicit? Wouldn't it be sufficient to just store it in the d3d8/9 surface? This would avoid adding more complexity to wined3d. The problem is the implicit surface (IS) destruction in wined3d (device and swapchain). Release won't destroy them, so wined3d needs a way to destroy IS. I solved it with setImplicit(false); release;. Another posibility would be to move the IS destruction to d3d8/d3d9. There we would have more control over the IS, and the parentDevice problem from patch [5] would also be solved. But it means some code duplication in d3d8/d3d9. I went for less code.
Re: d3d8/wined3d [5]: Create implicit surfaces with refcount 0.
Stefan Dösinger wrote: Currently our CreateTexture(surface, vertexbuffer, ...) increases the device refcount and initializes the refcount to 1. In my eyes it would be cleaner to init the refcount of everything to 0, and if the interface is not implicit AddRef it(from 0 to 1) in Create*. In AddRef, when increasing the refcount from to to 1, AddRef the device. You're right. Besides, we have already enough bogus AddRef/Release calls. I tried to keep the changes as small as possible. Hey I simply wanna game BF1942 :-)
Re: d3d8 2: Test refcount forwarding.
H. Verbeet wrote: On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: +extern int get_refcount(IUnknown *object); --- -static int get_refcount(IUnknown *object) +int get_refcount(IUnknown *object) We don't really want to do that. The idea is that a test should depend only on the .c file it's defined in. That's also why eg. the code to initialise a D3D device is duplicated everywhere. Ok. In the following test headers are extern functions: dlls/dinput/tests/dinput_test.h dlls/dsound/tests/dsound_test.h dlls/winmm/tests/winmm_test.h so i thought it's fine. Should we remove them?
Re: RFC: d3d8 refcount implementation
H. Verbeet wrote: On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: The implicit surfaces now gets released if the refcount is -1. Somehow we have to force releasing d3d8 sufaces from wined3d. No idea how. You could probably either force the refcount to 0 (ie, something like while(IWineD3DSurface_Release(surface));), I'm not sure what you mean. IWineD3DSurface_Release won't release the d3d8 surface. Besides, the surface shouldn't be released with refcount==0, only on device destruction. or add an explicit destructor to the d3d8 implementation. That's not too pretty either, but I suppose it's better than releasing on -1. This would mean a wine specific d3d8 interface extension. I'm not sure whether that's acceptable. Perhaps we could misuse an existing function (e.g QueryInterface with a magic refiid, to destroy the surface, or set/get maigc private data). Or handle implicit surface destruction in IDirect3DDevice8_Release and not in IWineD3DDevice_Uninit3D. There we could use our private d3d8 destruct function. Looks for me like the way to go. I added a flag to mark the implicit surfaces. It's redundant, because wined3d knows the implicit surfaces. The other idea is calling GetRenderTarget and friends in Surface_(AddRef/Release). Besides the problem of an endless recursion, it would be quite an overhead. Shouldn't we just check if the surface's container is the same as the surface's device? For d3d8 this would be a nice solution. But in d3d9 the implicit RenderTarget's container is the swapchain. I think we should handle d3d8 and d3d9 the same way. Totally unrelated to this, are you ever on IRC? Not yet, but I could. Is it easier to discuss such stuff on IRC?
RFC: d3d8 refcount implementation
After spamming wine-patches with d3d tests, I tried to implement the
probed behaviour. Attached are two patches, which makes all d3d8
refcount test pass. They are small and ugly. The problems are:
The implicit surfaces now gets released if the refcount is -1. Somehow
we have to force releasing d3d8 sufaces from wined3d. No idea how.
I added a flag to mark the implicit surfaces. It's redundant, because
wined3d knows the implicit surfaces. The other idea is calling
GetRenderTarget and friends in Surface_(AddRef/Release). Besides the
problem of an endless recursion, it would be quite an overhead.
Another problem is, that IWineD3DDeviceImpl_Uninit3D calls via GetParent
AddRef/Release on the d3d8 surface. This causes the device to be
released again(=endless recursion). I solved it with ignoring an
addref from 0 in the d3d8 Device, which causes the release to be -1 =
no wined3d device releasing. Works but ugly.
Ideas, suggestions?
From 1a73ec5958e2e4c7fd076184c9e1f1cf7427d936 Mon Sep 17 00:00:00 2001
From: Markus Amsler [EMAIL PROTECTED]
Date: Mon, 13 Nov 2006 22:29:12 +0100
Subject: [PATCH] d3d8: Force implicit surfaces to handle their own refcount.
To: wine-patches [EMAIL PROTECTED]
---
dlls/d3d8/d3d8_private.h |3 +++
dlls/d3d8/directx.c |2 ++
dlls/d3d8/surface.c |4 ++--
dlls/d3d8/tests/device.c |6 +++---
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/dlls/d3d8/d3d8_private.h b/dlls/d3d8/d3d8_private.h
index b32033f..9ca9989 100644
--- a/dlls/d3d8/d3d8_private.h
+++ b/dlls/d3d8/d3d8_private.h
@@ -246,6 +246,9 @@ struct IDirect3DSurface8Impl
/* Parent reference */
LPDIRECT3DDEVICE8 parentDevice;
+
+/* Flags an implicit surface */
+BOOL implicit;
};
/* -- */
diff --git a/dlls/d3d8/directx.c b/dlls/d3d8/directx.c
index 42ae40d..b51181e 100644
--- a/dlls/d3d8/directx.c
+++ b/dlls/d3d8/directx.c
@@ -202,6 +202,7 @@ HRESULT WINAPI D3D8CB_CreateRenderTarget
*ppSurface = d3dSurface-wineD3DSurface;
IUnknown_Release(d3dSurface-parentDevice);
d3dSurface-parentDevice = NULL;
+d3dSurface-implicit = TRUE;
} else {
*ppSurface = NULL;
}
@@ -281,6 +282,7 @@ HRESULT WINAPI D3D8CB_CreateDepthStencil
*ppSurface = d3dSurface-wineD3DSurface;
IUnknown_Release(d3dSurface-parentDevice);
d3dSurface-parentDevice = NULL;
+d3dSurface-implicit = TRUE;
}
return res;
}
diff --git a/dlls/d3d8/surface.c b/dlls/d3d8/surface.c
index 8ab312e..83265e9 100644
--- a/dlls/d3d8/surface.c
+++ b/dlls/d3d8/surface.c
@@ -46,7 +46,7 @@ static ULONG WINAPI IDirect3DSurface8Imp
TRACE((%p)\n, This);
-IWineD3DSurface_GetContainerParent(This-wineD3DSurface, containerParent);
+if (!This-implicit)
IWineD3DSurface_GetContainerParent(This-wineD3DSurface, containerParent);
if (containerParent) {
/* Forward to the containerParent */
TRACE((%p) : Forwarding to %p\n, This, containerParent);
@@ -65,7 +65,7 @@ static ULONG WINAPI IDirect3DSurface8Imp
TRACE((%p)\n, This);
-IWineD3DSurface_GetContainerParent(This-wineD3DSurface, containerParent);
+if (!This-implicit)
IWineD3DSurface_GetContainerParent(This-wineD3DSurface, containerParent);
if (containerParent) {
/* Forward to the containerParent */
TRACE((%p) : Forwarding to %p\n, This, containerParent);
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index 06f8aab..86e10af 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -429,17 +429,17 @@ static void test_refcount(void)
/* check implicit back buffer */
hr = IDirect3DSwapChain8_GetBackBuffer(pSwapChain, 0, 0, pBackBuffer);
todo_wine CHECK_CALL( hr, GetBackBuffer, pDevice, ++refcount);
-todo_wine CHECK_REFCOUNT( pSwapChain, 1);
+CHECK_REFCOUNT( pSwapChain, 1);
if(pBackBuffer)
{
todo_wine CHECK_CONTAINER( Surface, pBackBuffer,
IID_IDirect3DDevice8, pDevice, S_OK);
todo_wine CHECK_REFCOUNT( pBackBuffer, 1);
todo_wine CHECK_ADDREF_REFCOUNT(pBackBuffer, 2);
-todo_wine CHECK_REFCOUNT(pSwapChain, 1);
+CHECK_REFCOUNT(pSwapChain, 1);
todo_wine CHECK_REFCOUNT(pDevice, refcount);
todo_wine CHECK_RELEASE_REFCOUNT(pBackBuffer, 1);
-todo_wine CHECK_REFCOUNT(pSwapChain, 1);
+CHECK_REFCOUNT(pSwapChain, 1);
todo_wine CHECK_REFCOUNT(pDevice, refcount);
todo_wine CHECK_RELEASE_REFCOUNT( pBackBuffer, 0);
--
1.4.3.3
From 99bea2c16f008c412d578c81919bc52985396145 Mon Sep 17 00:00:00 2001
From: Markus Amsler [EMAIL PROTECTED]
Date: Tue, 14 Nov 2006 00:15:31 +0100
Subject: [PATCH] d3d8: Hack to fix all refcount issues.
To: wine-patches [EMAIL PROTECTED]
---
dlls/d3d8/device.c |1 +
dlls/d3d8/directx.c |6
WineD3D: heap corruption in d3dfmt_convert_surface
I have (finally!) found the heap corruption in bf1942: Small surfaces have a pitch of 4 and a width 4. This results in pitch*4 outpitch in IWineD3DSurfaceImpl_LoadTexture:1844. Afterwards the heap gets corrupted in d3dfmt_convert_surface:1654. The attached patch fixes the problem. I'm quite sure this fix is ugly, Suggestions? Markus
WineD3D: heap corruption patch
Oops, forgot to attach
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index d0f44cf..45972c4 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -1841,8 +1841,7 @@ static HRESULT WINAPI IWineD3DSurfaceImp
int height = This-glRect.bottom - This-glRect.top;
/* Stick to the alignment for the converted surface too, makes it
easier to load the surface */
-outpitch = width * bpp;
-outpitch = (outpitch + 3) ~3;
+outpitch = pitch * 4;
mem = HeapAlloc(GetProcessHeap(), 0, outpitch * height);
if(!mem) {
Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
Stefan Dösinger wrote: With vertex fixups I'd expect it to give 20-25 fps. You can test what you're likely to get with the attached hack. Gain with Bf1942 is about 20-30%, not bad for a one liner.
Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
Stefan Dösinger wrote: Am Samstag 28 Oktober 2006 16:44 schrieben Sie: Its a Radeon Mobility M7 LW, with direct rendering. It has a RV200 core which is a R100 with the memory controller from R200. And it looks like the R100 doesn't support vertex_buffer_objects (couldn't find precise specs). How well does bf1942 work without vertex buffers? My experiance with my M9 is that it got a 100% performance boost with vbos. It's playable (~10-15fps), perhaps 1/3-1/5 of w2k performance. That were rather the vertex fixups, not the vbos themselves. I think you can get most of that gain by improving the vertex buffer code to be able to do vertex fixups without VBOs Thanks for the tip. I will have a look at it.
Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
Stefan Dösinger wrote: -GLint curVBO = -1; +GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; Strange, I thought I sent a patch like that already and it was committed :-/ You wrote it for loadNumberedArrays, I copy pasted it to loadVertexData. I have to admit, I don't know exactly what I'm doing here (opengl/d3d newbie). But this patch lets me play Battlefield 1942 on my laptop where ARB_VERTEX_BUFFER_OBJECT is not supported :-)
Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
Stefan Dösinger wrote: Am Samstag 28 Oktober 2006 13:31 schrieb Markus Amsler: Stefan Dösinger wrote: -GLint curVBO = -1; +GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; Strange, I thought I sent a patch like that already and it was committed :-/ You wrote it for loadNumberedArrays, I copy pasted it to loadVertexData. I have to admit, I don't know exactly what I'm doing here (opengl/d3d newbie). The code below checks if the VBO for the data type in the stream is the vbo that is currently bound. 0 means no vbo, so setting the vbo to 0 equals operation without vbos. There is no member checking the current vbo in the device, only the curvbo optimization in the loading functions(waits for better state management). If vbos are not supported the vbo for each data in the stream source is always 0. Setting curvbo to 0 if vbos aren't supported will make sure that the .vbo != curvbo check is always false and glBindBufferARB is never called, preventing the crash due to a NULL or invalid function pointer. Thanks, so the patch is correct after all. But this patch lets me play Battlefield 1942 on my laptop where ARB_VERTEX_BUFFER_OBJECT is not supported :-) Could it be that you have some radeon dri setup without direct rendering(using accelerated indirect rendering instead)? I think even a gf2 and a mach64 card support vertex buffers objects, so I'm kinda surprised yours does not. Though, I also wonder why accelerated indirect rendering won't do VBOs. Its a Radeon Mobility M7 LW, with direct rendering. It has a RV200 core which is a R100 with the memory controller from R200. And it looks like the R100 doesn't support vertex_buffer_objects (couldn't find precise specs).
d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
I'm trying to solve bug 5872 http://bugs.winehq.org/show_bug.cgi?id=5872
BF1942 calls GetDepthStencilSurface/IUnknown_Release and checks the
refcount to be 0, but wine returns 1. (test hack attached)
I have done some testing: The first call to GetDepthStencilSurface
increases the refcount of the device, any subsequent call increases the
refcount of the surface.
On release calls the refcount of the surface gets decreased. If the
refcount is 1 the release call decreases the surface refcount AND the
device refcount.
The exact same behaviour shows GetRenderTarget. d3d9 does also the same.
Any ideas how we should implement this behaviour?
Markus
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index e735502..3ad8ca0 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -20,6 +20,7 @@ #define COBJMACROS
#include d3d8.h
#include dxerr8.h
#include wine/test.h
+#include stdio.h
static IDirect3D8 *(WINAPI *pDirect3DCreate8)(UINT);
@@ -183,6 +184,8 @@ static void test_refcount(void)
D3DPRESENT_PARAMETERSd3dpp;
D3DDISPLAYMODE d3ddm;
int refcount = 0, tmp;
+IDirect3DSurface8 *pRenderTarget2 = NULL;
+IDirect3DSurface8 *pStencilSurface2 = NULL;
DWORD decl[] =
{
@@ -217,6 +220,8 @@ static void test_refcount(void)
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = d3ddm.Format;
+d3dpp.EnableAutoDepthStencil = TRUE;
+d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
hr = IDirect3D8_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL,
hwnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING, d3dpp,
pDevice );
@@ -226,6 +231,41 @@ static void test_refcount(void)
refcount = get_refcount( (IUnknown *)pDevice );
ok(refcount == 1, Invalid device RefCount %d\n, refcount);
+printf(hr=%x refDevice=%d\n\n, hr, refcount);
+
+hr = IDirect3DDevice8_GetDepthStencilSurface(pDevice, pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, get_refcount( (IUnknown
*)pStencilSurface2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetDepthStencilSurface(pDevice, pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, get_refcount( (IUnknown
*)pStencilSurface2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetRenderTarget(pDevice, pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, get_refcount( (IUnknown
*)pRenderTarget2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetRenderTarget(pDevice, pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, get_refcount( (IUnknown
*)pRenderTarget2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n, hr, get_refcount( (IUnknown *)pDevice) );
+return;
+
/* Buffers */
hr = IDirect3DDevice8_CreateIndexBuffer( pDevice, 16, 0, D3DFMT_INDEX32,
D3DPOOL_DEFAULT, pIndexBuffer );
CHECK_CALL( hr, CreateIndexBuffer, pDevice, ++refcount );
@@ -316,6 +356,6 @@ START_TEST(device)
if (pDirect3DCreate8)
{
test_refcount();
-test_swapchain();
+//test_swapchain();
}
}
Re: wine segfaulting
Hi, What kernel version/distro are you using? What about make test. I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine. I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue. Markus Pavel Troller wrote: Hi! I have a problem running wine on one of my machines. It's the same binary copy which I've compiled and which successfully runs on another ones. The problem is that many apps, which run on other machines, cause wine to segfault here. The first one doing so is rundll.exe setupapi.dll..., invoked during wineprefixcreate process, so there is even a problem creating a fresh .wine directory. Simple apps, like winecfg and notepad, run well. Other ones don't. For some of them, wine dumps a lot of warnings before the segfault, but exactly the same warnings are emitted on another machines, where the app runs well. When the app fails, it even doesn't start to render its window. However, when a virtual desktop is to be used, it appears but it's still empty in the moment of the fault.
Re: msvcrt: fread: fill buffer on small reads
Duane Clark wrote:
Alexandre Julliard wrote:
Markus Amsler [EMAIL PROTECTED] writes:
+ /* fill empty buffer on small reads */
+ if(!file-_cnt rcnt = MSVCRT_BUFSIZ) {
+MSVCRT__filbuf(file);
+/* reset internal buffer */
+file-_cnt++;
+file-_ptr = file-_base;
+ }
You need to handle errors properly, and MSVCRT__filbuf is probably not
the most appropriate thing to use here, a simple read would be
better.
Are you referring to _read() or read_i()? Those don't have an
associated internal file buffer/cache (I guess because they don't have
an associated file-_cnt and _ptr). Or were you referring to some
other read call?
fread already does a _read() once it determines the current buffer is
empty.
I'm also not sure which read you mean. But i assumed some sort of
stripped down inline MSVCRT__filbuf with read_i.
Markus
Re: wine segfaulting
Marcus Meissner wrote: On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote: Hi, What kernel version/distro are you using? What about make test. I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine. I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue. Is there a ulimit set? (ulimit -a) But I think we solved this specific problem already. there is, but 2.6.17, 2.6.18 have the same settings. core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) unlimited file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) unlimited stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Setting stack size to unlimited didn't help either. As for make test ... was the exception test the problem? Ciao, Marcus Yes Almost every dll test fails somehow kernel32 for example: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so change.c touch change.ok err:seh:setup_exception nested exception on signal stack in thread 0010 eip 4440 esp 7ffdbc80 stack (nil)-0x change.c:80: Test failed: Missed notification err:seh:setup_exception nested exception on signal stack in thread 0015 eip 4440 esp 7ffd9c80 stack (nil)-0x change.c:80: Test failed: Missed notification make: *** [change.ok] Fehler 2 I also setted /proc/sys/vm/legacy_va_layout to 0|1. But no effect. Markus
Re: RFC: sfd2ttf
Jan Z. wrote: Btw. if we include other fonts in the future, as example the MS Tahoma replacement Greenville we need to include the ttf anyway as there is no source or perhaps only one usable with a nonfree as in money tool. Fontforge can convert ttf files to sfd. Another possibility would be to split the fonts off of wine. So we have separate source and binary packages. We could also add font download/install functionality to winecfg and install the MS core fonts. Markus
RFC: sfd2ttf
Hi, Here's a first version of an sfd2ttf tool based on fontforge-20051205. You can dwonload it from [1]. It consists of 5 files (with Makefile) and has a size of 500K. There's still some dead code lying around, I think I can bring it down to 300K-400K. Is this acceptable? SFD reading was quite easy, the code was well seperated. TTF generation was a bit harder. I decided to output TrueType, with bitmap tables from OpenType. The others ttf variations (full OpenType or even aat (Apple Advanced Typography)) are not supported, as it would make the tool a lot bigger (factor 2-5 or so) and i believe it's not needed (right?). I'm really no font expert, so any comment is welcome. Markus [1] http://oribi.org/download/sfd2ttf.tar.gz
Re: advpack: The Plan
James Hawkins wrote: Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. I'm quite sure RunPreSetupCommands gets executed before the base INF commands. I'm not sure wether there are others (BeginPrompt, BackupReg comes to mind). So you need two install functions like adv_install_pre and adv_install_post. This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you. Why not simply use the same mechanism as in setupapi [1]? My patch [2] back in january was using it, and it looked like a good idea. Markus [1] http://source.winehq.org/source/dlls/setupapi/install.c [2] http://www.winehq.org/pipermail/wine-devel/2006-January/044083.html
Re: advpack: Implement LaunchINFSection on top of DoInfInstall
James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus
Re: [oleaut32] Fix for pr4190, _invoke unsupported number of arguments 15 in stdcall
Dan Kegel wrote: The riched20 test app described in http://bugs.winehq.com/show_bug.cgi?id=4190 seems to require the patch http://kegel.com/wine/pr4190.patch which adds support for invoking functions with 15 or 16 parameters. This is similar to the first patch in http://bugs.winehq.com/show_bug.cgi?id=1912 -- Wine for Windows ISVs: http://kegel.com/wine/isv I don't think Alexandre is going to download the patch. For me (thunderbird-linux) attaching the pach works. For testing, you can send a patch to yourself, save the raw message and try* $ **cat raw_mail | patch -p0 or **$ cat raw_mail | patch -p1 According to Alexandre's Bottom Line [1]. If you still have problems I could download the patch and forward the message. [1] http://www.winehq.com/site/docs/winedev-guide/style-notes *
Re: Preliminary CD-Rom support on MacOS X #5
Hi, I took a look at your patches, here's what i've found: ntdll_cdrom.diff: # @ cdecl MODULE_DllThreadAttach(ptr) @ cdecl MODULE_GetLoadOrderW(ptr wstr wstr) +@ cdecl CDROM_InitCDDevices() +@ cdecl CDROM_FoundDevices() +@ cdecl CDROM_BSDPathForMedia(ptr) +@ cdecl CDROM_GetMountPointForBSDDevice(ptr) +@ cdecl CDROM_BSDPathForHandle(long) \ No newline at end of file - You shouldn't add more seperation hacks. Besides that, if _APPLE_ is not defined, the linker doesn't find these symbols. - Gcc spits out warnings about the missing newlines at the end of files. Markus
Re: advpack: fix LaunchInfSection[Ex] documentation
James Hawkins wrote: On 12/22/05, Markus Amsler [EMAIL PROTECTED] wrote: - * show[I] How the window should be shown. + * show[I] Reboot behaviour: + * 'A' reboot always + * 'I' default, reboot if needed + * 'N' no reboot * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins I found it on MSDN for LaunchINFSectionEx [1], and assumed the same for LaunchInfSection. I haven't tested it (yet). We shouldn't test the reboot behaviour in the wine tests, a lot of windows testers would get angry. Perhaps i code a little app. Markus [1] http://msdn.microsoft.com/workshop/delivery/download/overview/launchinfsectionex.asp
Re: Can't install mdac at all now
Dan Kegel wrote: Markus is working on a better implementation Any ETA? I guess I'll stop worrying, if he's going to get that area working, he'll fix this regression anyway. - Dan I'm mainly working on the advpack install functions. I'll have a look at the regression, but don't expect anything too soon (days to weeks, not months). Markus
Re: [advpack/setupapi] LaunchINFSection
Hi,
James Hawkins wrote:
* it would help to add test cases wherever you can even if it's just
to check how the function handles parameters.
I'm also working on advpack inf install functions. Perhaps we should
coordinate our work:
Here my current Roadmap:
1. get tests into CVS (see below)
2. fix doinfinstall
3. implement RunSetupCommand, Rewrite DoInfInstall, to call
RunSetupCommand.
4. Implement LaunchInfSection, LaunchInfSectionEx on top of
RunSetupCommand.
5. test installers, improve the tests (eg. test for
Run{Post,Pre}SetupCommand, registry entries, copied files, ..) and fix
the functions.
I'm currently on point 1:
I have written test cases for DoInfInstall, RunSetupCommand,
LaunchInfSection, LaunchInfSectionEx, and documented my findings (see
attachement). They pass on my w2k.
Can some one run this tests on win98?
Any comments on the patch are highly welcome (my C skills are a little
rosty).
Markus
Index: dlls/advpack/advpack.c
===
RCS file: /home/wine/wine/dlls/advpack/advpack.c,v
retrieving revision 1.14
diff -u -r1.14 advpack.c
--- dlls/advpack/advpack.c 8 Nov 2005 12:43:35 - 1.14
+++ dlls/advpack/advpack.c 17 Nov 2005 14:12:57 -
@@ -56,20 +56,20 @@
* Executes an install section in an INF file or a program.
*
* PARAMS
- * hWnd [I] Handle to parent window, NULL for quiet mode
+ * hWnd [I] Handle to parent window, NULL for desktop
* szCmdName [I] Inf or EXE filename to execute
* szInfSection [I] Inf section to install, NULL for DefaultInstall
* szDir [I] Path to extracted files
* szTitle [I] Title of all dialogs
* phEXE [O] Handle of EXE to wait for
- * dwFlags [I] Flags; see include/advpub.h
+ * dwFlags [I] Flags; see RSC_* in include/advpub.h
* pvReserved[I] Reserved
*
* RETURNS
* S_OK Everything OK
* S_ASYNCHRONOUS OK, required to wait on phEXE
* ERROR_SUCCESS_REBOOT_REQUIREDReboot required
- * E_INVALIDARG Invalid argument given
+ * E_INVALIDARG Invalid argument, szCmdName or szDir
NULL
* HRESULT_FROM_WIN32(ERROR_OLD_WIN_VERSION)
*Not supported on this Windows version
* E_UNEXPECTED Unexpected error
@@ -92,34 +92,84 @@
/***
* LaunchINFSection (ADVPACK.@)
+ *
+ * Install an INF section without BACKUP/ROLLBACK capabilities.
+ *
+ * PARAMS
+ * hWnd[I] Handle to parent window, NULL for desktop.
+ * hInst [I] Optional program instance.
+ * cmdline [I] Coma seperated string with inf file name, section name, flags.
+ * show[I] Reboot behaviour, see LaunchINFSectionEx().
+ *
+ * RETURNS
+ * Success: S_OK
+ * Failure: S_FALSE
+ *
+ * NOTES
+ * For possible cmdline flags see LIS_* in include/advpub.h. They differ from
+ * flags in LaunchINFSectionEx().
+ *
+ * BUGS
+ * Unimplemented
*/
-void WINAPI LaunchINFSection( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT
show )
+HRESULT WINAPI LaunchINFSection( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline,
INT show )
{
FIXME((%p %p %s %d): stub\n, hWnd, hInst, debugstr_a(cmdline), show );
+return S_FALSE;
}
/***
* LaunchINFSectionEx (ADVPACK.@)
+ *
+ * Install an INF section with BACKUP/ROLLBACK capabilities.
+ *
+ * PARAMS
+ * hWnd[I] Handle to parent window, NULL for desktop.
+ * hInst [I] Optional program instance.
+ * cmdline [I] Coma seperated string with
+ * inf file name, section name, cabinet path, flags.
+ * show[I] Reboot behaviour:
+ * 'A' reboot always
+ * 'I' default, reboot if needed
+ * 'N' no reboot
+ *
+ * RETURNS
+ * S_OKEverything OK
+ * E_INVALIDARGInvalid argument, cmdline NULL
+ * HRESULT_FROM_WIN32(GetLastError()) Some other error
+ *
+ * NOTES
+ * For possible cmdline flags see ALINF_* in include/advpub.h.
+ *
+ * BUGS
+ * Unimplemented
*/
-void WINAPI LaunchINFSectionEx( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline,
INT show )
+HRESULT WINAPI LaunchINFSectionEx( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline,
INT show )
{
FIXME((%p %p %s %d): stub\n, hWnd, hInst, debugstr_a(cmdline), show );
+return E_NOTIMPL;
}
-/* this structure very closely resembles parameters of RunSetupCommand() */
-typedef struct
-{
-HWND hwnd;
-LPCSTR title;
-LPCSTR inf_name;
-LPCSTR dir;
-LPCSTR section_name;
-} SETUPCOMMAND_PARAMS;
-
/***
* DoInfInstall (ADVPACK.@)
+ *
+ * Install an INF section.
+ *
+ *
Re: Measuring Wine's API completeness
Hi, Michael Jung wrote: Something like 'IMPLEMENTATION STATUS', which would document the author's opinion on how complete the implementation of a given API is. We could introduce a classification scheme similar to: STUBBED: Well, stubbed. SKETCHY: Implemented just enough to make a specific application or a small set of applications happy. SUBSTANTIAL: Implemented a substantial part of the API (Perhaps as much as is documented on MSDN). COMPLETE:The author of this API considers the implementation complete. REVIEWED:The code was reviewed for completeness and correctness. Steven Edwards wrote: We have a dynamic page like this for ReactOS though I don't like it because it only supports implemented and unimplemented tags in the function comment. I like the states from Michael, and the short @-notation from ReactOS. The implementation status is just a flag, writting a whole section is IMO an overkill. Any agreements on this proposal: @-notation, 5 states: @unimplemented (=STUBBED) @skechty @substantial @implemented(=COMPLETE) @reviewed 2 possible usages: - Header: /** * LsaFreeMemory [EMAIL PROTECTED] @implemented */ - on its own line: /** * LsaLookupNames [EMAIL PROTECTED] * * @substantial */ The parser would simply look for the keywords (@substantial, @..), false positives are pretty unlikley (not one in the wine source). Markus
c2man comment rejection
Hi, I identified 80 function comments, that have a description and a PARAMS section, but no RETURNS section. IMHO it would generate in most cases acceptable documentation, but gets rejected because of the missing RETURNS section. 2 possible fixes: - patch c2man so it accepts also PARAMS sections pro: small change, more html documented functions in general con: some functions have unsuitable comments - add RETURNS section to comments pro: cleaner documentation con: more changes, a lot of RETURNS TRUE on success FALSE otherwise- style comments. Which way to go? Markus identified Functions: IsTextUnicode CryptAcquireContextW SystemFunction036 SystemFunction040 SystemFunction041 BuildSecurityDescriptorA SetFileSecurityW StartServiceCtrlDispatcherA StartServiceCtrlDispatcherW GetEnhMetaFileHeader GetEnhMetaFileDescriptionW PlayEnhMetaFile PolyTextOutA PolyTextOutW GdiInit216 PlayMetaFile GetMetaFileBits16 SetMetaFileBits16 SetMetaFileBitsEx GetMetaFileBitsEx SetPixelFormat SwapBuffers PolyBezier PolyBezierTo AbortPath WaitCommEvent CommConfigDialogW WriteConsoleOutputCharacterA SetConsoleCursorPosition GetDriveType16 IsValidLocale SetLastError GetLastError GetCurrentProcessId GetCurrentThreadId SetLastError ThunkConnect32 ThunkInitSL SSCall FreeSLCallback ThunkConnect16 VirtualAllocEx GetColorDirectoryW ICInfo AcceptEx TransmitFile RtlSetLastWin32Error RtlSetLastWin32ErrorAndNtStatusFromNtStatus RtlOpenCurrentUser RtlCreateSecurityDescriptor RtlCopySecurityDescriptor _splitpath CreateILockBytesOnHGlobal16 CoInitialize16 ProgIDFromCLSID16 CoRegisterClassObject16 ReadClassStg16 SetupOpenInfFileW ILAppend ILFree ILGlobalFree RegisterShellHook SHUpdateImageW IShellFolder_ParseDisplayName SHFileOperationA SHFreeNameMappings IUnknown_SetSite CreateIcon SetCursor SetDebugErrorLevel DestroyAcceleratorTable SetScrollRange ShowScrollBar OpenThemeFile CloseThemeFile ApplyTheme GetThemeDefaults EnumThemes CheckThemeSignature EnumPrintersW
Re: How difficult would it be to make the equivalent of Windows Terminal Server with Wine?
Hans Leidekker wrote: different apps you want to serve. The user uses IE to navigate to that page. When clicking, the App comes up as a window in his/her machine. First time visit Installs a 12M Cygwin/X server. I really like the concept but your approach seems to limit publishing of apps to Windows boxes. Theoretically you could run the OCX (Internet Explorer) on Wine and the Cygwin/X as well but not practically though, if only from a performance point of view. It would be more interesting if Mac/Linux/Unix users could use their browser of choice and their native X server, which is usually already installed on those platforms. How exactly is this approach dependent on the use of an OCX? -Hans I really like the idea invoking a X-session from your browser. Some time ago working on some complex php/dhtml web site administration scripts, I had the feeling programming a real app instead of a web app would be much easier. I never got concrete, but made some ideas. My approach was the following: Server side: - defining a mime-type application/x11-control (or something similar) - a x control file, with all the information to connect to the X-client over ssh (app-name, host, ports, [ssh username,password], ...). (say tst.x11) - a link to the tst.x11 file in the webpage. - the app itself - a unix user (anonymous or autorized) Client side: - A x invoking script - Map application/x11-control type to the x-script When you click on the link, your x-script gets invoked with the tst.x11 files, which then connects to the x-client. You could also (optionally) specify an anonymous user/password setting for the ssh tunnel. This approach would be completly platform independant. But it would require the web-client to install the x-script and map the mime-type (well the x-script installation could do that). I googled a little around, but found nothing similiar, although the approach seems to me pretty obvious. This may be a little off-topic, but the idea combining http and x is really fascinating. Markus
Re: Ok, trying again
Hi,
This patch doesn't aplly smoothly, because you did the cvs diff not from
the wine-root directory.
do: at ~/src/wine$ cvs diff -u dlls/msvrt/tests/file.c
You can test if your patch apllies with
$ patch -p0 file.diff
from the wine root. If there are no error messages the format is fine.
To remove the patch do
$ patch -p0 -R file.diff
I hope this helps
Markus
Jakob Eriksson wrote:
*src/wine/dlls/msvcrt/tests
*
[EMAIL PROTECTED]:~/src/wine/dlls/msvcrt/tests$ cvs diff -u file.c
Index: file.c
===
RCS file: /home/wine/wine/dlls/msvcrt/tests/file.c,v
retrieving revision 1.10
diff -u -r1.10 file.c
--- file.c 3 Sep 2004 01:05:30 - 1.10
+++ file.c 1 Nov 2004 16:24:06 -
@@ -306,7 +306,25 @@
ok(res[strlen(res)-1] != '.', second call - last character is a
dot\n);
}
+static void test_access( void )
+{
+FILE *fp;
+
+const char filename[] = tmpfile.tst;
+ok(-1 == _access(filename, 0), This file should not exist yet.\n);
+ok(ENOENT == errno, and errno should be ENOENT but it is %d.\n,
errno);
+
+fp = fopen(filename, w);
+if (NULL == fp) return;
+fclose(fp);
+ok(0 == _access(filename, 0), Now the file should exist.\n);
+ok(0 == _access(filename, 2), We should have write permission,
after all I created it. errno=%d\n, errno);
+ok(0 == _access(filename, 4), We should have read permission.
errno=%d\n, errno);
+ok(0 == _access(filename, 6), We should also be able to check
for read and write permission. errno=%d\n, errno);
+
+_unlink(filename);
+}
START_TEST(file)
{
@@ -321,6 +339,7 @@
return;
}
+test_access();
test_fdopen();
test_fileops();
test_fgetwc();
Re: signaling unix threads
Jukka Heinonen wrote:
Yep. If using Linux 2.6 kernel and recent pthread library,
threads share the same pid and they must be signalled using
tkill and not kill.
Yes, you're right. I already wondered why dosvm worked before, it was
because I used a 2.4 kernel.
The only place which knows how to
correctly signal threads is send_thread_signal function in
server/ptrace.c. So, the easy way to fix signalling is
to use Windows thread identifier for identifying dosvm thread
instead of pids (which don't work anyway) and add to wineserver
a handler that just calls send_thread_signal, which I guess
is what you have been doing, anyway.
No, I did it much more uglier, that's why I asked the list. Thanks.
Alexandre Julliard wrote:
Jukka Heinonen [EMAIL PROTECTED] writes:
Now, I have tried this approach and it seems to work. I have
some prototype implementation lying around but I was thinking
about doing something more complicated at the time,
like using SIGUSR2 handler for doing Win32 remote operations
discussed earlier on wine-devel, because signal handler
is probably running in the correct context for doing
this kind of things but I guess locking issues are going to
be pretty complicated so it is probably better to just fix
dosvm issues with a simple mechanism and not worry about
anything else.
It would certainly be nice if we could convince dosvm to stop using
SIGUSR2, there are lots of other things that could make better use of
it. I don't really have a good solution to offer though (except maybe
getting rid of dosvm altogether ;-)
What about using a win32 compatible way to signal dosvm thread (I know
in win32 there are no signals, but perhaps there's a undocu/hackish
way). So one day winedos could compile/run on ReactOS/Windows.
I also attached the patch which solves my signalling issues with kernel
2.6.8 and libc 2.3.2.
I'm pretty unsure about the wineserver stuff, so comments are welcome.
Markus
? thread_kill.diff
Index: dlls/winedos/dosvm.c
===
RCS file: /home/wine/wine/dlls/winedos/dosvm.c,v
retrieving revision 1.59
diff -u -r1.59 dosvm.c
--- dlls/winedos/dosvm.c4 Aug 2004 19:08:19 - 1.59
+++ dlls/winedos/dosvm.c31 Oct 2004 19:00:30 -
@@ -51,6 +51,7 @@
#include thread.h
#include dosexe.h
#include dosvm.h
+#include wine/server.h
#include wine/debug.h
#include excpt.h
@@ -58,6 +59,8 @@
WINE_DECLARE_DEBUG_CHANNEL(module);
WINE_DECLARE_DEBUG_CHANNEL(relay);
+extern HANDLE dosvm_thread, loop_thread;
+
WORD DOSVM_psp = 0;
WORD DOSVM_retval = 0;
@@ -278,11 +281,22 @@
else pending_event = event;
if (!old_pending DOSVM_HasPendingEvents()) {
+ BOOL success;
TRACE(new event queued, signalling (time=%ld)\n, GetTickCount());
/* Alert VM86 thread about the new event. */
- kill(dosvm_pid,SIGUSR2);
-
+ SERVER_START_REQ( send_thread_signal )
+ {
+req-handle = dosvm_thread;
+req-signal = SIGUSR2;
+wine_server_call( req );
+success = reply-success;
+ }
+ SERVER_END_REQ;
+
+ if (!success)
+ERR (Couldn't alert vm86 thread!\n);
+
/* Wake up DOSVM_Wait so that it can serve pending events. */
SetEvent(event_notifier);
} else {
Index: dlls/winedos/module.c
===
RCS file: /home/wine/wine/dlls/winedos/module.c,v
retrieving revision 1.45
diff -u -r1.45 module.c
--- dlls/winedos/module.c 18 Oct 2004 21:19:57 - 1.45
+++ dlls/winedos/module.c 31 Oct 2004 19:00:31 -
@@ -103,9 +103,9 @@
/* global variables */
pid_t dosvm_pid;
+HANDLE dosvm_thread, loop_thread;
static WORD init_cs,init_ip,init_ss,init_sp;
-static HANDLE dosvm_thread, loop_thread;
static DWORD dosvm_tid, loop_tid;
static void MZ_Launch( LPCSTR cmdtail, int length );
Index: include/wine/server_protocol.h
===
RCS file: /home/wine/wine/include/wine/server_protocol.h,v
retrieving revision 1.111
diff -u -r1.111 server_protocol.h
--- include/wine/server_protocol.h 18 Aug 2004 00:04:58 - 1.111
+++ include/wine/server_protocol.h 31 Oct 2004 19:00:35 -
@@ -3095,6 +3095,20 @@
#define SET_GLOBAL_TASKMAN_WINDOW 0x04
+
+struct send_thread_signal_request
+{
+struct request_header __header;
+obj_handle_t handle;
+int signal;
+};
+struct send_thread_signal_reply
+{
+struct reply_header __header;
+int success;
+};
+
+
enum request
{
REQ_new_process,
@@ -3274,6 +3288,7 @@
REQ_set_clipboard_info,
REQ_open_token,
REQ_set_global_windows,
+REQ_send_thread_signal,
REQ_NB_REQUESTS
};
@@ -3458,6 +3473,7 @@
struct set_clipboard_info_request set_clipboard_info_request;
struct open_token_request open_token_request;
struct set_global_windows_request
signaling unix threads
Hi, There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the current process, but it should be sent to the dosvm thread. This causes various ugly bugs. I found no way signaling a unix thread, without modifing the wineserver. I have implemented a thread_kill command in the wineserver, this solves my problem, but i'm quite sure it won't get applied. I'm really not a wineserver/threading expert. Have I missed something? Markus
Re: winedos: TSR (was MCB implementation)
Quoting Alexandre Julliard [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: Now, what should happen, if you start a TSR programm in a win32 shell (like wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR somehow in win32 (shell or ntdll) or no TSR support in win32 shells? No, TSR support doesn't make sense in Win32. What do you need it for? I'm trying to run a DOS application, that uses a TSR as a database driver. So I donn't need TSR support in win32. I was just thinking how TSR support should look like in wine, and that involves what should happen if you start a TSR programm in a win32 shell. You can run already DOS programms in Win32 shells, so it's naturally to try running a TSR. Markus
dosmem: MCB implementation
Hi, I'm trying to run freecom[1] of the freedos project in wineconsole. After changing comspec in user.reg and some ugly hacks to kernel/dosmem.c it runs (dosmem_paragraph.patch). But it will never run cleanly without proper MCB support (it does its own MCB-chain walking, like a lot of other programms). I tried to implement it (dos_mcb.patch also ugly), and now i have some design questions: - where to implement MCB's? kernel or winedos? (the PSP from winedos is needed to write the MCB and the first MCB is needed in winedos DOS_LOL[2]) - how to get rid of the separtion hack of DOSMEM[3] - what about the use of DOSMEM in global16.c, do they need also MCB's (found no docu about the GA_DOSMEM flag) Markus [1] http://freedos.sourceforge.net/freecom/FreeCOM.html [2] http://source.winehq.org/source/dlls/winedos/devices.c#L478 [3] http://source.winehq.org/source/dlls/kernel/kernel32.spec#L1164 dosmem_paragraph.patch Description: Binary data dos_mcb.patch Description: Binary data
Re: winedos: dos debugger support
Quoting Andreas Mohr [EMAIL PROTECTED]: What does this patch do? Does it do what I believe it does?? :-) (finally provide useful debugging for DOS programs launched by Wine?) Yeahp. For Debugging .com files you also have to apply the EXEC fix patch [1]. For line editing support, apply BUFFERED INPUT patch [5]. Tested Debuggers (for more see [2]): - Microsoft's debug.exe - ddeb.exe (my favorite) [3] - debug.com (with source) [4] Markus [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0044.html [2] http://www.programmersheaven.com/zone5/cat188/ [3] http://www.programmersheaven.com/zone5/cat188/26391.htm [4] http://www.programmersheaven.com/zone5/cat188/2025.htm [5] http://www.winehq.org/hypermail/wine-patches/2004/08/0043.html
CHDIR/SetCurrentDirectory returns FILE_NOT_FOUND
Hi, The installation routine of the ida dos disassembler (gg: ida37fw.zip), wonn't work, because winedos/int21:0x3b CHDIR returns ERROR_FILE_NOT_FOUND. If I return ERROR_PATH_NOT_FOUND it will install. ntdll:RtlSetCurrentDirectory returns STATUS_OBJECT_NAME_NOT_FOUND, which gets mapped to ERROR_FILE_NOT_FOUND (ntdll/error.c#L403). How to achieve the right behavior? - Check for FILE_NOT_FOUND in winedos/int21.c: INT21_SetCurrentdirectory - Check for FILE_NOT_FOUND in kernel/path.c: SetCurrentDirectoryW/A - map STATUS_OBJECT_NAME_NOT_FOUND to ERROR_PATH_NOT_FOUND Or any other idea? Markus
