-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think after the 10 or more patches to the Wintab dll that I submitted
last month, I should say something about it's status...
And of course thank Alexandre for applying those patches.
P.S. I won't be available from the 15th for about a week or so.
So, if you have any questions, I'm afraid you might have to be patient.
Hope this is of interest to someone
-Rob.
******Applications: Current status***********
***In Painter 5
*Cursor pressure works. (Therefore is usable by most)
*Cursor orientation is a little odd: The orientation maths needs to be
re-done.
*No eraser. Haven't yet cracked what enables the eraser.
*Doesn't work in desktop mode: Need to map to desktop coordinates.
*Repeats windows bugs where cursor looses pressure/orientation info
almost bug for bug (Is this a feature? ;-)
*Cannot detect pressure/orientation int the "Brush Tracking" window: The
tablet context is attached to the main window, so no events get to the
popup, even if they overlap.
This is not how windows wintab functions.
***In Photoshop 6.
*Can only get tablet data in desktop mode: This is because the tablet
context is attached to the desktop. Which generates/receives no wine
events outside desktop mode.
* Eraser and pen pressure working. *But* to get them working, you must
have 3 XInput devices listed in your XF86Config file, They need to be
the last entries in the "ServerLayout" section and the following order:
eraser, tablet mouse. This is a far from ideal way of specifying the
devices Wintab should use :-/
I'll document this if someone can point me to a good place to put the docs.
*******To Do*************
1. Look at X11 errors. There appear to be some errors that deny some
users the
ability to access Wintab enabled apps. (I think I know how to fix this)
2. Improve orientation data. Orientation comes in as X-Y coords
(Implicit Z), and has to leave as spherical coords. This calculation
needs to be re-done.
3. When tablet context is on top, let it read XInput events from all the
app's top-level windows. (This simulates the fact that the context is
usually designed to cover the whole screen)
4. When tablet context is attached to desktop, read XInput events from
all the app's top-level windows.
5. Tests
~ --My current philosophy on tests is...
~ Use Photoshop & Painter, any formal tests
~ can be written if anyone else gets involved in patching Wintab, to
avoid regressions, and conflict.
**********Long term to do (Anyone interested?):*********
There's a lot of work that could be done here, but what gets done
and who does it probably depends upon whether anyone finds an app that
needs these features. I'd love to implement these, but realistically, I
don't
foresee doing this unless someone hires me to do so ;)
1. Improve configuration of wintab.
Wintab could probably do with some information entered into the
config file, to avoid the user having to
hack their Xfree86cfg file.
2. Handle Z-Order of context properly.
This entails
*sharing Z-Order between apps.
*Working out exactly what role windows have in
determining tablet context z-orders.
*Allow tablet contexts that don't cover the whole
screen/tablet.
*Handle inter-application clipping of tablet contexts
*Allow all application's windows to receive tablet events when tablet
context is on top
3. Implement non-system tablet contexts (Where system cursor not moved
by pen or mouse)
4. Unicodify
5. Implement various wintab extensions.
6. Implement wintab manager functions.
7. Tests.
*********Unknowns*********
1. How are wintab contexts are raised lowered?
Contexts have their own z-order independent of windows, and their own
viewport concept, based upon the tablet's coordinate system, not that of
the OS.
It appears that entering, or clicking on the window the tablet context
is attached to will raise/lower the context.
But I haven't done much testing on this.
In particular, what happens if more than one app request their tablet
context is attached to the desktop?
2. How Painter detects the eraser.
Have 3 possibilities
i. Windows can detect an eraser, and sends specific messages.
(I'm sure I've seen this, but can't work out where!)
ii. Only works if tablet and cursors are named correctly.
(Probably linked to wacom tablets only).
iii. I've missed something
3. Requirements of other applications
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s
/ZKMUGwQOuw/SIIbOkIUbd0=
=R4M7
-----END PGP SIGNATURE-----
Hello,
recently i tried to install some application and it hung when i
tried to select options.
It uses listbox with ownerdraw items with checkboxes. When listbox
is initially painted everything is ok. But when i try to select other
item, an extra WM_PAINT is sent to listbox when application draws item.
This causes infinite recursion.
I've been implemented a simple workaround adding boolean to listbox
structure but i have doubts. I briefly looked at some other controls
and had not noticed similar countermeasures.
Have somebody ever seen such behaviour?
It would be interesting to test other controls sending WM_PAINT from
ownerdraw handler but i'm short of time to do it soon.
Should this workaround implemented in this way or something
is wrong deeper with WM_PAINT handling?
Thanks.
Hello,
I am getting the attached error when running an install of Overnet v0.52.
Basically it cannot find NdrGetUserMarshalInfo(), despite it being in
the dll at entry point: 77d43452h, order 199. Any ideas what this
problem could be? I'm expecting this to be the symptom of some wider
problem.
Any help appreciated.
Kind regards
JG
p.s. Is there any way to get these mangled function names to be
displayed un-mangled please?
c:\opt\overnet_0_52>overnet
c:\opt\overnet_0_52>err:module:import_dll No implementation for
MSVCRT.dll.??_U@YAPAXI@Z imported from
L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef
err:module:import_dll No implementation for MSVCRT.dll.??_V@YAXPAX@Z
imported from L"C:\\opt\\overnet_0_52\\MSVCIRT.dll", setting to 0xdeadbeef
--
Homepage: http://jguk.org/
Blog: http://jguk.org/index.html#blog
Radio: http://jguk.org/index.html#radio
Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom
is a hang with the CPU at 100%, and it happens immediately if you try to
click on a notes 'bookmark', or shortly after you try to do much of
anything else if you try to avoid the 'bookmarks'.
Sorry that it took me so long to report this, when I decided that it wasn't
just a temporary instability I eventually had to iteratively compile (many)
CVS snapshots to narrow down when the problem was introduced because I
found it impossible to untangle the various patches that went in around
that time frame. I also ran afoul of the jack problems near the end.
I do not know how to narrow the problem down further. I tried running
winedbg (at CVS level a couple of days ago), and that seems to be broken
too -- it wanted to run things from the wine build tree? There are no
unusual console messages or anything when the problem happens.
Thanks,
Paul
z/OS core components development
Internet: prs(a)us.ibm.com
On Wed, 2005-02-09 at 16:59, Paul Millar wrote:
> I haven't worked on any of winetest's innards, so this is largely
> guess work...
>
> On Wednesday 09 February 2005 13:22, you wrote:
> > If I run winetest-200502091000-paul-mingw manually on my win98 box
> > I get several messages "Can't parse subtests output of" for the
> > following tests [...]
> > just before the tests actually start.
>
> My guess is that winetest is attempting to run these tests, but that
> they are dying straight away, with some error message. This error
> message is not the expected output, hence the error messsage.
>
> [...]
> > Does this mean that we have a deeper lying problem?
>
> Yes, obviously! The tests are failing and we have no mechanism for
> detecting this. This, in itself, is a bug.
>
> > Or just that
> > more tests are somehow not correct (in combination with mingw)?
>
> I've bundled the individual tests in:
> http://www.astro.gla.ac.uk/users/paulm/WRT/winetest-bin-20050209.zip
> (its some 2.6MiB in size, though)
>
> I image you should be able to run the shlwapi test individually, which
> should help narrow down the cause.
>
> HTH,
>
> Paul.
Hi Paul,
I've included wine-devel again as this must touch others as well.
I wasn't able to run the shlwapi tests on my win98 box, by itself.
Running this gives an error box:
The SHLWAPI_.EXE file is
linked to missing export SHLWAPI.DLL:PathIsValidCharA
and just for completeness sake:
dsound:
...
linked to missing export DSOUND.DLL:DirectSoundCreate8
mlang:
...
linked to missing export NTDLL.DLL:atoi
msvcrtd:
A required .DLL, MSVCRTD.DLL, was not found
ole32:
...
linked to missing export NTDLL.DLL:atoi
Cheers,
Paul Vriens.
Hi,
The following patch:
ChangeSet ID: 15259
CVSROOT: /opt/cvs-commit
Module name: wine
Changes by: julliard(a)wine.codeweavers.com 2005/01/07 09:34:25
Modified files:
dlls/comctl32 : treeview.c
Log message:
Crestez Leonard <cleonard(a)go.ro>
Fix bug with Treeview_SelectItem reselecting the same item.
Patch: http://cvs.winehq.org/patch.py?id=15259
Old revision New revision Changes Path
1.160 1.161 +0 -3 wine/dlls/comctl32/treeview.c
Breaks Filezilla's (filezilla.sourceforge.net) add new site dialog. The
way to reproduce it is to go to the Site manager and click the "New
site" button. (Doesn't work even with latest CVS)
Without the check which the patch removes,
if (prevSelect == newSelect)
return FALSE;
The dialog goes to an infinite loop. (you can exit it if you just hold
the ESC-key down for long enough)
I have no idea whether the rationale Leonard provided with his patch is
correct, but it does break Filezilla.
The binary file for Filezilla can be gotten from:
http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_10_setup.exe?dow…
and the source file from:
http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_10_src.zip?downl…
I would appreciate it if some comctl32 messaging guru could step up and
take look at this problem
--
- Hannu Valtonen
Hannu.Valtonen(a)hut.fi
+358408030179
The Windows api method uses the function call IDvdInfo2::GetDiscID
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c…
This returns a unique 64bit ID for a DVD.
Has anyone found out what exactly it does to create this 64bit ID.
It would be nice to get linux DVD players to be able to use the same method.
Cheers
James
hello,
we are using winamp 2.95 with latest wine 0.0.20040914 and are wondering
what there is about these 'fixme:wave:OSS_AddRingMessage two fast
messages in the queue!!!!' messages dumped out at the console every few
seconds...
Same happens(but with 'ALSA_AddRingMessages' of course) if we're using
the wine alsa-driver.
Winamp normally works, but sometimes there is a 15sec pause at the
playback, so we are trying to search the problem.
I watched the wine source-code, but as my less C knowledge I didn't
really understand the part where this 'FIXME' message is implemented.
As I understand the code, why somebody added the 'FIXME' message to the
code, if the code can handle this problem(two fast messages)?
Or can somebody explain me the reason for this 'two fast messages'?
thanks a lot
seut
btw. I'm not a member of the mailing-list, so please send answer to me
too!
and please don't suggest us to use a native linux-player instead, for
some reasons, we have to use winamp..
Hi,
I'm the maintainer for World of Warcraft, and I've noticed a few things which have been pointed out before (on irc, bugzilla, mailing list) but have not really gotten any attention. As this is one of the most popular, if not THE most popular pc game at the moment, it seems as though it would be worthwhile to look into getting this to work if it does not require a complete rewrite of wine to do so.
There are currently two things preventing operation of the game. Firstly, I'll start off by saying that there are two separate modes to run the game in. d3d9, and opengl.
The d3d9 mode doesn't currently work since the support for this dll is not complete. I have been following it closely though, and I constantly find myself impressed with the amount of work being poured into it lately.
It's really coming along, and I've even gotten it to run a few demos. Unfortunately, even with the latest patches it still comes up with a blank screen. I don't want to rush anything in this department since I know there's a massive transition from the d3d* architecture to wine3d, and I think it's a really great idea to funnel everything through opengl and only need one rendering library.
It's hard for me to say as a WoW addict myself, but I would rather have a complete implementation of d3d9 than one that is only able to play WoW. So I guess what I'd like to say on this front is this: awesome work guys!
As for the opengl mode, it crashes strangely just after the character loading screen, but before actually getting into the game. I'm not really sure exactly what is causing the crash. I've run several traces, and all that comes up is a large group of fixmes which look like this:
fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads
fixme:thread:NtQueryInformationThread info class 9 not supported yet
The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this:
ERROR #0 (0x85100000)
Program: C:\Program Files\World of Warcraft\WoW.exe
File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp
Line: 1287
Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603
Nothing has happened yet with this bug except for someone else confirming it.
I'd appreciate it if someone could give me one of two pieces of information (both would be spectacular!):
1) What exactly is causing the problem with the opengl version, and is it easy to fix?
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things?
Thanks in advance,
Darckness
--
Stop searching forever. Happiness is unattainable.
"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote:
> With some help I'll be able to improve it (more unicodification, etc.)
> when I'll come back.
You can't really convert to unicode partially, you have to do it in one go.
That not only will simplify things a lot, but also will save you a lot of time.
> + for (i=0; i < numentries; i++)
> + {
> + len = WideCharToMultiByte(CP_UNIXCP, 0, entries[i].descr, -1, NULL, 0, NULL, NULL);
> + descr = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR));
> + WideCharToMultiByte(CP_UNIXCP, 0, entries[i].descr, -1, descr, len, NULL, NULL);
> + printf("%s|||%s\n", entries[i].key, descr);
There is no need to allocate len * sizeof(WCHAR) bytes, len works just fine.
> +int wmain(int argc, char *argv[])
wmain takes 'WCHAR *argv[]' list.
All remaining problems are caused by the fact that now argv[] array
is passed in unicode but you still handle argv[] strings as ASCII and
pass them around to internal functions which accept 'char *' not 'WCHAR *'
strings.
--
Dmitry.
