"GyЖrgy 'Nog' Jeney" nog@sdf.lonestar.org wrote:
Here's the latest version of my RtlAtom test, these should now succeed on an nt system. Thanks to Dmitry for running the initial test.
There are failures yet.
atom.c:186: Test failed: We found wrong atom atom.c:232: Test failed: Able to find previously deleted atom in table, retval: c0000034 atom.c:248: Test failed: Able to find deleted atom in table atom.c:381: Test failed: Expected pincount 1 but got 3 atom.c:382: Test failed: Expected refcount 3 but got 0 atom.c:395: Test failed: Expected pincount 3 but got 3 atom: 163923 tests executed, 0 marked as todo, 6 failures.
You can send further versions to me directly until it's finished to avoid spamming the list.
Looking at the ReactOS implementations of RtlAtom* APIs, I've found that they conform to the results I get under win2k. Did you try to ask a permission to use their implementation in Wine? Steven?
-- Dmitry.
Looking at the ReactOS implementations of RtlAtom* APIs, I've found that they conform to the results I get under win2k. Did you try to ask a permission to use their implementation in Wine? Steven?
I don't think that shall be necessary, it looks like all that support is in the wineserver already. It seems like all that is required is to add a couple of server calls, but I may be wrong.
nog.
"GyЖrgy 'Nog' Jeney" nog@sdf.lonestar.org wrote:
Looking at the ReactOS implementations of RtlAtom* APIs, I've found that they conform to the results I get under win2k. Did you try to ask a permission to use their implementation in Wine? Steven?
I don't think that shall be necessary, it looks like all that support is in the wineserver already. It seems like all that is required is to add a couple of server calls, but I may be wrong.
What is missing in the wineserver server interface is the support for multiple atom tables (but it exists as an internal one). Anything else can be implemented using existing wineserver infrastructure, yes.
NTDLL atom APIs could be added later on when we'll find an application that depends on it.
-- Dmitry.
"GyЖrgy 'Nog' Jeney" nog@sdf.lonestar.org wrote:
I don't think that shall be necessary, it looks like all that support is in the wineserver already. It seems like all that is required is to add a couple of server calls, but I may be wrong.
One more point:
My tests under win2000 show that Windows uses several different atom tables for various needs: local atom table, global atom table, global atom table for registered window messages, global atom table for registered clipboard formats, local atom table for registered window classes and probably some others.
Instead of inventing our own API to handle multiple local and global atom tables, perhaps it would be better to implement NTDLL atom APIs and use them when appropriate.
-- Dmitry.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Instead of inventing our own API to handle multiple local and global atom tables, perhaps it would be better to implement NTDLL atom APIs and use them when appropriate.
I still haven't seen any evidence that this is needed. Do we really know of an app that uses the NTDLL atom APIs, or that depends on having multiple atom tables? Unless we find one, there's really no reason to worry about it.
From another mail:
What Microsoft say doesn't matter; what matters is what applications do. Many apps use SuspendThread, and it has to work reliably 100% of the time, not just 99%. It's the same argument we had with mutexes, and shared memory, etc. Sure you can simplify a lot of things if you don't try to handle "unlikely" cases; but practice has shown that no matter how unlikely a case may seem, there is a Windows app out there that triggers it. And we want to run *all* Windows apps, not just the ones that are lucky enough to not trigger our bugs.
Alexandre Julliard julliard@winehq.com
snip
I still haven't seen any evidence that this is needed. Do we really know of an app that uses the NTDLL atom APIs, or that depends on having multiple atom tables? Unless we find one, there's really no reason to worry about it.
Alexandre Julliard julliard@winehq.com
I can understand, that the focus lies on needed things, but it's still funny comparing these two statements :)
Anyway, thanks for a lot of good work. Peace :)
bye Fabi
"Fabian Cenedese" Cenedese@indel.ch wrote:
[skipped]
I can understand, that the focus lies on needed things, but it's still funny comparing these two statements :)
Fabian, let me explain. Alexandre will add clarifications on his own.
NTDLL (so called "native") APIs is a completely undocumented layer of internal NT APIs, and it's very unlikely that a Win32 application will use that API. Here I completely agree with Alexandre that it's better to spend the time on the known bugs and fix the published API (already *a lot* of work) instead of doing the work for nothing, or inventing virtual bugs. We always can reconsider, if a real application depending on that APIs will be found.
On the other hand we are forced to implement NTDLL loader related and some other native APIs, since there are known applications which do use them, and we need cleanly separate kernel and ntdll.
Hope that helps better understand our priorities.
Thanks.
I can understand, that the focus lies on needed things, but it's still funny comparing these two statements :)
Hope that helps better understand our priorities.
I didn't want to refer specifically to the mentioned APIs, it was more about:
"And we want to run *all* Windows apps, not just the ones that are lucky enough to not trigger our bugs."
against
"Do we really know of an app that uses ...? Unless we find one, there's really no reason to worry about it."
But as I said, it was more for the fun of it. I know that all of you are doing a lot of hard work which needs priorizing. And this wasn't critics at all. So let's make wine a better piece of SW. (I still need to do my part of it...)
bye Fabi
-
Alexandre Julliard -
Dmitry Timoshkov -
Fabian Cenedese -
György 'Nog' Jeney