-----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.
Troy Rollo <wine(a)troy.rollo.name> writes:
> Activate by setting WINEDEBUG=relay,nrelay
>
> Alternatives considered but rejected:
>
> - Having a config file option. When the config file options are read it is
> already too late to prevent calls by and between kernel32.dll and
> ntdll.dll from being logged.
This option clearly belongs with the similar ones in the config file,
probably even as a special case of RelayFromExclude. The fact that it
doesn't work properly on startup is not a reason to invent a new
mechanism, the other config options don't work on startup either, and
this needs to be fixed.
--
Alexandre Julliard
julliard(a)winehq.org
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
In the bug found at http://bugs.winehq.org/show_bug.cgi?id=2096 , I have
described an issue that I am having with Quicken Deluxe 2000 when running
under Wine. The symptom is that Quicken was crashing HARD when trying to
print a partial page of checks on a laser printer. Now, I just get fixme's
stating that CreateCompatibleBitmap is getting bad parameters.
(In lieu of reading the following, you could probably just read the last few
posts in bugzilla for this bug...)
Long story short, with the help of some others (thanks guys!), it seems that
CreateCompatibleBitmap is being called directly from Quicken, and that
Quicken seems to be passing an address instead of a value for the height
parameter.
Now, I would normally just mark the bug as INVALID, and let it go. But, while
looking into things, I read the MSDN page describing the function of
CreateCompatibleBitmap, and it appears to me that there may be "issues" with
Wine's implementation of CreateCompatibleBitmap. To quote my post attached
to the bug:
"I would have changed this bug entry's resolution to INVALID, except that (a)
I wouldn't mind a more knowledgeable (of Wine, Win API, and C) person to
verify my findings, and, more importantly, (b) it seems to me that Windows
would be handling this scenario differently than Wine (or Intuit/Quicken
would have some customer relations problems due to frequent crashes) - should
Wine do something different when the parameters are out of whack? The only
thing I can see on MSDN under CreateCompatibleBitmap is "Windows 95/98/Me:
The created bitmap cannot exceed 16MB in size."
"Which I guess brings up another point... dlls/gdi/bitmap.c's
CreateCompatibleBitmap shows the aforementioned fixme message if the width or
height exceeds 0x10000, and no bitmap is returned. This seems wrong to me on
three counts: (1) MSDN states that if either width or height is zero, a 1x1
monochrome bitmap is returned (in my case the height was 0, but the width was
"huge", so a 1x1 bitmap should be returned); (2) a 0x11000 by 0x2 bitmap is
within the (more restrictive Win95) 16 MB limit and should be valid; and (3)
Win NT/2000/XP do not seem to have any restriction on a bitmap's size (except
physical and paged memory constraints), so at least in theory, any values for
width and height are "valid".
So, this begs the question, should Wine's CreateCompatibleBitmap be modified
for any (or all?) of the reasons above?
Thoughts? Comments?
Carl
2 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess()
always returns 1:
http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html
It was fixed by patch:
http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html
and I used the patched Wine-20030508 all the time to run MSVC,
OpenWatcom C, and Borland C in a command line.
However, when I try to run dmc.exe, sc.exe, or make.exe from
Digital Mars C/C++ Compiler, I always see the message:
wine: Unhandled exception (thread 0009), starting debugger...
I build Wine-20050310, but it has the same two problems:
1) GetExitCodeProcess() always returns 1 on FreeBSD 5.3,
2) and wine could not run Digital Mars C/C++ Compiler.
Digital Mars C/C++ Compiler is could be downloaded here:
http://www.digitalmars.com/download/freecompiler.html
Igor Sysoev
http://sysoev.ru/en/
Hi Jesse,
The failures you see are only whitespace changes.
Either make patch skip whitespace changes, or apply the following patch
to Olivier's patch prior to apply it to your tree.
Vincent
Kees Cook <kees(a)outflux.net> writes:
> ChangeLog:
> Black-box implementation of CryptProtectData/CryptUnprotectData
>
> This is a resend, since it looks like current patches are making their
> way into CVS now. :) It was reviewed last week by several people, and
> includes docs, tests, etc.
I don't understand while you come up with such an elaborate scheme of
storing things in the registry when it's clearly not the way this
thing is supposed to work. If you can't figure out what Windows does,
then just xoring the data with 0xdeadbeef or something like this would
be at least as secure as your solution, and would actually be much
closer to the proper behavior.
--
Alexandre Julliard
julliard(a)winehq.org
Hello,
Right now, each time I make a modification (even one line) I do a
'make' followed by a 'make install'.
Is there a faster way ?
Thanks
David Hemmo