Re: dlls/winmm/winealsa/midi.c: Bug in MIDI_CMD_BENDER fixed
On Tue, Jul 26, 2005 at 11:52:55PM +0200, Johannes Koch wrote: > The pitch value was wrongly converted and has to be centered around zero. > > Changelog >Fixed pitch bending in the alsa midi driver. > > ? patch.diff > Index: dlls/winmm/winealsa/midi.c > === > RCS file: /home/wine/wine/dlls/winmm/winealsa/midi.c,v > retrieving revision 1.16 > diff -u -p -r1.16 midi.c > --- dlls/winmm/winealsa/midi.c27 Apr 2005 09:39:56 - 1.16 > +++ dlls/winmm/winealsa/midi.c26 Jul 2005 21:31:05 - > @@ -833,7 +833,7 @@ static DWORD modData(WORD wDevID, DWORD > snd_seq_ev_set_controller(&event, evt&0x0F, d1, d2); > break; > case MIDI_CMD_BENDER: > - snd_seq_ev_set_pitchbend(&event, evt&0x0F, ((WORD)d1 << 7) | > (WORD)d2); > + snd_seq_ev_set_pitchbend(&event, evt&0x0F, ((WORD)d2 << 7 | > (WORD)d1) - 0x2000); This is not correct, you need extra ( ) around the << 7, like this perhaps: > + snd_seq_ev_set_pitchbend(&event, evt&0x0F, (((WORD)d2 << 7) | > (WORD)d1) - 0x2000); Ciao, Marcus
Re: Automatic ANSI<>Unicode message translation
On Wed, 27 Jul 2005 15:28, Dmitry Timoshkov wrote: > Take into account that threads can belong to different processes. Another > thing that we may want to take into account (that needs a test though) is > whether a thread locale affects the translation. Locale doesn't affect the A->W translation. I know that is counter-intuitive and it surprised me when I found out (and verified) this. The system dialogs where you can change these things tend to obscure this.
Re: Add ShellExecute() conformance tests
Saulius Krasuckas escreveu: * On Fri, 22 Jul 2005, Francois Gouget wrote: So the goal of this conformance test is to at least get things started and to test a few sticking points like putting quotes around the One test fails on my box: In my box it pass(1). | $ make -C dlls/shell32/tests/ test | make: Entering directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/shell32/tests' | ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlexec.c && touch shlexec.ok | shlexec.c:275: Test failed: ShellExecute(null, "C:\windows\temp\\test_shortcut_shlexec.lnk", null, null) failed: rc=31 err=0 | make: *** [shlexec.ok] Error 1 Any ideas? Do you have the dir "C:\windows\temp" (2)? (1) output of test: make -C dlls/shell32/tests/ test make: Entering directory `/home/mduarte/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shelllink.c && touch shelllink.ok ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shellpath.c && touch shellpath.ok fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlexec.c && touch shlexec.ok ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfolder.c && touch shlfolder.ok ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so string.c && touch string.ok make: Leaving directory `/home/mduarte/wine/dlls/shell32/tests' (2) existence of the directory: ll ~/c/windows/temp/ total 0
Re: Automatic ANSI<>Unicode message translation
"Troy Rollo" <[EMAIL PROTECTED]> wrote: > Locales don't affect the ANSI code page - that is determined either at boot > time or by the most recent call of the process to SetGlobalCP (NT only). I > could write a test for this, but I won't have time to do it until about a > week from now. Take into account that threads can belong to different processes. Another thing that we may want to take into account (that needs a test though) is whether a thread locale affects the translation. -- Dmitry.
Re: Automatic ANSI<>Unicode message translation
On Wed, 27 Jul 2005 13:20, Dmitry Timoshkov wrote: > "Troy Rollo" <[EMAIL PROTECTED]> wrote: > > This means that ideally, if the window is not a unicode window, then > > there should be no A->W->A translation. > > What is the source and target threads are running in different locales? > That's the point in conversion to unicode for the interthread PostMessage/ > SendMessage case. Locales don't affect the ANSI code page - that is determined either at boot time or by the most recent call of the process to SetGlobalCP (NT only). I could write a test for this, but I won't have time to do it until about a week from now.
Re: Add ShellExecute() conformance tests
* On Fri, 22 Jul 2005, Francois Gouget wrote: > > So the goal of this conformance test is to at least get things started > and to test a few sticking points like putting quotes around the One test fails on my box: | $ make -C dlls/shell32/tests/ test | make: Entering directory `/mnt/antras/usr/src/wine-cvs/wine/dlls/shell32/tests' | ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlexec.c && touch shlexec.ok | shlexec.c:275: Test failed: ShellExecute(null, "C:\windows\temp\\test_shortcut_shlexec.lnk", null, null) failed: rc=31 err=0 | make: *** [shlexec.ok] Error 1 Any ideas?
Re: Automatic ANSI<>Unicode message translation
"Troy Rollo" <[EMAIL PROTECTED]> wrote: > This means that ideally, if the window is not a unicode window, then there > should be no A->W->A translation. What is the source and target threads are running in different locales? That's the point in conversion to unicode for the interthread PostMessage/ SendMessage case. -- Dmitry.
Re: Benchmark's on the Wiki
On 7/26/05, Mitchell Mebane <[EMAIL PROTECTED]> wrote: > I'd be interested to see how 3DMark05 runs. Do Oliver's patches support it > yet? Back in April 3DMark05 would install and load but there was a lack of Pixel Shader 2.0 support, so none of the test would run. http://www.futuremark.com/products/3dmark05/?minreq A quick look at : http://directxwine.sourceforge.net/ "pixel shaders should be implemented in the next release or two depending on the amount of regression and other bugs that popup." Oliver would you have a ETA for Pixel Shader 2/3 ? Tom > > --Mitchell
Re: Benchmark's on the Wiki
Tom Wickline wrote: Hello, I put the Benchmark results that I posted to wine-devel back in April on the Wiki. http://wiki.winehq.org/BenchMark I would appreciate any constitutive criticism to improve this page. Tom . I'd be interested to see how 3DMark05 runs. Do Oliver's patches support it yet? --Mitchell -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
Re: Const Function Parameters?
On Wed, 27 Jul 2005 09:25, Felix Nawothnig wrote: > There is no need to make anything except the pointers const - I don't > think I've ever seen that in real world code. In theory this would give > the compiler slightly more information... but if the optimizer is unable > to figure out that the parameter is never used as an lvalue by himself > it sucks so badly that it probably won't do much better with that hints > anyway. :-) In fact I don't know that making these const would make any difference - I'd like to see the assembly code generated by the two versions for comparison. > Constifying the pointers is fine ofcourse (but rather because it helps > finding bugs than for those 1.5% performance improvements. The 1.5% appears to be within the noise. A few of us analysed those routines to death on IRC a couple of months back and decided the real problem was that they were being called too frequently, not that there was a problem with the routines themselves. The routines could probably be made faster by rewriting them in assembly language, but bigger benefits could be gained by figuring out why there are so many calls and reducing the number of calls.
Re: [wined3d] pbuffer support
> I expect this is caused by states not being in sync between the pbuffer and > old buffer, or > textures not being loaded properly... I've just sent in a patch that should > correct the latter. Re-tested HL2 today, pbuffer white screen regression is gone.
Re: Const Function Parameters?
Michael Carlson wrote: I've also found that marking a couple of parameters of that function const (that I believe should be marked const anyways), CPU usage in that function drops measurably with oprofile. As far as I know, parameters that aren't modified in a function should be marked const anyways, to send the right hint to the compiler. Since it actually turns out to be faster too, it seems worth it to me. -static void convert_5x5_asis(int width, int height, - const void* srcbits, int srclinebytes, - void* dstbits, int dstlinebytes) +static void convert_5x5_asis(const int width, const int height, + const void* srcbits, const int srclinebytes, + void* dstbits, const int dstlinebytes) There is no need to make anything except the pointers const - I don't think I've ever seen that in real world code. In theory this would give the compiler slightly more information... but if the optimizer is unable to figure out that the parameter is never used as an lvalue by himself it sucks so badly that it probably won't do much better with that hints anyway. :-) Constifying the pointers is fine ofcourse (but rather because it helps finding bugs than for those 1.5% performance improvements. Felix
Re: How to pass / convert file names?
Christian Britz wrote:
> Stefan Dösinger wrote:
>> I've also written a small C program which scans the registry and
>> creates .desktop files for each mime type found. I've sent a first alpha
>> version to this list late June. With these .desktop files in place you can
>> just click on the files in Konqueror or (I think so, but didn't test) the
>> Gnome Equivalent and they will open.
>
> This sounds interesting to me. I will be pleased to test your program
> with Nautilus (the Gnome equivalent to Konqueror). I will search for
> your submission on the ML archives, if you have a newer version please
> tell me how to get it.
Compiled and works fine with KDE (didn't have to change the directory
permission as you wrote).
I didn't figure out how to use these .desktop files with gnome but that
is not so important because you can easily adjust the mime type settings
manually ("open with" -> winestart in file properties).
Regards
Christian
Benchmark's on the Wiki
Hello, I put the Benchmark results that I posted to wine-devel back in April on the Wiki. http://wiki.winehq.org/BenchMark I would appreciate any constitutive criticism to improve this page. Tom
Re: Automatic ANSI<>Unicode message translation
On Tue, 26 Jul 2005 17:31, Dmitry Timoshkov wrote: > > What about the character codes which can't be converted? > > A->W conversion doesn't have that problem That is not necessarily true. A DBCS lead byte without a valid trail byte will result in failure in an A->W conversion. In fact translating from the 'A' version of WM_CHAR to the 'W' version is likely to be wrong. Compare WM_IME_CHAR to WM_CHAR: WM_IME_CHAR has wParam set to ((lead_byte << 8) | (trail_byte)) for DBCS characters. WM_CHAR receives DBCS characters as two WM_CHAR messages. This means that if you SendMessageA a DBCS lead byte, any conversion to a W window procedure would need to involve caching that byte and returning immediately, then performing the translation. On the other hand SendMessageA of any character to an A window procedure (regardless of any DBCS rules that might apply) ought to pass the character through immediately. This means that ideally, if the window is not a unicode window, then there should be no A->W->A translation. On the other hand perhaps Windows is doing some kind of caching, but if it is then it's doing something very strange. When I tested this I noticed an anomoly on Win2K - if I called PostMessageA(hWnd, WM_CHAR...) followed by PostMessageW(hWnd, WM_CHAR...), the character posted with PostMessageW arrived at the A window procedure first. I didn't bother to investigate why this happened.
Const Function Parameters?
I've been doing some oprofille tests with wine running fce ultra, the
8-bit Nintendo emulator. I found that when running a rom for 60
seconds, more than 99% of the CPU utilization for winex11drv (which
uses the most of all components of wine in this case) is in the same
function : convert_888_to_0888_asis (in dlls/x11drv/dib_convert.c).
I've also found that marking a couple of parameters of that function
const (that I believe should be marked const anyways), CPU usage in
that function drops measurably with oprofile. As far as I know,
parameters that aren't modified in a function should be marked const
anyways, to send the right hint to the compiler. Since it actually
turns out to be faster too, it seems worth it to me.
Here are the results from oprofile before the change:
2198299.2012 convert_888_to_0888_asis
2207899.1735 convert_888_to_0888_asis
2220799.1605 convert_888_to_0888_asis
2216199.1544 convert_888_to_0888_asis
2215899.2253 convert_888_to_0888_asis
and after:
2182899.1731 convert_888_to_0888_asis
2176999.2296 convert_888_to_0888_asis
2183599.3313 convert_888_to_0888_asis
2186899.1027 convert_888_to_0888_asis
2160199.1508 convert_888_to_0888_asis
On average, it went from 22117 (context switches I believe?) to 21780,
about a 1.5% improvement. The same test was run with a script each
time (run fceu with the same rom, kill it after 60 seconds). I'm
assuming the percentages (the second column in this chart) don't
matter much, because this function we're examining takes up an
overwhelming amount of the function's CPU (> 99%), so its percentage
depends largely on how many context switches other functions took up.
I've taken the liberty of providing a diff that patches all the
functions in this file to use const parameters where appropriate. I
don't get any compiler warnings with this compiling with gcc 4.0.1.
Should I submit this to wine-patches? This would be my first patch to
wine (or any open-source project, period). I'd appreciate some
feedback before I try for it.
Thanks in advance!
? patch.diff
Index: dlls/x11drv/dib_convert.c
===
RCS file: /home/wine/wine/dlls/x11drv/dib_convert.c,v
retrieving revision 1.3
diff -u -p -r1.3 dib_convert.c
--- dlls/x11drv/dib_convert.c 30 Nov 2004 21:38:58 - 1.3
+++ dlls/x11drv/dib_convert.c 26 Jul 2005 15:03:45 -
@@ -69,9 +69,9 @@
* 15 bit conversions
*/
-static void convert_5x5_asis(int width, int height,
- const void* srcbits, int srclinebytes,
- void* dstbits, int dstlinebytes)
+static void convert_5x5_asis(const int width, const int height,
+ const void* srcbits, const int srclinebytes,
+ void* dstbits, const int dstlinebytes)
{
int y;
@@ -83,9 +83,9 @@ static void convert_5x5_asis(int width,
}
-static void convert_555_reverse(int width, int height,
-const void* srcbits, int srclinebytes,
-void* dstbits, int dstlinebytes)
+static void convert_555_reverse(const int width, const int height,
+const void* srcbits, const int srclinebytes,
+void* dstbits, const int dstlinebytes)
{
const DWORD* srcpixel;
DWORD* dstpixel;
@@ -115,9 +115,9 @@ static void convert_555_reverse(int widt
}
}
-static void convert_555_to_565_asis(int width, int height,
-const void* srcbits, int srclinebytes,
-void* dstbits, int dstlinebytes)
+static void convert_555_to_565_asis(const int width, const int height,
+const void* srcbits, const int srclinebytes,
+void* dstbits, const int dstlinebytes)
{
const DWORD* srcpixel;
DWORD* dstpixel;
@@ -147,9 +147,9 @@ static void convert_555_to_565_asis(int
}
}
-static void convert_555_to_565_reverse(int width, int height,
- const void* srcbits, int srclinebytes,
- void* dstbits, int dstlinebytes)
+static void convert_555_to_565_reverse(const int width, const int height,
+ const void* srcbits, const int srclinebytes,
+ void* dstbits, const int dstlinebytes)
{
const DWORD* srcpixel;
DWORD* dstpixel;
@@ -181,9 +181,9 @@ static void convert_555_to_565_reverse(i
}
}
-static void convert_555_to_888_asis(int width, int height,
-const void* srcbits, int srclinebytes,
-void* dstbits, int dstlinebytes)
+static void convert_555_to_888_asis(const int width, const int height,
+const void* srcbits, const int srclinebytes,
+
Re: How to test a win16 application in our test-suite
Steven Edwards wrote: --- Paul Vriens <[EMAIL PROTECTED]> wrote: I'm busy fixing up version.dll, and I want to create some tests to read resources from win16 applications. I currently have a fixed .exe in my tests directory, but I'd like to create a 16bit .exe (or .dll) during the creation of the tests. OpenWatcom supports Win16 and Win32 apps and it works under Wine. Without a free 16bit compiler I don't see anyway to do it but perhaps we could make a project for Watcom and Winetests. Isn't OpenWatcom open source? Maybe SomeOne T.M. should make a winelib app out of OpenWatcom... :-P //Jakob
Re: cross-compiling for ARM
Hi John, --- John Connor <[EMAIL PROTECTED]> wrote: > Has anyone tried to cross-compile Wine for the ARM platform or is there > any documentation on how to do this? I have but its been a day or two. You need two trees and to first build the Wine tools for your host platform and something like the following cd /usr/src/wine-tools ./configure make tools then in another tree cd /usr/src/wine ./configure --build=armv4 --with-wine-tools=/usr/src/wine-tools Note there is no support for arm in Wineserver, kernel32 or ntdll so winelib won't run yet. Most everything else should compile as Winelib works on i386, PPC and SPARC. You might be able to get by stubbing the set_thread_context stuff out for simple apps. Thanks Steven __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
cross-compiling for ARM
Has anyone tried to cross-compile Wine for the ARM platform or is there any documentation on how to do this? This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Re: How to pass / convert file names?
Dear Stefan, Stefan Dösinger schrieb: > Try this script: > > #!/bin/bash > document=`winepath -l "$1"` > exec wine start.exe "$document" Marvellous! This is exactly the solution I need. :-) Maybe I should have been able to guess better what the "path" in winepath actually stands for... ;-) > If the word viewer installed the .doc file format in the wine registry you > can > call winestart /some/unix/path/file.doc and wine will start the asociated > application automatically. Yes, this works without any problems so far (using the Office 97 versions of the Word-, Excel- and PowerPoint viewers, they seem to be most compatible), even with Mozilla! I stored your little script under the name /usr/local/bin/winestart and selected that in the MIME options. Now it feels 100% native to click on the "FUD" documents on www.microsoft.com! ;-) > I've also written a small C program which scans the registry and > creates .desktop files for each mime type found. I've sent a first alpha > version to this list late June. With these .desktop files in place you can > just click on the files in Konqueror or (I think so, but didn't test) the > Gnome Equivalent and they will open. This sounds interesting to me. I will be pleased to test your program with Nautilus (the Gnome equivalent to Konqueror). I will search for your submission on the ML archives, if you have a newer version please tell me how to get it. > It's far away from beeing mature, but you can give it a try. I will! :^) > I don't think that these .desktop files directly, but theres a kstart program > which allows you to open any file KDE knows, and this works from literally > any application. I didn't get this sentence. Thank you very much, Christian
Adding a new include file (softpub.h)
Hi, for a patch to wintrust_main.c I need to define a GUID (WINTRUST_ACTION_GENERIC_VERIFY_V2). This GUID is present in softpub.h. The include file is not included in Wine right now. What are the 'rules' to add a new include file? Is it ok that have only this GUID in there ? Cheers, Paul. P.S. If somebody already has this one lying around, be my guest :-)
Re: commctrl: modularize progress drawing
From: "Felix Nawothnig" <[EMAIL PROTECTED]> > > It has become the norm lately to not have the ALLCAPS_ prefix > > for internal static functions, but rather have names_with_underscores > > to easily tell them apart from Win32 APIs. > > > > So for the above, I guess get_led_size() would be preferable. > > I thought the only half-official rule would be to keep the style > consistent with the rest of the file, which is just what Frank is doing > here since progress.c uses ALLCAPS_CamelCase everywhere? Correct. But in this case I think it's warranted as we add a lot more functions than the there exists. And besides, I initially wrote this control, and I think we're better off dropping the illy prefix :) > And actually I'd prefer ALLCAPS_CamcelCase over kernel_style since the > latter looks quite alien in Win32 code... and looking at wine-patches > from the last weeks it seems I'm not alone. :) This ALLCAPS prefix comes from a day long gone when we didn't have DLL separation. Now it just hurts the eye and it's distracting, without providing much benefit for internal functions. I think we're safe to assume that the prefered rule is: -- static functions don't have a prefix, and use the_undescode_names -- non-static ones keep the prefix, to avoid namespace polution. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: commctrl: modularize progress drawing
Dimi Paun wrote: It has become the norm lately to not have the ALLCAPS_ prefix for internal static functions, but rather have names_with_underscores to easily tell them apart from Win32 APIs. So for the above, I guess get_led_size() would be preferable. I thought the only half-official rule would be to keep the style consistent with the rest of the file, which is just what Frank is doing here since progress.c uses ALLCAPS_CamelCase everywhere? And actually I'd prefer ALLCAPS_CamcelCase over kernel_style since the latter looks quite alien in Win32 code... and looking at wine-patches from the last weeks it seems I'm not alone. :) Felix
Re: commctrl: modularize progress drawing
From: "Frank Richter" <[EMAIL PROTECTED]> > Frank Richter <[EMAIL PROTECTED]> > Split up the drawing code into a set of smaller functions and also moved > some common computations into helper functions. All that to facilitate > the implementation of the forthcoming theming support. > +static inline int PROGRESS_GetLedSize( PROGRESS_INFO *infoPtr, LONG style, It has become the norm lately to not have the ALLCAPS_ prefix for internal static functions, but rather have names_with_underscores to easily tell them apart from Win32 APIs. So for the above, I guess get_led_size() would be preferable. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: How to pass / convert file names?
> One solution would probably be to write a wrapper script that translates > the path name before it is passed to wine. One discussion board entry I > found indicates the CrossOver plugin does it that way. Try this script: #!/bin/bash document=`winepath -l "$1"` exec wine start.exe "$document" If the word viewer installed the .doc file format in the wine registry you can call winestart /some/unix/path/file.doc and wine will start the asociated application automatically. I've also written a small C program which scans the registry and creates .desktop files for each mime type found. I've sent a first alpha version to this list late June. With these .desktop files in place you can just click on the files in Konqueror or (I think so, but didn't test) the Gnome Equivalent and they will open. It's far away from beeing mature, but you can give it a try. I don't think that these .desktop files directly, but theres a kstart program which allows you to open any file KDE knows, and this works from literally any application. Stefan
How to pass / convert file names?
Hi, I discovered only recently a problem which is probably quite prevalent, but I could not find the answer on the web. Example: I want to configure Mozilla for opening .DOC files with the free Word Viewer that can be downloaded at http://www.microsoft.com. To do so I go to Edit -> Preferences -> Navigator -> "Helper Applications" and create a new MIME-Type "application/msword", extensions "doc dot" and tell the beast to open such files with /home/cbritz/.wine/drive_c/Programme/Microsoft Office/WORDVIEW.EXE (I have configured binfmt support, so I can call the EXE directly) Expected behaviour: The viewer program starts, opens the doc file and displays it. What happens: The viewer program starts and does not open any file. I must manually select Z:\tmp\Example.doc from the application. Next try from command line: .wine/drive_c/Programme/Microsoft\ Office/WORDVIEW.EXE /tmp/Example.doc - Again the doc file doesn't open. It DOES WORK when I manually translate the path name to: .wine/drive_c/Programme/Microsoft\ Office/WORDVIEW.EXE Z:\tmp\Example.doc first. I expected naively that wine automatically translates the Unix scheme to it's own convention but this doesn's seem to be true. Is it possible to instruct wine to translate the path string before it passes it to the windows binary? If not, is there a workaround to do that trick? One solution would probably be to write a wrapper script that translates the path name before it is passed to wine. One discussion board entry I found indicates the CrossOver plugin does it that way. I might even volunteer for trying to write a patch to wine if someone could tell me where to start to look at in the code ;) But probably the solution is already out there and I just don't see it. Any help would be much appreciated! Regards Christian
Re: [wintrust] Return TRUST_E_PROVIDER_UNKNOWN for WinVerifyTrust
On Mon, 25 Jul 2005 21:28:27 +0200, you wrote:
>
> Hi Rein,
>
> could you try the attached patch. It's a hack and we probably need an
> implementation of softpub.h. I just want to make sure Girotel doesn't
> use the same ActionID
Yes that works. Here is the Girotel's output:
| fixme:wintrust:WinVerifyTrust 0x
{64b9d180-8da2-11cf-8736-00aa00a485eb} 0x7ba7f2f0
(repeated 10 times or so.)
Rein.
Re: [wined3d] regression
--- Raphael <[EMAIL PROTECTED]> wrote: > On Monday 25 July 2005 19:47, Robert Shearman wrote: > > Oliver Stieber wrote: > > >Following this patch > > > http://www.winehq.org/hypermail/wine-patches/2005/07/0575.html wined3d > > > SegV's every time the dll is loaded. > > > > One bug is that GetModuleFileName is called with a buffer size of > > MAX_PATH, yet buffer is only 64 chars big. > > You are right i'm too stupid :( > (taking my brown paper bag...) > > But i'm interested to see how Oliver have the crash each times it use wined3d > (for me it doesn't crash) I get a segment fault after returning from the function, all I can assume is that the stack is getting corrupted by the buffer overrun, maybe mp path length is >64 and yours = <64? > > Regards, > Raphael > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: [wined3d] per app settings regression
--- Raphael <[EMAIL PROTECTED]> wrote: > On Monday 25 July 2005 20:41, Oliver Stieber wrote: > > Hi, > > This patch corrects a regression issue in > > http://www.winehq.org/hypermail/wine-patches/2005/07/0575.html > > > > Hi > > You just sent the sme patch :) > Maybe you forgot to attach the good one > It looks like a patch to correct the problem has been applied, I would change len = GetModuleFileNameA( 0, buffer, MAX_PATH ); to len = GetModuleFileNameA( 0, buffer, size ); to make things consistant. > Regards, > Raphael > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: Automatic ANSI<>Unicode message translation
"Phil Krylov" <[EMAIL PROTECTED]> wrote: Oh sorry. For some reason I thought that HIWORD(wParam) is used for some other data. Here is a new patch, is it ok? Looks good to me, let's see if Alexandre likes it as well. -- Dmitry.
Re: wine installation for Debian
Khe Siang Tan wrote: > Hi > > just wondering if someone could help mei am > running Debian operating systemand i am trying to > install/run WINE.i have typed the command $apt-get > install wine in root user. > > KHE:/home/zhe# apt-get install wine > Reading Package Lists... Done > Building Dependency Tree... Done > wine is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 0 not > upgraded. > > it seems to have installed but it has not appeared on > my programs listhow do i get it running > > i have also tried this command: > KHE:/home/zhe# dpkg -i wine_0.0.20030115-1.deb > dpkg: error processing wine_0.0.20030115-1.deb > (--install): > cannot access archive: No such file or directory > Errors were encountered while processing: > wine_0.0.20030115-1.deb > > how do i get WINE running > > thx > > > Cheers > K-Si > > Send instant messages to your online friends http://au.messenger.yahoo.com If you have a Windows executable called t.exe in the current directory then you just open a console and type "wine t.exe". If you also installed binfmt than you can also just run t.exe and it will use wine to run it. David
Re: objsel: Add stubs for objsel.dll and objsel.h
Thomas Weidenmueller <[EMAIL PROTECTED]> writes: > Thomas Weidenmueller wrote: > > The attached archive contains a stubbed objsel.dll and it's public > > header file objsel.h > > Any comments why it got rejected? I'd appreciate if you could send a proper patch instead of a zip file. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Automatic ANSI<>Unicode message translation
Hi Dmitry,
On Tue, 26 Jul 2005 16:56:31 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> The key word is "the whole" wparam. So, there is no need to truncate it
> by using LOWORD.
Oh sorry. For some reason I thought that HIWORD(wParam) is used for some
other data. Here is a new patch, is it ok?
> > > > AFAIK in DBCS two separate messages are used.
> > >
> > > A test under Windows would say it for sure.
> >
> > I can't test it as I don't have a Windows with DBCS locales installed,
>
> Just install one of such locales then, NT/2k/XP have built-in support
> for DBCS locales.
I'll try to find a distro that has. However, my 2000 and XP distros have an
installation option for CJK locales, but the needed files are not on the
installation CDs.
-- Ph.
Index: dlls/user/message.c
===
RCS file: /home/wine/wine/dlls/user/message.c,v
retrieving revision 1.86
diff -p -u -r1.86 message.c
--- dlls/user/message.c 19 Jul 2005 19:14:32 - 1.86
+++ dlls/user/message.c 26 Jul 2005 09:06:33 -
@@ -368,10 +368,12 @@ static WPARAM map_wparam_AtoW( UINT mess
case WM_SYSDEADCHAR:
case WM_MENUCHAR:
{
-char ch = LOWORD(wparam);
-WCHAR wch;
-MultiByteToWideChar(CP_ACP, 0, &ch, 1, &wch, 1);
-wparam = MAKEWPARAM( wch, HIWORD(wparam) );
+BYTE ch[2];
+WCHAR wch[2];
+ch[0] = (wparam & 0xFF);
+ch[1] = (wparam >> 8);
+MultiByteToWideChar(CP_ACP, 0, ch, 2, wch, 2);
+wparam = MAKEWPARAM(wch[0], wch[1]);
}
break;
case WM_IME_CHAR:
@@ -407,10 +409,12 @@ static WPARAM map_wparam_WtoA( UINT mess
case WM_SYSDEADCHAR:
case WM_MENUCHAR:
{
-WCHAR wch = LOWORD(wparam);
-BYTE ch;
-WideCharToMultiByte( CP_ACP, 0, &wch, 1, (LPSTR)&ch, 1, NULL, NULL );
-wparam = MAKEWPARAM( ch, HIWORD(wparam) );
+WCHAR wch[2];
+BYTE ch[2];
+wch[0] = LOWORD(wparam);
+wch[1] = HIWORD(wparam);
+WideCharToMultiByte( CP_ACP, 0, wch, 2, (LPSTR)ch, 2, NULL, NULL );
+wparam = MAKEWPARAM( ch[0] | (ch[1] << 8), 0 );
}
break;
case WM_IME_CHAR:
Windows API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone saw the article in June's Dr. Dobb's Journal, July 95 titled "Finding Binary Clones with Opstrings & Function Digests: Part I" by Andrew Schulman http://www.undoc.com Although just the first article, It already shows promise from wine's perspective. Generating hashes on the functions in the DLL's & EXE's while taking into consideration not to be fooled by the pointer diffs because of different positions in the binaries, Huge potential to find similar functions in all dll's instead of recoding them all. According to the article something Windows suffers from quite a bit... Just my 2c Tnx & Bi Bennie Kahler-Venter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC5fc7jrc/ZmvwnjARAgsyAJ9EGFZjvY+bvS4MuUJuS9IZ9WZ59ACgkAr1 ynML4cy/z/JKviK17RrwiOE= =TlTz -END PGP SIGNATURE-
Re: hhctrl: Add the WebBrowser implementation
"James Hawkins" <[EMAIL PROTECTED]> wrote:
> +#define HH_Alloc(size) ((LPVOID)HeapAlloc(GetProcessHeap(),
> HEAP_ZERO_MEMORY, size))
> +
> +#define HH_Free(buffer) \
> +if (buffer) \
> +HeapFree(GetProcessHeap(), 0, (HLOCAL)buffer);
Alot of work has been done to avoid tests for NULL before HeapFree
call, please do not introduce them again. Personally I don't see
the point of HH_Alloc and HH_Free macros at all.
> +#define HH_SafeRelease(x) \
> +if (x) \
> +{ \
> +x->lpVtbl->Release(x); \
> +x = NULL; \
> +}
Again, a direct access to a vtable. There is no much point in that
macro either, do that check directly instead and get rid of hhctrl.h
completely.
--
Dmitry.
Re: Automatic ANSI<>Unicode message translation
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
> > One solution is to translate the whole wparam.
>
> How do you see it? Example: I do a
>
> PostMessageA(hwndAnsi, WM_CHAR, 0xF301, 0);
>
> map_wparam_AtoW takes the "\x01\xF3" string, translates it to Unicode via
> CP_ACP (for CP1251, this would be probably {'\x01', 0x443})... and how
> does it fit this info back in LOWORD(wParam)?
The key word is "the whole" wparam. So, there is no need to truncate it
by using LOWORD.
> > > AFAIK in DBCS two separate messages are used.
> >
> > A test under Windows would say it for sure.
>
> I can't test it as I don't have a Windows with DBCS locales installed,
Just install one of such locales then, NT/2k/XP have built-in support
for DBCS locales.
> but
> Internet says:
>
> > When entering non-ASCII characters on systems with DBCS input
> locales, the lead byte and trail byte for the DBCS character are passed
> in two successive WM_CHAR messages. So we are better off processing
> WM_IME_CHAR messages because we get both bytes at once. If we move to
> Unicode, however, we'll directly get UTF-16 in WM_CHAR; or on XP: UTF-32
> in WM_UNICHAR.
Again, without a test we can't tell for sure what happens in reality.
--
Dmitry.
Re: bugs #3148 - Still in wine-20050725
Hi, On Mon, Jul 25, 2005 at 02:31:58PM -0700, Hiji wrote: > Can anyone help out with this bug? It's still in > existence in the July Wine release. OK, I've added a comment. Andreas Mohr
Re: Automatic ANSI<>Unicode message translation
On Tue, 26 Jul 2005 16:31:50 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> "Phil Krylov" <[EMAIL PROTECTED]> wrote:
>
> > > This patch is not correct. All messages which potentially go through
> > > wineserver
> > > should be posted/sent via unicode.
> >
> > OK, then how you would suggest to solve the problem described in previous
> > messages of this thread?
>
> One solution is to translate the whole wparam.
How do you see it? Example: I do a
PostMessageA(hwndAnsi, WM_CHAR, 0xF301, 0);
map_wparam_AtoW takes the "\x01\xF3" string, translates it to Unicode via
CP_ACP (for CP1251, this would be probably {'\x01', 0x443})... and how
does it fit this info back in LOWORD(wParam)?
> > AFAIK in DBCS two separate messages are used.
>
> A test under Windows would say it for sure.
I can't test it as I don't have a Windows with DBCS locales installed, but
Internet says:
> When entering non-ASCII characters on systems with DBCS input
locales, the lead byte and trail byte for the DBCS character are passed
in two successive WM_CHAR messages. So we are better off processing
WM_IME_CHAR messages because we get both bytes at once. If we move to
Unicode, however, we'll directly get UTF-16 in WM_CHAR; or on XP: UTF-32
in WM_UNICHAR.
-- Ph.
Re: Automatic ANSI<>Unicode message translation
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: > > What about the character codes which can't be converted? > > A->W conversion doesn't have that problem, A->W translation either if Of course the last A->W should be read as W->A, i.e.: "W->A translation either if ..." -- Dmitry.
Another AppDB screenshot problem...
Hi, Tonight I tried to submit a shot for Palm Desktop 4.1 and it gave me this error: Unable to move screenshot from to data/screenshots/originals/781 What's going on? Thanks a lot, James Liggett
Re: Automatic ANSI<>Unicode message translation
"Phil Krylov" <[EMAIL PROTECTED]> wrote: > > This patch is not correct. All messages which potentially go through > > wineserver > > should be posted/sent via unicode. > > OK, then how you would suggest to solve the problem described in previous > messages of this thread? One solution is to translate the whole wparam. > > Perhaps map_wparam_AtoW and map_wparam_WtoA > > should translate the whole wparam, i.e. both high and low bytes. > > What about the character codes which can't be converted? A->W conversion doesn't have that problem, A->W translation either if you use a valid source (i.e. the result of the A->W conversion). > > What does > > Windows do if the current locale is DBCS (Chinese/Japanese/Korean), does it > > translate the whole wparam in that case? > > AFAIK in DBCS two separate messages are used. A test under Windows would say it for sure. -- Dmitry.
Re: Automatic ANSI<>Unicode message translation
On Tue, 26 Jul 2005 16:04:22 +0900 "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: > This patch is not correct. All messages which potentially go through > wineserver > should be posted/sent via unicode. OK, then how you would suggest to solve the problem described in previous messages of this thread? > Perhaps map_wparam_AtoW and map_wparam_WtoA > should translate the whole wparam, i.e. both high and low bytes. What about the character codes which can't be converted? > What does > Windows do if the current locale is DBCS (Chinese/Japanese/Korean), does it > translate the whole wparam in that case? AFAIK in DBCS two separate messages are used. -- Ph.
Re: Automatic ANSI<>Unicode message translation
"Phil Krylov" <[EMAIL PROTECTED]> wrote: > Translate Unicode<->ANSI message wParams only when window type > (ANSI/Unicode) does not match message handling function postfix > (PeekMessageA/W etc.). This patch is not correct. All messages which potentially go through wineserver should be posted/sent via unicode. Perhaps map_wparam_AtoW and map_wparam_WtoA should translate the whole wparam, i.e. both high and low bytes. What does Windows do if the current locale is DBCS (Chinese/Japanese/Korean), does it translate the whole wparam in that case? -- Dmitry.
