August 2007 - Wine-Devel - list.winehq.org

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

Wine desktop integration: current directory of app launched with doubleclick?
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

4 9

Re: hhctrl.ocx: Parse HTML entities in the table of contents.
by Alexandre Julliard April 15, 2008

April 15, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > + p++; > + if ((*p == 'X') || (*p == 'x')) > + { > + /* hexadecimal entity */ > + while ((*p >= '0' && *p <= '9') || (*p >= 'a' && *p <= 'f') || > + (*p >= 'A' && *p <= 'F')) > + p++; > + ch = strtolW(start + 2, NULL, 16); > + } This is still broken. > + if (p - start - 1 <= sizeof(char_refs[0].name)) > + { > + for (i = 0; i < sizeof(char_refs)/sizeof(char_refs[0]); i++) > + if (!strncmpW(char_refs[i].name, start + 1, p - start - 1)) > + break; > + } This is still broken too. -- Alexandre Julliard julliard(a)winehq.org

2 1

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----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-----

2 1

Direct3D Game test framework
by Stefan Dösinger Dec. 21, 2007

Dec. 21, 2007

Hi, Now that we're facing Direct3D 9 feature completion soon - VTF support coming in from Henri, High order patches and thread safety from me - the d3d work will change a bit soon. Instead of adding new features we'll debug games and improve performance. It would be good if we had some automated testing framework to support the process :-) Unfortunately this isn't easy. Games do not render exactly, so verifying that a game doesn't show any visual regressions automatically may be more effort than reward. Here I think we'll have to rely on users testing the games regularly and testing regressions. I am more concerned about the performance thing. It is very easy to make some performance improvement that does more harm than good. Also benchmarks take quite some time and are affected by many external parameters. So I'd like some automated and controlled performance testing environment. Instead of building one from scratch it would be cool if we could reuse existing software. cxtest comes to my mind(www.cxtest.org). It is a test suit built by codeweavers for running regression tests on Windows apps. It can remote control applications using keyboard input and compares screenshots to reference ones. It could be used to start benchmarks automatically. A plus here is that some machines run nightly tests. However, those are VMs, so no 3D acceleration. A problem is also reading back the results. Does anyone know some applications for doing that? Windows or Linux apps, commercial or open source ones(prefered, though). Then we need benchmarking apps. Here regular Windows benchmarks come to my mind(3DMarkXYZW), games with benchmark facilities(hl2, ut, ...). We can record tests, get a reference performance counter from windows and run nightly tests(or manually started tests). A problem we're facing is reading back the results. Taking screenshots and running OCR on them is error prone, we need a way to get the numbers from the benchmarks, not an image of the numbers. Now we need a concrete collection of benchmarks. A mixture of popular Benchmarks like 3DMark would be good, and some more cientific benchmarks. So far I have: 3DMark: Popular benchmark for testing the overall performance, doesn't give very detailed results though. Controlling: Standard windows controls, keyboard events should do the job Result readback: Can write results to a file, but must take care about the licensing. Not everything is free, most likely a license is needed. Half-Life 2: Nice facility of recordable timedemos. Can record average game demos, but also demos which stress specific features. Controlling: Command line parameters Result readback: Can be asked to copy the console into the clipboard UT2004: Popular engine. Has a Linux port, but many mods only ship the d3d renderer. Controlling: Unknown Result readback: unknown. DirectX sdk demos, nvidia / ati demos: Stress specific rendering features. Good for testing performance(with vsync removed), or a bad idea? Controlling, Readback: Source code is available and can be modified. License, especially possible benchmark clauses? Other suggestions? Another nice-to-have thing would be a game independent profiling method, simmilar to the +fps debug channel, just more detailed. Some games do not have built-in benchmarking, it would still be nice to use them. That means facing some new problems? How to tell loading from in-game rendering? How to remove control those games in a repeatable way, especially if there are some random elements in the game? More detailed data from wined3d could also be used to draw nice graphs for other benchmarks :-) We'll need some hardware diversity too. It would be nice if the tests worked on Linux and MacOS, and a variety of hardware was used. I want at least nvidia, ati and intel gpu's, older and newer ones. I could also revive my ATI mach64 :-) Any other comments or suggestions? I think once I'm done with the current exam season and my patch backlog is in I will retire from direct wined3d development for a few days / weeks to set up a testing environment, then start fixing games.

10 40

Work legalities
by Nathan Williams Dec. 11, 2007

Dec. 11, 2007

Hey everyone, I have been planning to do some work on wine for a while now, but after I started working I got myself a new programming job. I'm worried about the copyright of any external work I do, so I need a little advice. What do I need from my employer to clear me to work on wine? Is something verbal ok, or should I get it in writing? -- Nathan

10 12

Will ROS and WINE still be steady be synchronized ?
by theUser BL Sept. 20, 2007

Sept. 20, 2007

Hi! I have also ask the question in a mail in the ROS-Mailinglist -- until now there comes now answer. http://www.reactos.org/archives/public/ros-dev/2007-August/009718.html Will ReactOS and WINE still be steady synchronized? ROS have for example an other Notepad.exe and an other Wordpad.exe The WineMINE have on ROS the colors of the original Windows WinMine. And the cards.dll have other cards. AT first it used the cards of http://nifty.stanford.edu/2004/EstellCardGame/ But after the comment of http://www.reactos.org/archives/public/ros-dev/2007-July/009625.html it used the cards at http://sourceforge.net/projects/macsolitairex WINE on the other side used since the beginning of its cards.dll the Microsoft copyrighted cards, which are also part of MS-Windows. So, for me it seems, that ROS and WINE goes two different ways since some time without syncronizing the source-codes, which can be used for both projects. Is that true? And if yes: Why? Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

4 4

AppDB entries
by speedator＠gmx.de Sept. 11, 2007

Sept. 11, 2007

Hi, sometimes app-entries (like Acrobat Reader) are for series of applications and versions for the single applications. Sometimes there are app-entries(like Age of Empires) for single applications in a series and version-entries for patches, betas, demos etc.. And sometimes it is a mixture. What about making this more clear? Do we need entries for the whole series? I think it is important for overview. So what about a new structure like "application / version / derived from version(subversion)"? Julian

3 2

Hmm. Cider and the LGPL
by Dan Kegel Sept. 3, 2007

Sept. 3, 2007

http://www.linux-community.de/story?storyid=23294 and http://www.macnews.de/news/102145.html mention that some users are using Cider from one game to run a second game on the Mac. The game vendors are upset, and are saying they'll do something to make that harder. There is some question about whether Cider includes LGPL components of Wine, and whether there are any violations lurking there. I imagine our friends at Cedega would instinctively avoid such infringement, but accidents might happen. It'll be interesting to see if anybody finds a real problem. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

6 7

Re: [5/5] WineD3D: texkill ignores the .w only in ps 1.x
by Tomas Carnecky Sept. 1, 2007

Sept. 1, 2007

+ + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0xff00ff00, 0.0, 0); + ok(hr == D3D_OK, "IDirect3DDevice9_CreatePixelShader returned %s\n", DXGetErrorString9(hr)); Is that worth changing? tom

2 1

Re: [4/5] WineD3D: Implement texldb
by H. Verbeet Aug. 31, 2007

Aug. 31, 2007

On 31/08/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Not as much a comment on this patch, but rather something I just thought of and I'll otherwise probably forget: our d3d9types.h doesn't contain definitions for D3DSI_TEXLD_PROJECT and D3DSI_TEXLD_BIAS, so we should add those.

1 0

Re: [2/5] WineD3D: Fix the z range
by Stefan Dösinger Aug. 31, 2007

Aug. 31, 2007

Am Freitag, 31. August 2007 17:20 schrieb Stefan Dösinger: Do not apply this patch yet, it breaks half life 2. There's something about the minZ and maxZ values in the viewport that we have to take into account.

1 1

Re: [3/5] WineD3D: Fix texdepth instruction
by Alexandre Julliard Aug. 31, 2007

Aug. 31, 2007

Stefan Dösinger <stefan(a)codeweavers.com> writes: > The DCT pixel shader test spotted a problem with texdepth. The test > included in this patch demonstrates texdepth's undocumented clamping > behavior, and > verifies the documented r5.r == 0.0 special case. This doesn't work for me: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:2281: Test failed: Pixel 158(25% - 2 pixel) has color 00ffffff, expected 0x000000ff visual.c:2303: Test failed: Pixel 318(50% - 2 pixel) has color 00ffff00, expected 0x000000ff visual.c:2344: Test failed: Pixel 318(50% - 2 pixel) has color 0000ff00, expected 0x000000ff make: *** [visual.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv[1/4]: wintab: restructure WTInfoA to dump a category by dumping field by field (resend)
by Alexandre Julliard Aug. 31, 2007

Aug. 31, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > I see that my patch to skip non-pressure-sensitive devices didn't > get it. I will try to look into it next week while now I'll resend the > Unicode patches that are easier. Here the first patch could be > controversial as I use a lot of macros. But that allows me not to use > long parameter lists. It's ugly. I don't see why you'd need long parameter lists at all, simply adding a current offset in CopyTabletData should be enough. Also, always going through all the cases even when a specific index is specified is not nice. And the winex11 function should always return Unicode, the A translation can be done in the generic code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Vacation
by Alexandre Julliard Aug. 31, 2007

Aug. 31, 2007

Hi folks, I'll be on vacation all of next week, so there won't be any commits. If you need to synchronize development with others in the meantime, I encourage you to create a tree on repo.or.cz. The 0.9.45 release will also be delayed by a week, so it will be on Sept 14th. Have fun while I'm gone... -- Alexandre Julliard julliard(a)winehq.org

1 0

RegDeleteTree and older versions of windows?
by Maarten Lankhorst Aug. 31, 2007

Aug. 31, 2007

Now that most functions get replaced with RegDeleteTree, I'm wondering if it is possible to link against that function statically for mingw/msvc dlls, so wine dlls can be still be used on win9x and windows nt and win2k. The problem is I don't know what the best solution would be to make sure the function makes it in, in case of mingw. I think it would be best to add it to include/wine/regdeltree.h and then include it from all dlls that need it, and probably from dlls/advapi32/registry.c as well, so code duplication is avoided. Something along the lines of: #if defined(__MINGW32__) || defined(__MSVC__) || defined(EXPORTREGDELTREE) (insert regdeltree functions here) #endif I'm open for suggestions though, since I really can't come up with any good ways to make sure wine dlls will keep working for older versions of windows. Cheers, Maarten

2 1

Re: winex11.drv: fix memory leak in create_cursor (found by Smatch)
by James Hawkins Aug. 31, 2007

Aug. 31, 2007

On 8/31/07, Lionel_Debroux <lionel_debroux(a)yahoo.fr> wrote: > create_cursor leaks some heap memory in an error path. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > I'm almost sure that the other potential memory leak detected by Smatch, > in the same function, is NOTABUG. Indeed, bitMask32 is conditionally > freed at line 850, if the number of bits per pixel (ptr->bBitsPerPixel) > is 32 - which is the condition which led to bitMask32 being allocated, > at line 639. > > 2007-08-31 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/winex11.drv/mouse.c: > winex11.drv: Fix memory leak in create_cursor (found by Smatch) > > >From d62a874a6d399546940a97fc3d800a692c08b362 Mon Sep 17 00:00:00 2001 > From: Lionel Debroux <lionel_debroux(a)yahoo.fr> > Date: Fri, 31 Aug 2007 08:16:36 +0200 > Subject: winex11.drv: fix memory leak in create_cursor (found by Smatch). > > --- > dlls/winex11.drv/mouse.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c > index 86dad89..d8bf30a 100644 > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -763,6 +763,8 @@ static Cursor create_cursor( Display *display, CURSORICONINFO *ptr ) > pixmapBits = XCreateBitmapFromData( display, root_window, (char *)pXorBits, xmax, ymax ); > if (!pixmapBits) > { > + if (bitMask32) > + HeapFree( GetProcessHeap(), 0, bitMask32 ); > XFreePixmap( display, pixmapAll ); > You shouldn't be checking bitMask32 for NULL before freeing it. -- James Hawkins

1 0

Re: crypt32(1/17): Greatly expand certificate chain tests
by Alexandre Julliard Aug. 31, 2007

Aug. 31, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > In case the big version doesn't get through in time, here's a gzipped version. It fails for me: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so chain.c && touch chain.ok chain.c:1187: Test failed: Chain 12: CertGetCertificateChain failed: 80092004 make[2]: *** [chain.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] WineD3D: Fix texdp3tex in glsl
by H. Verbeet Aug. 31, 2007

Aug. 31, 2007

On 30/08/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The preferred way to do that is to use shader_glsl_get_sample_function(). Also note that previously the docs just said "The result is used to sample the texture at texture stage m by performing a 1D lookup." The addition of using 0.0 to extend the vector is apparently recent.

2 2

Re: [PATCH] user32: edit control should respond to ctrl + z
by Dmitry Timoshkov Aug. 30, 2007

Aug. 30, 2007

"Lei Zhang" <thestig(a)google.com> wrote: > This lets users hit ctrl + z in edit dialogs. A test case is included. > This should fixed bug 9525. > + /* select all, cut (ctrl-x), undo (ctrl-z) */ > + SendMessage(hwEdit, EM_SETSEL, 0, -1); > + SendMessage(hwEdit, WM_CHAR, 24, 0); > + SendMessage(hwEdit, WM_CHAR, 26, 0); I'd suggest to add checks to make sure that every message you send above really worked. -- Dmitry.

2 1

Re: winex11.drv/wintab32[5/6]: implement WTInfoW
by John Klehm Aug. 30, 2007

Aug. 30, 2007

You forgot the patch. On 8/30/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > Now we allow to query the Unicode data > > >

1 0

Re: winex11.drv[2/6]: wintab: skip non-pressure-sensitive devices for wintab32
by John Klehm Aug. 30, 2007

Aug. 30, 2007

You forgot the patch. On 8/30/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > Another problem I had was that the laptop touchpad was detected as a > tablet. This may confuse Windows applications, as on Windows it isn't. > Also it confuses Wine because we support only one tablet - we assume > that each cursors have the same resolution. > > Is there a good way to select the correct devices as do we have to add > heuristics like the one in this patch? This patch ignored devices that > don't have the pressure axis. I assume that the WM_MOUSEDOWN gives > enough information so there is little loss that it can't be accessed > with wintab32. > > >

1 0

.NET support
by Jakob Eriksson Aug. 30, 2007

Aug. 30, 2007

Now that GDIplus is shaping up, is there a chance of implementing .forms support in mono with it? regards, Jakob

3 9

Fwd: Re: winmm: Change default driver order to be alsa, coreaudio, oss - try2
by Kuba Ober Aug. 30, 2007

Aug. 30, 2007

---------- Forwarded Message ---------- Subject: Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2 Date: Tuesday 21 August 2007 From: Kuba Ober <kuba(a)mareimbrium.org> To: wine-devel(a)winehq.org On Sunday 19 August 2007, Vitaliy Margolen wrote: > Maarten Lankhorst wrote: > > Forgot to remove the strlen check. > > Isn't this a bit premature? ALSA still does not support proper sound > capture, working mixer, and not stable enough on some configurations. In fact, for whatever it's worth, on some machines running either CentOS5 or FC6, for me alsa is completely broken (choppy sound output from linux alsa applications, etc). :( Cheers, Kuba -------------------------------------------------------

1 0

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 30, 2007

Aug. 30, 2007

On Thursday August 30 2007 07:03, you wrote: > Hello, > > I have corrected a patch. Now font in the menu and a font in winecfg > coincides. Your patch still doesn't work correctly. With 120 DPI setting font size in winecfg and notepad menu is different (menu' font is bigger; no so big as before but still bigger). As I have said, in Windows font size is the same in whole system if I change DPI setting and this is (correct) behavior of current WINE too. Please note that your patch behaves even worse at higher DPI resolutions. For example if I set: "LogPixels"=dword:00000096 ...In system.reg then menu font is of ridiculosly big size. In winecfg I have normal font size suitable for my display resolution. In fact, dword:00000096 setting this is what I use in both WINE and Windows (in Windows I can just use "Custom..." menu; in WINE winecfg isn't yet sophisticated enough). In short: if DPI setting changes then font size should change in linear fashion at the same rate for all fonts. Also please explain what exactly you are trying to fix with your patch (what application)? Are you sure that Windows behaves in the same way as you proposing? Test case probably would be nice thing. Sorry, but purpose of your patch is unclear to me. In your changelog field you tell that "This patch does a font for the menu, statusbar and messages dependent from logpixels" but as far as I know WINE already have correct behavior and respects the LogPixels value (it already sets correct size in menu, status bar and other GUI elements). This is why I'm asking you for an real-world example (with real-world application) of what you are trying to fix. P.S. Don't forget to reply to wine-devel so others can see the discussion.

3 4

Re: dsound: Disable thread calls and increase refcount in dllmain
by Dmitry Timoshkov Aug. 30, 2007

Aug. 30, 2007

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Seems native directsound keeps itself loaded by calling LoadLibrary when > attaching. A simple testcase I wrote confirms that at least for xp, by > not crashing. After seeing this, I decided to write my own test, and can confirm now that this patch looks correct: after a successful LoadLibrary("dsound.dll") FreeLibrary needs to be called 2 times before it starts to return FALSE. Just for fun I tested other dlls as well (GetModuleHandle returns 0 for all of them before the LoadLibrary call): user32 requires 4 FreeLibrary calls after LoadLibrary, dinput - 1, mfc42 - 1, advapi32 - 1, comctl32 - 1. I'm attaching the program I used for testing. > + GetModuleFileNameW(hInstDLL, modname, sizeof(modname)/sizeof(*modname)); > + LoadLibraryW(modname); Probably simple LoadLibrary("dsound.dll") should be enough. -- Dmitry.

3 2

Re: winex11.drv: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (2nd try, fixes bug #9262)
by Alexandre Julliard Aug. 30, 2007

Aug. 30, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > I'm not sure if I understood how it's supposed to look like. Is > something like this good? It adds an 'if' in the inner loop, but it's > an 'if' that is easy to predict and this version makes less memory > reads so maybe it will be better. You should put the if outside the loops, and keep the existing fast case with the memcpys and add a separate slower way for when alpha needs patching. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: getting started...
by Dan Kegel Aug. 30, 2007

Aug. 30, 2007

Ed wrote: >I'm brand new to the list and would like to get a Windows application that >I wrote (uCon) to work with wine/winelib. I've submitted it to the application >database. I've tried it on Wine and it *almost* works, so I'd like to pursue >this further by building uCon with Winelib (as is recommended somewhere >in the documentation). Egads. Where does it recommend that? Using winelib is a terrible idea unless you really need it (e.g. on non-x86 platforms, it's your only option). The downside is that your app suddenly becomes very fragile with respect to user updates of wine; they need a synchronized version of your app that matches their version of Wine. I've seen this happen, and it's not pretty. Also, this means double the QA and release trouble. The Right Thing To Do IMHO is just make your app and wine work better together, not use winelib. So your next move is to file bugs in http://bugs.winehq.org describing how your app doesn't work with wine, and work with us to solve them. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 7

Re: [2/5] WineD3D: Clear unused channels on R32F and R16F textures on readback
by H. Verbeet Aug. 29, 2007

Aug. 29, 2007

On 29/08/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can you even use those formats as render target on any cards?

2 1

Re: notepad: Add program icon
by Pedro Araújo Aug. 29, 2007

Aug. 29, 2007

On 8/27/07, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > notepad: Add program icon > > And now for the usual Wine oath: :) > I swear under pain of treason that the icon is my own work. > > .png attached if anyone wants to look at it. It's really not all that pretty. > > Alexander N. Sørnes I had this quick and dirty (okay, *very* dirty) mockup lying around for a while (not at all a very long while) and thought somebody might find some use for it... just in case. Ah, yeah, I too "swear under pain of treason" that I did it myself. :-) (I still have the original svg here if anyone wants it) - Pedro.

2 1

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 29, 2007

Aug. 29, 2007

On Wednesday August 29 2007 09:15, Ivan Sinitsin wrote: > Has corrected "logpixels=72" to " logpixels = 96 " and has changed the > indentation > > This patch adds an opportunity for fonts of the menu, statusbar and > messages to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. With your patch applied to current GIT head I have too large fonts in all menus even in notepad if for example I have set logpixels to 120 dpi using winecfg. "Too large" means MUCH larger than in, for example, winecfg itself (you need to restart the program to see the effect). See atached snapshot to see how notepad looks like with your patch if I set 120 dpi in winecfg. Font size is ridiculously big! For testing I have used clean WINE with your patch only and clean WINEPREFIX. In Windows and current WINE without your patch in clean WINEPREFIX all fonts are of same size no matter what DPI I set in LogPixels or winecfg and this is correct behavior. What application you are trying to fix?

1 0

Re: winex11.drv[2/2]: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (fixes bug #9262)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -1600,6 +1603,16 @@ #endif > for(; y >= y2; y--) { > memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > + if (!(blendfn.AlphaFormat & AC_SRC_ALPHA)) > + { > + int i; > + RGBQUAD *quad = (RGBQUAD *)dstbits; > + for (i = 0; i < widthSrc; i++) > + { > + quad->rgbReserved = blendfn.SourceConstantAlpha; > + quad++; > + } > + } It would be nicer to have a separate loop for that case, and do everything in one go instead of patching up the values after the copy. Also RGBQUAD is meant for color tables, it's not an appropriate type for the bitmap data itself. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (3rd try, with testcase, fixes bug #9195)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > Is there something wrong with this patch? You should use IntersectClipRect or ExtSelectClipRgn to avoid intermediate copies. Also GetClipRgn doesn't return a region code so checking it against NULLREGION is wrong. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: patch for sysparam.c
by Paul Vriens Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. > > > ------------------------------------------------------------------------ > > With the latest release winecfg can set this value. The default there is 96 and the range is 96..120. How does that relate to the 72 in your code? : +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) + logpixels=72; Cheers, Paul.

1 0

Re: patch for sysparam.c
by Robert Shearman Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > +size=sizeof(DWORD); > +RegOpenKeyExW( HKEY_LOCAL_MACHINE, registry_key, > + 0, KEY_QUERY_VALUE, &myhKey ); > +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, > + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) > + logpixels=72; > +ncm.lfMenuFont.lfHeight=-MulDiv(ncm.lfMenuFont.lfHeight,logpixels,72); > +RegCloseKey( myhKey ); You're missing some indentation here. -- Rob Shearman

1 0

Re: [PATCH] Support for animated cursors
by H. Verbeet Aug. 28, 2007

Aug. 28, 2007

On 28/08/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > On 8/28/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > You should use the timing and frame sequence info from the .ani. > > Also, Xcursor actually supports proper animated cursors, so it would > > be better to handle the animation in winex11.drv > > Can you please direct me to some example code of defining and using an > animated cursor with Xcursor? > http://repo.or.cz/w/wine/hacks.git?a=blob;f=dlls/winex11.drv/mouse.c;h=b344… should be a decent start. > > As explained in the comment at the top of cursoricon.c, you can't do > > that, because it will break win16 applications. > > Umm.. what comment would that be? This one: > * Cursors and icons are stored in a global heap block, with the > * following layout: > * > * CURSORICONINFO info; > * BYTE[] ANDbits; > * BYTE[] XORbits; > * > * The bits structures are in the format of a device-dependent bitmap. > * > * This layout is very sub-optimal, as the bitmap bits are stored in > * the X client instead of in the server like other bitmaps; however, > * some programs (notably Paint Brush) expect to be able to manipulate > * the bits directly :-( > Should I replace hNext with a CURSORICONINFO *? This is what I had > initially.. or should I be using something else? Or should I just > make it an BYTE bFrames and append multiple data blocks to the end of > the CURSORICONINFO struct? > Well, what it comes down to is that you can't change the cursor memory layout for win16 applications at all, which complicates things a bit.

3 12

[PATCH] the function called is cdecl, not WINAPI
by Juan Lang Aug. 28, 2007

Aug. 28, 2007

Hi Marcus, > the function called is cdecl, not WINAPI No it isn't. It's declared that way, but it's wrong. Calling it that way in Windows crashes. That's why I sent this patch: http://www.winehq.org/pipermail/wine-cvs/2007-August/035682.html --Juan

2 2

Re: winex11.drv: test for out-of-bound src coordinates in GdiAlphaBlend (fixed, with testcase, fixes bug #7428)
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > The previous version didn't take into account that dib.dsBmih.biHeight > can be negative. You should check for negative widthSrc/heightSrc too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: tests: some values of _mbctype are dependent on the version of Windows
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -144,10 +144,18 @@ static int result_cp_949_mbctype[] = { 0 > static int result_cp_950_mbctype[] = { 0x0,65, 0x8,1, 0x18,26, 0x8,6, 0x28,26, 0x8,4, > 0x0,2, 0x4,32, 0xc,94, 0,1 }; > > +/* these characters may differ on different Windows versions */ > +static int fuzzy_cp_1252_mbctype[] = {142, 158, 170, 181, 186, -2}; > +static int fuzzy_cp_1250_mbctype[] = {131, 141, 142, 143, 157, 158, 159, 163, 165, 170, 175, 179, 181, 185, 186, 188, 190, 191, -2}; > +static int fuzzy_cp_932_mbctype[] = { -2 }; > +static int fuzzy_cp_936_mbctype[] = { -2 }; > +static int fuzzy_cp_949_mbctype[] = { -2 }; > +static int fuzzy_cp_950_mbctype[] = { -2 }; What this shows is that the exact values don't matter, and that apps are very unlikely to depend on them. This also means that having slightly different tables in Wine is not a problem, so I'd suggest to not try to test every single char, but just pick a few that are the same on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

Old versions of Photoshop Elements tryout?
by Dan Kegel Aug. 27, 2007

Aug. 27, 2007

Hi all, I have a copy of Photoshop Elements 1.0, and can easily download a tryout of Photoshop Elements 5, but I don't know where to get trial versions of 2 through 4. Anyone know? Thanks, Dan

2 3

Re: 0001-Basic-starting-point-for-implementing-d3dx9_yz.dll.patch
by Detlef Riekenberg Aug. 27, 2007

Aug. 27, 2007

On Mo, 2007-08-27 at 14:13 +0200, Martijn Berger wrote: > > --- > .gitignore | 1 + > Makefile.in | 1 + > configure.ac | 1 + > dlls/Makefile.in | 1 + > dlls/d3dx9/Makefile.in | 15 +++++++++++++++ > 5 files changed, 19 insertions(+), 0 deletions(-) > --- /dev/null > +++ b/dlls/d3dx9/Makefile.in > @@ -0,0 +1,15 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +MODULE = d3dx9.dll > +IMPORTS = wined3d kernel32 > + > +C_SRCS = \ > + d3dx9_main.c > + > +RC_SRCS = version.rc This will not work: Your Makefile.in referenced "version.rc" and "d3dx9_main.c", but this files are missing in this Patch. You should never autogenerated modifications in any Patch: http://wiki.winehq.org/Developers-Hints#head-30a7f7f51ce0e42b4141749c9832ba… -- By by ... Detlef

1 0

DIB Driver code available
by Jesse Allen Aug. 27, 2007

Aug. 27, 2007

Hi, I have my DIB driver code available on a public git host now: http://repo.or.cz/w/wine/dibdrv.git I'm going to briefly describe it. The dib driver (or engine) is a gdi driver. It is loaded into a dc when an application selects a dib, and overrides the existing driver. The magic takes place in SelectBitmap. Safe interaction is provided in gdi32 in four patches. If the winedib.drv.so library is available, then gdi will use the dib driver for drawing into the selected dib. If winedib.drv.so is not available, then gdi will continue using winex11 for example just as before. So these four patches can be safely integrated with the main tree if that is decided to be done. The rest of the code is the driver itself. It can handle all the standard uncompressed dib formats. It can convert between formats, and it can Get/SetDIBits/Blt. Get/SetPixel is implemented too. No other drawing code is done yet, so only simple GDI apps work. I've tested several apps and I'll list my results. notepad -- no regressions found winefile -- visual artifacts, but usable bmp loading -- works fine for what has been tested pixel setting -- works fine for every supported format opengl app -- Tribes 1 -- no regressions found d3d app -- Star Wars Battlefront -- no regressions found ddraw app -- Diablo shareware -- no regressions found ddraw app -- Diablo prerelease -- discovered one visual artifact These are the deficiencies in current code (non-stubs): No RLE support Missing raster operations in *Blt Get/SetDIBits does not conform exactly yet Bottom-up DIB's not tested for (and probably broken) DIB_PAL_COLORS not tested for No stretching No forwarding calls back to original driver* *For forwarding back the calls, what I think can be done is use the hbitmap handle originally given, convert it to a DDB, select it, and make the same gdi call again which will then go to the actual device. I do probably need to make sure the dibdrv's physdev persists and doesn't get deleted during this ;) (probably something in Create/Delete DC) Performance Originally I was going to state not to expect there really to be any performance improvements. I feel that there are optimizations possible that I have not done, but I left room for. My first concern was correct pixel by pixel operation. So I thought not to expect anything but last night I discovered this, so I might as well share. I have written a program that performs Get/SetPixel to test the various formats. There are 13 total tests, and the program produces 52 MB of output. Just for fun I ran my program without the dib driver and found it took a very long time (I was thinking it hung up at first since it took so long!): timed with winex11.drv real 0m53.903s user 0m19.807s sys 0m5.869s So I tried it with my driver: timed with winedib.drv real 0m3.924s user 0m3.537s sys 0m0.191s Indeed, my tests show that there is a 50 second difference with GDI Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Still, I wouldn't expect *your* app to seem much different (or work at all :P) So will all the interested parties take a look at the driver and I'd sure appreciate feedback on the direction this is going, so we move towards finishing this project beyond the summer of code. :) Jesse

3 7

Re: 0002-Basic-d3dx9-stub.patch
by H. Verbeet Aug. 27, 2007

Aug. 27, 2007

On 27/08/07, Martijn Berger <martijn.berger(a)gmail.com> wrote: > +WINE_DEFAULT_DEBUG_CHANNEL(d3d10); That's not a good idea. Also, since the dll isn't actually called d3dx9.dll, how do you intend to handle the different versions? (Arguably these dlls are outside Wine's scope, since they're not installed as part of the OS, and should be installed by the application that is using them.)

2 1

getting started...
by Ed Sutter Aug. 27, 2007

Aug. 27, 2007

Hi, I'm brand new to the list and would like to get a Windows application that I wrote (uCon) to work with wine/winelib. I've submitted it to the application database. I've tried it on Wine and it *almost* works, so I'd like to pursue this further by building uCon with Winelib (as is recommended somewhere in the documentation). That being said, I'm a bit confused... The winelib users guide mentions "winemaker", but doesn't point to where I get it. It doesn't appear to come with the Wine package (as expected); however, aside from the entire Wine source tree, I don't see anything else to download. Do I need/want the entire Wine source tree if my next step is to attempt to build my application using Winelib? Thanks in advance Ed BTW... I'm going to be doing this on a RH9 linux box.

2 3

[PATCH] Support for animated cursors
by Trent Waddington Aug. 27, 2007

Aug. 27, 2007

Test program at: http://rtfm.insomnia.org/~qg/animatedcursor.exe Probably doesn't support all the possible animated cursors supported under windows, and correct timing of animation hasn't been attempted. Trent

3 2

Re: wintrust(4/5): Test and implement SoftpubLoadMessage (with patch)
by Alexandre Julliard Aug. 27, 2007

Aug. 27, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > + ret = data->pPDSip->pSip->pfGet(data->pPDSip->psSipSubjectInfo, > + &data->dwEncoding, 0, &size, buf); > + if (ret) > + { > + data->hMsg = CryptMsgOpenToDecode(data->dwEncoding, 0, 0, data->hProv, > + NULL, NULL); > + if (data->hMsg) > + ret = CryptMsgUpdate(data->hMsg, buf, size, TRUE); > + } > + > + if (!ret || !data->hMsg) > + err = GetLastError(); > + data->psPfns->pfnFree(buf); > + return err; That style of coding is dangerous, it assumes that all the error paths of the called functions will set last error properly. It's better to return a success/failure boolean and fetch the last error only when the actual error is needed, not as an error indication. -- Alexandre Julliard julliard(a)winehq.org

1 0

[git] Playing with gitstat (can we change date for the tags?)
by Paul Vriens Aug. 27, 2007

Aug. 27, 2007

Hi, I was just playing with gitstat (http://tree.celinuxforum.org/gitstat/) to see if it give some nice graphs for Wine as well (on my local box). I can see all the tags but for some reason a lot of tags (from wine-0.0.2 to wine-0.7 and after that wine-940201 to wine-980927, so basically every tag before Alexandre's "Initial revision") have nearly the same tagger/author date (around November 30th 2005). This messes up the ordering of the tags. Is there something I can do about this? (man git-tag tells me one shouldn't change tags afterwards). (I've changed the necessary perl-script to only include the tags that are correct so I do have some output). -- Cheers, Paul.

2 1

Re: Imm32: Update position of default IME window
by Alexandre Julliard Aug. 27, 2007

Aug. 27, 2007

Aric Stewart <aric(a)codeweavers.com> writes: > + > + /* make sure we are on the desktop */ > + GetClientRect(GetDesktopWindow(),&desk_rect); You have to use GetMonitorInfo to support multi-monitor setups correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [patch] Garbage code in text string display
by Guan Xin Aug. 27, 2007

Aug. 27, 2007

On 8/23/07, Juan Lang <juan.lang(a)gmail.com> wrote: > You may generally post source to wine-devel if it's short and to the > point. Please don't post a binary. Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests. > Right to the first point, which is why we write tests that pass on > Windows, and fix Wine to match the tests. This obviates the need to > look at Windows source. You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition. Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.

2 2

[wiki] Useful Registry Keys
by Paul Vriens Aug. 27, 2007

Aug. 27, 2007

Hi, Is "Useful Registry Keys" to show what's in current GIT or should it also help with older versions of Wine? I'm asking because "LogPixels" is currently handled by winecfg and thus could be removed if the page only shows the latest and greatest. Cheers, Paul.

1 0

Re: cabinet: Add initial tests for FDI
by Paul Vriens Aug. 27, 2007

Aug. 27, 2007

James Hawkins wrote: > Hi, > > Changelog: > * Add initial tests for FDI. > > dlls/cabinet/tests/Makefile.in | 3 +- > dlls/cabinet/tests/fdi.c | 578 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 580 insertions(+), 1 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi James, Am I correct that you're not deleting the "dest" directory? + CreateDirectoryA("dest", NULL); +} + +static void delete_test_files(void) +{ + DeleteFileA("a.txt"); + DeleteFileA("b.txt"); + DeleteFileA("testdir\\c.txt"); + DeleteFileA("testdir\\d.txt"); + RemoveDirectoryA("testdir"); + + DeleteFileA("extract.cab"); +} (Is "dest" used at all?) -- Cheers, Paul.

1 0

Re: wine.inf: add Internet Explorer AppPath registry key
by James Hawkins Aug. 26, 2007

Aug. 26, 2007

On 8/24/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > If I remember correctly some MSIE registry keys are not put into > Wine registry because that would prevent users from installing the > original MSIE. Does the AppPath key falls into the same category or > can it be included in Wine? > Why don't you try it yourself and see if it works? -- James Hawkins

2 1

[PATCH] Implement ImmReleaseContext.
by Trent Waddington Aug. 26, 2007

Aug. 26, 2007

Ugly stub warning replaced with intuitive implementation. Trent

1 0

Call for Testers: Dreamweaver on Wine
by Dan Kegel Aug. 26, 2007

Aug. 26, 2007

Last I checked, Dreamweaver 8 starts and seems to run reasonably well under Wine. But I'm no Dreamweaver user, and I don't have time to do much QA on it myself, so I'm sure I'm missing a lot of problems. Could somebody test it and/or comb through the appdb comments, usenet posts, blog entries, and whatnot about Dreamweaver, and start filing bugs? Can't fix 'em if we don't know about 'em! Thanks, Dan

3 3

Re: dinput: Count should not be 0-based.
by Vitaliy Margolen Aug. 25, 2007

Aug. 25, 2007

Paul Vriens wrote: > Vitaliy Margolen wrote: >> Fixes bug 9439. >> --- >> dlls/dinput/joystick_linux.c | 7 ++++--- >> 1 files changed, 4 insertions(+), 3 deletions(-) >> >> >> ------------------------------------------------------------------------ >> >> > Hi Vitaliy, > > doesn't this patch leave it 0-based? > > if (joystick_devices_count != -1) return joystick_devices_count; > > + joystick_devices_count = 0; > for (i = 0; i < MAX_JOYSTICKS; i++) > { > CHAR device_name[MAX_PATH], *str; > @@ -154,7 +155,7 @@ static INT find_joystick_devices(void) > if (!(str = HeapAlloc(GetProcessHeap(), 0, len))) break; > memcpy(str, device_name, len); > > - joystick_devices[++joystick_devices_count] = str; > + joystick_devices[joystick_devices_count++] = str; > } > > AFAIK this doesn't change anything. Before it was: > > joystick_devices_count = -1 > ++joystick_devices_count -> 0 (for the first entry) > > now: > > joystick_devices_count = 0 > joystick_devices_count++ -> 0 (for the first entry) > I didn't say "index", I said "count" <g>. Count should never be "0-based" as in "0" means "count of one". Index should be 0-based, as in "0" means first. If the count is -1 then it haven't been initialized yet. If it's 0, then there are no devices found. 1+ one or more devices have been found. Where it does mater is in joydev_create_device[A|W], where I assumed that count was 1 based. Vitaliy.

1 0

Regression caused by EM_LIMITTEXT
by Kopfgeldjaeger Aug. 25, 2007

Aug. 25, 2007

Hi, I am daily using wine with Miranda. The AppDB rates it as garbage, which is true for all versions (including .44) since 0.9.29 because of this patch: http://source.winehq.org/git/wine.git/?a=commit;h=dbcf2e391c684e8e364e29993… It let's Miranda crash the first time when you press enter to send a message. Attached is a log with wine 0.9.44 and Miranda 0.7 alpha #35 Miranda works fine with the newest wine if you revert the patch. Greetings, KGJ PS: Thanks a lot for the cursor position patch, it really helps to see where you are typing ;) Warning: could not find DOS drive for current working directory '/home/florian', starting in the Windows directory. fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\Programme\\Miranda IM\\Plugins\\advaimg.dll") not found fixme:thread:NtQueryInformationThread info class 9 not supported yet err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\Programme\\Miranda IM\\Plugins\\irc.dll") not found fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:richedit:RichEditWndProc_common EM_GETLANGOPTIONS: stub fixme:richedit:RichEditWndProc_common EM_SETLANGOPTIONS: stub fixme:thread:NtQueryInformationThread info class 9 not supported yet wine: Unhandled page fault on write access to 0x008cfffc at address 0xb7d5859d (thread 0009), starting debugger... Unhandled exception: page fault on write access to 0x008cfffc in 32-bit code (0xb7d5859d). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b7d5859d ESP:003362f8 EBP:00336318 EFLAGS:00210602( - 00 - RDI1) EAX:0059eb24 EBX:7dcb791c ECX:3fffeb68 EDX:008d5248 ESI:003314d8 EDI:008cfffc Stack dump: 0x003362f8: ffffffff 7dca50c9 008d5260 0033673c 0x00336308: fffffffc 7dcb791c 008d51e8 008d3158 0x00336318: 00336348 7dca4051 0033673c fffffffe 0x00336328: 00000000 7dca2cf4 008d2fe0 00000000 0x00336338: 00336358 7dcb791c 008d2860 00000000 0x00336348: 00336378 7dc903ae 008d2860 008d3158 Backtrace: =>1 0xb7d5859d memmove+0x4d() in libc.so.6 (0x00336318) 2 0x7dca4051 ME_InsertRunAtCursor+0x71(editor=0x8d2860, cursor=<register EDI not in topmost frame>, style=0x8d4fc0, str=0x33673c, len=0xfffffffe, flags=0x0) [/home/florian/wine-0.9.44/dlls/riched20/run.c:418] in riched20 (0x00336348) 3 0x7dc903ae ME_InternalInsertTextFromCursor+0x4e(editor=<register ESI not in topmost frame>, nCursor=<is not available>, str=<is not available>, len=0xfffffffe, style=0x8d4fc0, flags=0x0) [/home/florian/wine-0.9.44/dlls/riched20/caret.c:394] in riched20 (0x00336378) 4 0x7dc920b8 ME_InsertTextFromCursor+0x178(editor=0x8d2860, nCursor=0x0, str=0x33673c, len=0x1, style=0x8d4fc0) [/home/florian/wine-0.9.44/dlls/riched20/caret.c:515] in riched20 (0x003363c8) 5 0x7dc9df79 RTFFlushUnicodeOutputBuffer+0x49(info=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/riched20/reader.c:2659] in riched20 (0x003363f8) 6 0x7dc9519d ME_RTFReadHook+0x27d(info=<register EDI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/riched20/editor.c:420] in riched20 (0x003364e8) 7 0x7dc9eb08 RTFGetToken+0x38(info=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/riched20/reader.c:432] in riched20 (0x00336508) 8 0x7dc9ec88 RTFRead+0x28(info=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/riched20/reader.c:345] in riched20 (0x00336528) 9 0x7dc94ec2 ME_StreamIn+0x5e2(editor=0x8d2860, format=<is not available>, stream=<is not available>) [/home/florian/wine-0.9.44/dlls/riched20/editor.c:678] in riched20 (0x0033c6f8) 10 0x7dc973e6 RichEditWndProc_common+0x1416(hWnd=0x10044, msg=<register EDI not in topmost frame>, wParam=0x8002, lParam=0x33da50, unicode=0x0) [/home/florian/wine-0.9.44/dlls/riched20/editor.c:1465] in riched20 (0x0033d048) 11 0x7dc9a1b0 RichEditWndProcA+0x20(hWnd=0x10044, msg=0x449, wParam=0x8002, lParam=0x33da50) [/home/florian/wine-0.9.44/dlls/riched20/editor.c:2657] in riched20 (0x0033d058) 12 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033d088) 13 0x7e9bbb8b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x449, wp=0x8002, lp=0x33da50, result=0x33d7a8, arg=0x7dc9a190) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:468] in user32 (0x0033d0c8) 14 0x7e9bfd51 WINPROC_CallProcWtoA+0x181(callback=0x7e9bbb20, hwnd=0x10044, msg=0x449, wParam=0x8002, lParam=0x33da50, result=0x33d7a8, arg=0x7dc9a190) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:1285] in user32 (0x0033d778) 15 0x7e9c0e2f CallWindowProcW+0x13f(func=<register ESI not in topmost frame>, hwnd=0x10044, msg=0x449, wParam=0x8002, lParam=0x33da50) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2331] in user32 (0x0033d7b8) 16 0x129ca83b in srmm (+0xa83b) (0x0033d820) 17 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033d850) 18 0x7e9bbb8b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x449, wp=0x8002, lp=0x33da50, result=0x33d930, arg=0x129ca52f) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:468] in user32 (0x0033d890) 19 0x7e9c0f51 WINPROC_call_window+0xe1(hwnd=<register ESI not in topmost frame>, msg=0x449, wParam=0x8002, lParam=0x33da50, result=0x33d930, unicode=0x1, mapping=0x3e9) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2220] in user32 (0x0033d8d0) 20 0x7e987c55 call_window_proc+0xd5(hwnd=<register ESI not in topmost frame>, msg=0x449, wparam=0x8002, lparam=0x33da50, unicode=0x1, same_thread=0x1, mapping=0x3e9) [/home/florian/wine-0.9.44/dlls/user32/message.c:1615] in user32 (0x0033d940) 21 0x7e98ba43 send_message+0x223(info=<register EDI not in topmost frame>, res_ptr=0x33d9dc, unicode=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/user32/message.c:2444] in user32 (0x0033d9a0) 22 0x7e98beca SendMessageW+0x4a(hwnd=0x10044, msg=0x449, wparam=0x8002, lparam=0x33da50) [/home/florian/wine-0.9.44/dlls/user32/message.c:2567] in user32 (0x0033d9e0) 23 0x7e95369c SendDlgItemMessageW+0x4c(hwnd=0x50030, id=0x3e9, msg=0x449, wParam=0x8002, lParam=0x33da50) [/home/florian/wine-0.9.44/dlls/user32/dialog.c:1269] in user32 (0x0033da00) 24 0x129c6105 in srmm (+0x6105) (0x0033da6c) 25 0x129c47ec in srmm (+0x47ec) (0x0033e1a0) 26 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033e1d0) 27 0x7e9bd1f5 call_dialog_proc+0x65(hwnd=<register EDI not in topmost frame>, msg=0x40b, wp=0x0, lp=0x0, result=0x33e240, arg=0x129c1739) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:490] in user32 (0x0033e210) 28 0x7e9c0be1 WINPROC_CallDlgProcW+0xa1(func=<register ESI not in topmost frame>, hwnd=0x50030, msg=0x40b, wParam=0x0, lParam=0x0) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2424] in user32 (0x0033e250) 29 0x7e94f9a2 DefDlgProcW+0x82(hwnd=<register ESI not in topmost frame>, msg=0x40b, wParam=0x0, lParam=0x0) [/home/florian/wine-0.9.44/dlls/user32/defdlg.c:488] in user32 (0x0033e280) 30 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033e2b0) 31 0x7e9bbb8b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x40b, wp=0x0, lp=0x0, result=0x33e390, arg=0x7e94f920) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:468] in user32 (0x0033e2f0) 32 0x7e9c0f51 WINPROC_call_window+0xe1(hwnd=<register ESI not in topmost frame>, msg=0x40b, wParam=0x0, lParam=0x0, result=0x33e390, unicode=0x1, mapping=0x33eb1c) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2220] in user32 (0x0033e330) 33 0x7e987c55 call_window_proc+0xd5(hwnd=<register ESI not in topmost frame>, msg=0x40b, wparam=0x0, lparam=0x0, unicode=0x1, same_thread=0x1, mapping=0x33eb1c) [/home/florian/wine-0.9.44/dlls/user32/message.c:1615] in user32 (0x0033e3a0) 34 0x7e98ba43 send_message+0x223(info=<register EDI not in topmost frame>, res_ptr=0x33e43c, unicode=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/user32/message.c:2444] in user32 (0x0033e400) 35 0x7e98beca SendMessageW+0x4a(hwnd=0x50030, msg=0x40b, wparam=0x0, lparam=0x0) [/home/florian/wine-0.9.44/dlls/user32/message.c:2567] in user32 (0x0033e440) 36 0x129c3671 in srmm (+0x3671) (0x0033eb74) 37 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033eba4) 38 0x7e9bd1f5 call_dialog_proc+0x65(hwnd=<register EDI not in topmost frame>, msg=0x40c, wp=0xab4a74, lp=0x12fc4d9, result=0x33ec14, arg=0x129c1739) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:490] in user32 (0x0033ebe4) 39 0x7e9c0be1 WINPROC_CallDlgProcW+0xa1(func=<register ESI not in topmost frame>, hwnd=0x50030, msg=0x40c, wParam=0xab4a74, lParam=0x12fc4d9) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2424] in user32 (0x0033ec24) 40 0x7e94f9a2 DefDlgProcW+0x82(hwnd=<register ESI not in topmost frame>, msg=0x40c, wParam=0xab4a74, lParam=0x12fc4d9) [/home/florian/wine-0.9.44/dlls/user32/defdlg.c:488] in user32 (0x0033ec54) 41 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033ec84) 42 0x7e9bbb8b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x40c, wp=0xab4a74, lp=0x12fc4d9, result=0x33ed64, arg=0x7e94f920) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:468] in user32 (0x0033ecc4) 43 0x7e9c0f51 WINPROC_call_window+0xe1(hwnd=<register ESI not in topmost frame>, msg=0x40c, wParam=0xab4a74, lParam=0x12fc4d9, result=0x33ed64, unicode=0x1, mapping=0xab4a74) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2220] in user32 (0x0033ed04) 44 0x7e987c55 call_window_proc+0xd5(hwnd=<register ESI not in topmost frame>, msg=0x40c, wparam=0xab4a74, lparam=0x12fc4d9, unicode=0x1, same_thread=0x1, mapping=0xab4a74) [/home/florian/wine-0.9.44/dlls/user32/message.c:1615] in user32 (0x0033ed74) 45 0x7e98ba43 send_message+0x223(info=<register EDI not in topmost frame>, res_ptr=0x33ee10, unicode=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/user32/message.c:2444] in user32 (0x0033edd4) 46 0x7e98beca SendMessageW+0x4a(hwnd=0x50030, msg=0x40c, wparam=0xab4a74, lparam=0x12fc4d9) [/home/florian/wine-0.9.44/dlls/user32/message.c:2567] in user32 (0x0033ee14) 47 0x129c1560 in srmm (+0x1560) (0x0033ee44) 48 0x0040275d in miranda32 (+0x275d) (0x0033ee6c) 49 0x12581ff1 in dbx_3x (+0x1ff1) (0x0033eed0) 50 0x00402d6f in miranda32 (+0x2d6f) (0x0033eee8) 51 0x129c37ae in srmm (+0x37ae) (0x0033f618) 52 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033f648) 53 0x7e9bd1f5 call_dialog_proc+0x65(hwnd=<register EDI not in topmost frame>, msg=0x40a, wp=0x0, lp=0x7d647a18, result=0x33f6b8, arg=0x129c1739) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:490] in user32 (0x0033f688) 54 0x7e9c0be1 WINPROC_CallDlgProcW+0xa1(func=<register ESI not in topmost frame>, hwnd=0x50030, msg=0x40a, wParam=0x0, lParam=0x7d647a18) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2424] in user32 (0x0033f6c8) 55 0x7e94f9a2 DefDlgProcW+0x82(hwnd=<register ESI not in topmost frame>, msg=0x40a, wParam=0x0, lParam=0x7d647a18) [/home/florian/wine-0.9.44/dlls/user32/defdlg.c:488] in user32 (0x0033f6f8) 56 0x7e9bb4aa WINPROC_wrapper+0x1a() in user32 (0x0033f728) 57 0x7e9bbb8b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x40a, wp=0x0, lp=0x7d647a18, result=0x33f808, arg=0x7e94f920) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:468] in user32 (0x0033f768) 58 0x7e9c0f51 WINPROC_call_window+0xe1(hwnd=<register ESI not in topmost frame>, msg=0x40a, wParam=0x0, lParam=0x7d647a18, result=0x33f808, unicode=0x1, mapping=0xab4a74) [/home/florian/wine-0.9.44/dlls/user32/winproc.c:2220] in user32 (0x0033f7a8) 59 0x7e987c55 call_window_proc+0xd5(hwnd=<register ESI not in topmost frame>, msg=0x40a, wparam=0x0, lparam=0x7d647a18, unicode=0x1, same_thread=0x1, mapping=0xab4a74) [/home/florian/wine-0.9.44/dlls/user32/message.c:1615] in user32 (0x0033f818) 60 0x7e98ba43 send_message+0x223(info=<register EDI not in topmost frame>, res_ptr=0x33f8b4, unicode=<register ESI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/user32/message.c:2444] in user32 (0x0033f878) 61 0x7e98beca SendMessageW+0x4a(hwnd=0x50030, msg=0x40a, wparam=0x0, lparam=0x7d647a18) [/home/florian/wine-0.9.44/dlls/user32/message.c:2567] in user32 (0x0033f8b8) 62 0x129c15d9 in srmm (+0x15d9) (0x0033f8ec) 63 0x00402817 in miranda32 (+0x2817) (0x0033f910) 64 0x7efc5747 invoke_apc+0x87(call=0x33fa68, result=<register EDI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/ntdll/sync.c:664] in ntdll (0x0033f990) 65 0x7efc5db1 NTDLL_wait_for_multiple_objects+0x1c1(count=0x2, handles=0x33fb08, flags=0x6, timeout=0x0, signal_object=0x0) [/home/florian/wine-0.9.44/dlls/ntdll/sync.c:875] in ntdll (0x0033faa0) 66 0x7efc60a0 NtWaitForMultipleObjects+0x60(count=<register ESI not in topmost frame>, handles=0x33fb08, wait_all=0x0, alertable=0x2, timeout=0x0) [/home/florian/wine-0.9.44/dlls/ntdll/sync.c:911] in ntdll (0x0033fad0) 67 0x7ee537c7 WaitForMultipleObjectsEx+0x137(count=0x2, handles=0x33fc80, wait_all=0x0, timeout=0xffffffff, alertable=0x2) [/home/florian/wine-0.9.44/dlls/kernel32/sync.c:192] in kernel32 (0x0033fc20) 68 0x7e194f5b X11DRV_MsgWaitForMultipleObjectsEx+0xeb(count=0x2, handles=0x33fc80, timeout=0xffffffff, mask=0x4ff, flags=<register EDI not in topmost frame>) [/home/florian/wine-0.9.44/dlls/winex11.drv/event.c:297] in winex11 (0x0033fc50) 69 0x7e9878f5 MsgWaitForMultipleObjectsEx+0xf5(count=<register ESI not in topmost frame>, pHandles=0x45d1f4, timeout=0xffffffff, mask=<is not available>, flags=<is not available>) [/home/florian/wine-0.9.44/dlls/user32/message.c:3260] in user32 (0x0033fe00) 70 0x0040191f in miranda32 (+0x191f) (0x0033fe1c) 71 0x00401a21 in miranda32 (+0x1a21) (0x7e98a670) 72 0x04ffbe56 (0x57e58955) 73 0x00000000 (0x00000000) 0xb7d5859d memmove+0x4d in libc.so.6: repe movsl (%esi),%es:(%edi) Modules: Module Address Debug info Name (107 modules) PE 400000- 48c000 Export miranda32 PE 12000000-12011000 Deferred zlib PE 12240000-1227c000 Deferred chat PE 122c0000-122d2000 Deferred clist_classic PE 12580000-12589000 Export dbx_3x PE 12640000-12689000 Deferred icq PE 126e0000-126ee000 Deferred import PE 127c0000-1282e000 Deferred jabber PE 128a0000-128ce000 Deferred msn PE 129c0000-129d5000 Export srmm ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7da18000-7da23000 Deferred libgcc_s.so.1 ELF 7da41000-7da56000 Deferred wtsapi32<elf> \-PE 7da50000-7da56000 \ wtsapi32 ELF 7dc78000-7dcbe000 Dwarf riched20<elf> \-PE 7dc80000-7dcbe000 \ riched20 ELF 7dcbe000-7dd0f000 Deferred libgcrypt.so.11 ELF 7dd0f000-7dd22000 Deferred libtasn1.so.3 ELF 7dd22000-7dd50000 Deferred libcrypt.so.1 ELF 7dd50000-7ddbe000 Deferred libgnutls.so.13 ELF 7ddbe000-7dded000 Deferred libcups.so.2 ELF 7ddf0000-7ddf6000 Deferred libnss_dns.so.2 ELF 7ddf6000-7ddf9000 Deferred libnss_mdns4_minimal.so.2 ELF 7deb0000-7dec5000 Deferred midimap<elf> \-PE 7dec0000-7dec5000 \ midimap ELF 7dec5000-7deeb000 Deferred msacm32<elf> \-PE 7ded0000-7deeb000 \ msacm32 ELF 7deeb000-7df03000 Deferred msacm32<elf> \-PE 7def0000-7df03000 \ msacm32 ELF 7df03000-7df3e000 Deferred wineoss<elf> \-PE 7df10000-7df3e000 \ wineoss ELF 7df3e000-7df70000 Deferred uxtheme<elf> \-PE 7df50000-7df70000 \ uxtheme ELF 7df70000-7df75000 Deferred libxfixes.so.3 ELF 7df75000-7df7e000 Deferred libxcursor.so.1 ELF 7df7e000-7df9b000 Deferred imm32<elf> \-PE 7df90000-7df9b000 \ imm32 ELF 7df9b000-7df9e000 Deferred libxrandr.so.2 ELF 7df9e000-7dfa6000 Deferred libxrender.so.1 ELF 7dfa6000-7dfa9000 Deferred libxinerama.so.1 ELF 7dfa9000-7dfb0000 Deferred libdrm.so.2 ELF 7dfb0000-7e01a000 Deferred libgl.so.1 ELF 7e01a000-7e01f000 Deferred libxdmcp.so.6 ELF 7e01f000-7e022000 Deferred libxau.so.6 ELF 7e022000-7e10e000 Deferred libx11.so.6 ELF 7e10e000-7e11c000 Deferred libxext.so.6 ELF 7e11c000-7e121000 Deferred libxxf86vm.so.1 ELF 7e121000-7e139000 Deferred libice.so.6 ELF 7e139000-7e142000 Deferred libsm.so.6 ELF 7e151000-7e155000 Deferred libgpg-error.so.0 ELF 7e157000-7e1e8000 Dwarf winex11<elf> \-PE 7e170000-7e1e8000 \ winex11 ELF 7e2bc000-7e2dc000 Deferred libexpat.so.1 ELF 7e2dc000-7e307000 Deferred libfontconfig.so.1 ELF 7e307000-7e31b000 Deferred libz.so.1 ELF 7e31b000-7e385000 Deferred libfreetype.so.6 ELF 7e39a000-7e3ff000 Deferred msvcrt<elf> \-PE 7e3b0000-7e3ff000 \ msvcrt ELF 7e3ff000-7e49b000 Deferred oleaut32<elf> \-PE 7e410000-7e49b000 \ oleaut32 ELF 7e49b000-7e4f4000 Deferred rpcrt4<elf> \-PE 7e4b0000-7e4f4000 \ rpcrt4 ELF 7e4f4000-7e590000 Deferred ole32<elf> \-PE 7e500000-7e590000 \ ole32 ELF 7e590000-7e5c5000 Deferred winspool<elf> \-PE 7e5a0000-7e5c5000 \ winspool ELF 7e5c5000-7e61d000 Deferred shlwapi<elf> \-PE 7e5d0000-7e61d000 \ shlwapi ELF 7e61d000-7e71e000 Deferred shell32<elf> \-PE 7e630000-7e71e000 \ shell32 ELF 7e71e000-7e7be000 Deferred comdlg32<elf> \-PE 7e730000-7e7be000 \ comdlg32 ELF 7e7be000-7e7d7000 Deferred version<elf> \-PE 7e7c0000-7e7d7000 \ version ELF 7e7d7000-7e864000 Deferred winmm<elf> \-PE 7e7e0000-7e864000 \ winmm ELF 7e864000-7e8fa000 Deferred gdi32<elf> \-PE 7e880000-7e8fa000 \ gdi32 ELF 7e8fa000-7ea35000 Dwarf user32<elf> \-PE 7e910000-7ea35000 \ user32 ELF 7ea35000-7eaf3000 Deferred comctl32<elf> \-PE 7ea40000-7eaf3000 \ comctl32 ELF 7eaf3000-7eb3a000 Deferred advapi32<elf> \-PE 7eb00000-7eb3a000 \ advapi32 ELF 7eb3a000-7eb4d000 Deferred libresolv.so.2 ELF 7eb4d000-7eb6b000 Deferred iphlpapi<elf> \-PE 7eb50000-7eb6b000 \ iphlpapi ELF 7eb6b000-7eb96000 Deferred ws2_32<elf> \-PE 7eb70000-7eb96000 \ ws2_32 ELF 7eb96000-7ebb0000 Deferred wsock32<elf> \-PE 7eba0000-7ebb0000 \ wsock32 ELF 7edcf000-7eef3000 Dwarf kernel32<elf> \-PE 7edf0000-7eef3000 \ kernel32 ELF 7eef3000-7eefe000 Deferred libnss_files.so.2 ELF 7eefe000-7ef08000 Deferred libnss_nis.so.2 ELF 7ef08000-7ef1e000 Deferred libnsl.so.1 ELF 7ef1e000-7ef27000 Deferred libnss_compat.so.2 ELF 7ef27000-7ef4c000 Deferred libm.so.6 ELF 7ef4d000-7ef61000 Deferred lz32<elf> \-PE 7ef50000-7ef61000 \ lz32 ELF 7ef61000-7f000000 Dwarf ntdll<elf> \-PE 7ef70000-7f000000 \ ntdll ELF b7ce8000-b7cec000 Deferred libdl.so.2 ELF b7cec000-b7e1d000 Export libc.so.6 ELF b7e1d000-b7e2f000 Deferred libpthread.so.0 ELF b7e45000-b7f59000 Deferred libwine.so.1 ELF b7f5b000-b7f72000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) C:\Programme\Miranda IM\miranda32.exe 00000013 0 00000012 15 00000010 0 0000000f 0 0000000e 0 0000000d 0 00000009 0 <==

2 1

Regression at #9443 - caused by "winex11: Force a window to managed mode when it is activated"
by Alex Villacís Lasso Aug. 25, 2007

Aug. 25, 2007

Alexandre Julliard escribió: > Module: wine > Branch: master > Commit: f48eb1581dfe176043cbca5c46400c0f86eb5552 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=f48eb1581dfe176043cbca5c4… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Aug 20 22:06:50 2007 +0200 > > winex11: Force a window to managed mode when it is activated. > > --- This patch causes a regression in Visual Basic apps that display a drop-down combo - the drop-down is displayed behind the dialog instead of over it. Details and URL of demostration at http://bugs.winehq.org/show_bug.cgi?id=9443 . Just discovered it minutes ago. Reversing this patch fixes the regression. This is one of a series of patches on winex11 committed on August 20. Since they did not pass through wine-patches, I don't really know what are they supposed to fix. This is keeping me from simply submitting a reversal of this patch to wine-patches. Could somebody be so kind as to explain? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 2

How do I build with ssl support on Ubuntu AMD 64?
by Scott Ritchie Aug. 25, 2007

Aug. 25, 2007

Somehow, my amd64 packages keep ending up without ssl support being built at runtime. This is despite libssl-dev packages being installed - there doesn't appear to be a 32 bit version of them. Interestingly, the 32 bit wine package works with SSL when installed into the amd64 version. Is this because Wine doesn't dynamically link with libssl? See: http://bugs.winehq.org/show_bug.cgi?id=9292 Thanks, Scott Ritchie

1 0

AMD release developer tools with DX10 support
by Ian Macfarlane Aug. 24, 2007

Aug. 24, 2007

I hope this is useful for testing DX10 stuff: Snippet: "[AMD] has updated its range of game programming tools, adding in DirectX 10 support to its popular suite" http://www.theinquirer.net/default.aspx?article=41904 Ian

1 0

[test.winehq.org] Addition of todo on the results page
by Paul Vriens Aug. 24, 2007

Aug. 24, 2007

Hi, While I'm also busy with getting dll information on the page, I'm still adding stuff. This next iteration will add todo information on the pages. Current situation: http://test.winehq.org/data/200708221000/ There are several todo's for the Wine test but this is not shown on the page. New situation: http://www.xs4all.nl/~pvriens/200708221000_new/ The main difference is the yellow border on the left for some of the Wine tests (for the group shown in the Main Summary and individually at the Group 'Wine differences'). I deliberately didn't add all the todo tests on the Group level (as is done for the skips) as todo have more to do with tests/implementations than the actual system running the test. If there are no objections, I'll sent the necessary patches in a few days. Bit off topic: One thing that struck me was the difference in test results for the Wine runs. This has most likely to do with old Wine installations running new tests. I will add the Wine version to the infrastructure soon so that these outcomes make more sense. -- Cheers, Paul.

3 5

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (patch)
by Alexandre Julliard Aug. 24, 2007

Aug. 24, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > +static void setup_clipping(HWND hwnd, HDC hdc) > +{ > + RECT rc; > + HRGN hrgn; > + > + /* Native control has always a clipping region set when sending > + * the WM_CTLCOLORSTATIC and an application depends on it > + */ > + GetClientRect(hwnd, &rc); > + hrgn = CreateRectRgn(rc.left, rc.top, rc.right, rc.bottom); > + if (GetClipRgn(hdc, hrgn) == 0) > + SelectClipRgn(hdc, hrgn); > + DeleteObject(hrgn); > +} You need to set the region in all cases, intersecting with the existing one if any. Also you need to restore the previous region after painting. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cabinet 4: Don't extract a file if DoExtract is FALSE
by Alexandre Julliard Aug. 24, 2007

Aug. 24, 2007

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Don't extract a file if DoExtract is FALSE. This one fails make test: ../../../tools/runtest -q -P wine -M advpack.dll -T ../../.. -p advpack_test.exe.so files.c && touch files.ok files.c:465: Test failed: Expected dest\testdir to exist files.c:466: Test failed: Expected dest\b.txt to not exist files.c:467: Test failed: Expected dest\testdir\d.txt to not exist files.c:474: Test failed: Expected dest\testdir to exist files.c:475: Test failed: Expected dest\b.txt to not exist files.c:476: Test failed: Expected dest\testdir\d.txt to not exist files.c:483: Test failed: Expected dest\testdir to not exist make[2]: *** [files.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

1 0

What the web test reports need.
by Jakob Eriksson Aug. 24, 2007

Aug. 24, 2007

We need a http://test.winehq.org/data/latest/ Which always points to the latest results. Instead of: http://test.winehq.org/data/200708221000/ etc... Who can fix this? regards, Jakob

2 1

Photoshop CS2 surprise
by Dan Kegel Aug. 23, 2007

Aug. 23, 2007

I fired up Photoshop CS2 today on a hunch, and sure enough, it starts and runs just barely well enough to test! When it starts, you have to dismiss a dialog box, press ^C in the console, and then dismiss another dialog box, but after that you can open an image, edit it, and save it successfully. Quite a few menu items misbehave, so there's lots left to do, but this is a lovely improvement. It seems likely that Mikolaj's recent changes had something to do with this. He's been doing quite a bit on Photoshop lately. Go Mikolaj! - Dan

1 0

re: mscoree: Return S_OK if mono runtime is found
by Dan Kegel Aug. 23, 2007

Aug. 23, 2007

Hi Bryan, I believe your patch lets me install WinBITS successfully. Thanks! - Dan p.s. To be precise, it let winetricks mono12 wine msiexec /i WinBITS.msi work. I then had to do winetricks gdiplus corefonts else the startup would complain about a missing font. Now mono's only complaining about GetThreadContext failed in gc, but that's another kettle of fish.

1 0

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (2nd version, with testcase, fixes bug #9195)
by James Hawkins Aug. 23, 2007

Aug. 23, 2007

On 8/23/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > Tests have shown that every control style should set the clipping > region so I've changed the patch. > You forgot the patch. -- James Hawkins

1 0

Application minimizing resizes it to icon size.
by Meelis Mägi Aug. 23, 2007

Aug. 23, 2007

Hello, i have a silly question. Why does application resized to icon size when it gets minimized ? (also when switching desktops, but thats acts as minimizing i think) Reason i ask is that, there is MMO Ryzom (ryzom.com) that gets a bit confused when minimized and ingame UI gets messed up (only game i know that has this problem) If i comment out SetWindowPos() line in X11DRV_UnmapNotify() function (file dlls/winex11.drv/winpos.c), then ingame ui stays ok. thanks

2 3

Re: shlwapi: Fix UrlCombineW for absolute URLs without slashes.
by Dmitry Timoshkov Aug. 23, 2007

Aug. 23, 2007

"Robert Shearman" <rob(a)codeweavers.com> wrote: > + process_case = (*base.pszSuffix == L'/') ? 5 : 1; Although using the L prefix is harmless in this case, it's better to avoid it in Wine code IMO. -- Dmitry.

1 0

[winetest] Use of HeapAlloc and friends
by Paul Vriens Aug. 23, 2007

Aug. 23, 2007

Hi, Is there any particular reason we don't use HeapAlloc/HeapReAlloc in winetest? The rest of our programs do, but winetest uses malloc and realloc. Cheers, Paul.

3 4

Re: wordpad: Add initial printing support
by Stefan Dösinger Aug. 23, 2007

Aug. 23, 2007

Am Donnerstag, 23. August 2007 01:52 schrieb Alexander Nicolaysen Sørnes: > wordpad: Add initial printing support I usually don't read non-d3d patches, but when I saw the wordpad patches I decided to see what wordpad looks like today, and I am really impressed :-) Good work! This makes me wonder if Wine does or should register mime types for wordpad, notepad, regedit, msiexec or .bat files? We really don't have to be ashamed of our wordpad implementation, it is a nice lightweight editor for .rtf files.

2 1

Re: [PATCH try3 5/5] wininet: When sending INTERNET_STATUS_HANDLE_CLOSING make sure the freed handle is not yet available.
by Alexandre Julliard Aug. 23, 2007

Aug. 23, 2007

Misha Koshelev <mk144210(a)bcm.edu> writes: > + /* As on native when the equivalent of WININET_Release is called, the handle > + * is already invalid, but if a new handle is created at this time it does > + * not yet get assigned the freed handle number */ > if( info ) > WININET_Release( info ); > > + EnterCriticalSection( &WININET_cs ); > + > + if( WININET_dwNextHandle > handle ) > + WININET_dwNextHandle = handle; > + > + LeaveCriticalSection( &WININET_cs ); This is wrong, the handle could have been reused by then, you can't assume it is still free. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used
by Ivan Gyurdiev Aug. 23, 2007

Aug. 23, 2007

Stefan Dösinger wrote: > Up to now we've been lucky that all the games requireing manual fog coords > haven't used vertex buffers, thus we always went through drawStridedSlow. > Make sure that the fog also works with vertexbuffers > > As for the rejected patches from yesterday, I've moved them back to the bottom > of the queue when I fixed them, so I will resend them later. > > ------------------------------------------------------------------------ > > This patch is probably fine, but it makes me look into the surrounding code [ software blending, changing the strided data ], which is still incredibly misleading. That should go into its own function, with the FIXVBO macro removed (since all such macros are evil, without exception), and a big comment should be added that named access to the strided data is only valid in the fixed function pipeline and will not work in the shader pipeline. Maybe it makes sense to use two different structures to make this clearer - not sure.

2 1

Re: user32: static controls should have a clipping region set whilesending the WM_CTLCOLORSTATIC (with testcase, fixes bug #9195)
by Dmitry Timoshkov Aug. 23, 2007

Aug. 23, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > Photoshop ImageReady depends on it. You have added an explicit clipping to STATIC_PaintTextfn, but since you are working on it, please test other static styles as well. Btw, if you are keen on writing a test (or making your test generic) for button control, that would help in investigating and fixing the bug 7569 which suffers from the same problem. -- Dmitry.

1 0

New winetricks: updated fakeie6, added sha1 checksums
by Dan Kegel Aug. 23, 2007

Aug. 23, 2007

Winetricks 1.27 is available for download at 1. Add sha1sums for most downloads 2. Note a few downloads are no longer available (replacements, anyone?) 3. Note mono11 is deprecated 4. Add Mikołaj's nifty fakeie changes (see http://bugs.winehq.org/show_bug.cgi?id=9036) As always, it's up at http://kegel.com/wine/winetricks Share and enjoy (TM)! - Dan (Share and Enjoy is a registered trademark of the Sirius Cybernetics Corp. See http://en.wikipedia.org/wiki/Sirius_Cybernetics_Corporation http://www.zootle.net/afda/share-and-enjoy.shtml )

1 0

re: Using pthread_create within Wine
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

Phil wrote: >The Wine socket implementation has problems when it comes to select. >A fix for this problem is not currently on anybody's radar. > http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html Hmm. You never filed a bug at http://bugs.winehq.org for this, it seems. Could you, please? Incidentally, I ported your test app to Unix, and on Linux, it prints out THIS IS WINE. I'm not sure why you can't adapt your code to deal with the difference in select behavior -- is the problem third party code you have no source for? - Dan

1 0

re: gphoto2.ds: remove camera import UI
by Dan Kegel Aug. 22, 2007

Aug. 22, 2007

Lei wrote: > ... > The alternative is to keep the GUI. It is useful in the case where > there's many pictures on the camera, and the user just want to import > a few of them. We would need to: > > - modify the GUI to fix the crash > - do not automatically generate download thumbnails, but rather, > present the user with the options to download thumbnails, or just go > ahead and import all pictures > - perhaps add a winecfg option to turn off the GUI Rather than remove all that nearly-working code, how about keeping it, adding the winecfg option, and making it default to off for now? (i.e. leave fixing the bug for later.) That should be a smaller, less violent patch... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

Using pthread_create within Wine
by Phil Lodwick Aug. 22, 2007

Aug. 22, 2007

Greetings, I have a proprietary library that has both Windows and Linux ports. The Windows DLL has problems running on Wine, so I have created a builtin version of this DLL in Wine. This has worked fine, except for one function that basically creates a new thread and fires back events to the calling Window application. I believe I have traced this down to the Linux version of the library creating the new thread with pthread_create. Windows.exe Call_dll_to_spawn_thread_and_register_callback(MyCallbackfunc); Windows DLL implemented in wine: void * NewThread(void *p) { MyParams *params = (MyParams *)p; for (i = 0; i < 500000; i++) p->Callback(); } void Call_dll_to_spawn_thread_and_register_callback(void (*callback)()) { MyParams *params = (MyParams *)malloc(sizeof(MyParams)); params->Callback = callback; pthread_create(&MyThread, NULL, NewThread, (void *)params); } If instead of using pthread_create I use CreateThread, I never have a problem. I notice no other wine DLLs are using pthread_create and I have seen hints that this might not work. If so, how do I use the Linux library. (Call_dll_to_spawn_thread_and_register_callback is just simulating what the Linux library would do) Do I create a separate thread using CreateThread to communicate back to the Window application, so that Call_dll_to_spawn_thread_and_register_callback effectively creates two threads, one using CreateThread (Wine DLL), one using pthread_create (Linux Library) and then do synchronization between the two? Any help, suggestion, ideas, questions would be greatly appreciated. Phil

4 5

Compositing GL
by Chris Robinson Aug. 22, 2007

Aug. 22, 2007

Over the past several days, I've been working with some people in #winehackers on a way to help solve the problems Wine faces with OpenGL.. namely the lack of useable onscreen pixel formats and broken child windown rendering. Here's a patch for your perusal in hopes to generate feedback. What this does is, it renders GL to an offscreen buffer the size of the window it's rendering to, first trying a redirected window (if you have the Xcomposite extension), then falling back to GLXPixmaps (which may be slower, especially if you don't have AIGLX). The offscreen buffer is then copied to the window it should be displaying on using X, acting in a manner nearly identical to how Vista composites OpenGL (as described here: http://www.opengl.org/pipeline/article/vol003_7/ ). Given that it uses X to do the final composite, it obeys all clipping regions, which means it works even on obscured child windows. And since it's offscreen, it won't interfere with, or be bothered by, Wine's window. It also allows it to use other visuals/pixel formats than Wine's window (not done in this patch yet). There is a speed hit, however. The DX9 swap chains demo, which gets about 280 FPS for me normally, gets about 80 to 90 FPS with the compositing method. It seems to be a ceiling though, as other more GPU intense apps have no extra noticeable slow down. Still, as an optimization, it can render directly to the window when it's being used on the whole window and the selected pixel format matches the current visual (this bit is disabled in the patch since it's for testing offscreen rendering, but it's simple to re-enable). Further, a registry setting (HKCU\Software\Wine\X11 Driver\CompositeGL) can be used to force GL compositing off to give you the current behavior (single onscreen pixel format, broken child window rendering). This obviously isn't the final patch, however it's likely what the final result will be like, forgoing unforeseen issues. Questions and comments are welcome.

4 7

Re: include: add some definitions to winioctl.h (patch)
by Robert Shearman Aug. 22, 2007

Aug. 22, 2007

Mikolaj Zalewski wrote: > -#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > -#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > The above should be 0x0304 instead of 0x0305. > +#define IOCTL_STORAGE_GET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_SET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0306, METHOD_BUFFERED, FILE_READ_ACCESS) > -- Rob Shearman

2 1

gphoto2.ds: remove camera import UI
by Luke Bratch Aug. 22, 2007

Aug. 22, 2007

--- Alexandre Julliard <julliard at winehq.org> wrote: > > Rather than remove all that nearly-working code, > > how about keeping it, adding the winecfg option, > > and making it default to off for now? > > That option is much too specific to go in winecfg, it's > something most > users don't care about. What you could do though is have a "don't show > this dialog again" option in the dialog itself. How about a registry key? ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

1 0

Re: [2/5] WineD3D: Refuse to lock locked surfaces
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Spotted by DCT > I don't know what the DCT actually tests, but should it refuse to lock any locked surface, or only when the rectangles overlap? Of course a test would be nice, considering surface locking behaves somewhat different between ddraw, d3d8 and d3d9.

2 2

Re: [5/5] WineD3D: Fake occlusion queries if the wrong context is active
by H. Verbeet Aug. 22, 2007

Aug. 22, 2007

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can't we wait for the other thread & context to become active? Afaik occlusion queries are allowed to block on Windows.

2 1

Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"
by Kai Blin Aug. 22, 2007

Aug. 22, 2007

Hi folks, While working on bug 9405, I realized that all 20 votes on that bug were made by the reporter. I think that's pretty lame, so I've asked the bugzilla folks if there's a way to fix that. They said that the settings should be obvious when editing the product. Can we please fix that? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

4 4

Re: advapi32: Add more tests for CryptVerifySignatureW, and correct its parameter checking
by Alexandre Julliard Aug. 22, 2007

Aug. 22, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > From 53a45e7e2adf3b8591f2c07501e7b37538d95657 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Tue, 21 Aug 2007 15:10:35 -0700 > Subject: [PATCH] Add more tests for CryptVerifySignatureW, and correct its parameter checking This breaks the tests: ../../../tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so rsaenh.c && touch rsaenh.ok rsaenh.c:1081: Test failed: Expected ERROR_INVALID_PARAMETER error, got 80090006 make: *** [rsaenh.ok] Error 1 Also the indentation is messed up, please fix your tab size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: How to Calling PE Dlls on linux??
by trulyliu Aug. 22, 2007

Aug. 22, 2007

Hi, Damjan Jovanovic Thank you tired of the answer to my questions. I carefully read the wine part of the code and development document, searched in mail lists, these days. And I got some inspiration from wine plugin API wiki page and wine loader's code. I am considering of an approach. Link preloader and related resource(libwine) with my Linux native App. Do some modify with wine_init function, and call it before main(). This can be implemented by a global C++ objects's constructor. Upper two steps can deal with TEP and FS register. But I there may be another problem. If there was aready an static global C++ object in my App, How can I makde it initiatited after wine_init from in object. Do you have some other expostulate of this idea? BTW, I skim over mplayer and xine's parts of code. They don't dealwith TEB and FS register. They only do sth on LDT and allocat PE header before LoadeLibaray. Why they can run correctly??? 2007/8/22, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > > > > > > > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com>: > > > > > On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > > > > > > Can I made Arithmetic.dll.so ? And link it against my linux App? > > > > > > > > > > A library function runs in the context of the process that invokes > it. > > > > > A library doesn't have its own TEB/memory layout/exception > handling > > > > > that works independently of the process that calls it, no matter > how > > > > > it is compiled. If the wine plugin API is ever made, it will > modify > > > > > the process so it has what the library expects when the library > > > > > functions are called. > > > > > > > > > > Does your Arithmetic.dll.so call any Windows functions? If so, you > > > > > need wine and you will always need wine, plugin API or no plugin > API, > > > > > whether you compile it into a DLL or .dll.so. But if you only use > ANCI > > > > > C stuff you can compile it into a .so and use it without wine. > > > > > > > > > > If you want something that runs seamlessly on every operating > system > > > > > today, IMHO you should consider Java. > > > > > > > > > > > > > > > > > > > > > > Yes, Java may be a good choice for crossing platform. > > > > > > > > As you said, my Arithmetic.dll does not call any windows function. > > > > It's pure ANSI C library. What's the step of make .dll.so ?? > > > > > > > > Use winegcc or gcc ?? > > > > > > Use gcc and make a .so like this: > > > gcc -c arithmetic.c -fPIC > > > gcc arithmetic.o -shared -o arithmetic.so > > > > > > Then put it in /usr/lib and link to it like so: > > > gcc -c application.c > > > gcc application.o -o application -larithmetic > > > > > > > > > -- > > > > > > trulyliu(a)gmail.com > > > > > Damjan > > > > -- > > > > trulyliu(a)gmail.com > > > > > > > > > > Damjan > > > > gcc -c arithmetic.c -fPIC ??? > > I am sorry. I don't have Arithmetic.dll's source code. > > Can I use LoadLibaray() and GetProcAddress > > to get the function which Arithmetic.dll exports. > > No, for the reasons I talked about before. Eg. GetProcAddress() does > look up the current directory, which resides in the TEB, which AFAIK > resides in the FS CPU register on Windows. On Linux the FS register > contains something else, leading to a crash. > > At the moment, you can only use Windows DLLs from Windows applications > or from winelibs, which are Windows applications compiled to be able > to use Linux libraries as well. > > > -- > > trulyliu(a)gmail.com > > > > Damjan > -- trulyliu(a)gmail.com

1 1

Re: [kernel32/tests] Skip some not implemented functions and add a few skip's
by Francois Gouget Aug. 22, 2007

Aug. 22, 2007

On Tue, 21 Aug 2007, Paul Vriens wrote: > Hi, > > GetTempPathW is not implemented on win9x. I did not actually read the test but it sounds like GetTempPathW() is not actually essential to the test. Could we replace it with another way to get the path for a temporary directory? Maybe even hard-code one, maybe adding the process id to make it somewhat unique? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: [1/2] wined3d: Restore a line that got lost
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

Am Dienstag, 21. August 2007 23:22 schrieb H. Verbeet: > This got lost by commit 92ce028a0b3aba513f8fb62d7021533896cd99f6. > > Changelog: > - Restore a line that got lost Actually I think we can remove that whole codeblock now. stateblock::apply and stateblock::capture have the needed states hardcoded now for _ALL, _VERTEX and _PIXEL stateblocks.

1 0

OS X and OpenGL
by Mike Kronenberg Aug. 21, 2007

Aug. 21, 2007

Hello list, I'm a frequent user of wine and normally build my own copy, as no official distribution for Mac OS X exists. Lately I had to deal with a Program, that needs OpenGL. I found different hints on the list and around the net, that the current Apple X11 libGL is broken, so I tried different flavors of xdarwin and x11: X11R6.8.2 and X11R7.2. With X11R6.8 (compiled from fink) wine builds without error. (OpenGL Headers and libs where found) When I run the app, I get: err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support ! err:wgl:X11DRV_wglMakeCurrent No libGL on this box - disabling OpenGL support ! I modified opengl.c to see whether SONAME_LIBGL was set in as_opengl () and it was. With X11R7.2 (pkg form x.org) wine builds without error. (OpenGL Headers and libs where found) but it seams that libGL has a link to a nonexistent library (/usr/X11/ lib/GL), which crashes openGL32.dll when I run the app. Before I start some more debugging on my system: Do you have any hints? (Is this a linking problem / Anybody knows a working revision of X11 / recent bugs, etc) Txs Mike Intel Wine 0.9.43 OS X 10.4.10

1 0

Re: WineD3D: fix a null pointer dereference
by Stefan Dösinger Aug. 21, 2007

Aug. 21, 2007

Am Dienstag, 21. August 2007 16:55 schrieb Roderick Colenbrander: > Hi, > > This patch gets Tiberian Sun working in ddraw OpenGL mode. Before it > suffered > > >from a null pointer dereference bug. This patch is ok with me, but there's a bad flaw with opengl'ed ddraw I want to point out Ddraw apps can just create offscreen surfaces and perform blits between them without creating a render target. To do anything in opengl, a context is needed, and a context needs a drawable. So no gl context without a render target in gl. Now the current code checks if the locked surface is a render target, and crashes because the render target array doesn't exist. This patch simply fixes this NULL pointer dereference. The essential problem remains though, that ddraw operations in gl won't work unless the app creates a render target. Currently it works because only operations on render targets use opengl, but there is code to have opengl do offscreen<->offscreen blits. That code(stretch_rect_fbo) is only used for d3d9, but when activated for ddraw apps too, we have to be careful.

1 0

Re: dinput: Fix compile with old input.h that missing input_absinfo
by Dmitry Timoshkov Aug. 21, 2007

Aug. 21, 2007

"Vitaliy Margolen" <wine-patches(a)kievinfo.com> wrote: > +struct wine_input_absinfo { > + LONG value; > + LONG minimum; > + LONG maximum; > + LONG fuzz; > + LONG flat; > +}; If it's a kernel structure, it's better IMO to use the types that are actually used in the native structure instead of LONG. -- Dmitry.

1 0

Re: How to Calling PE Dlls on linux??
by Damjan Jovanovic Aug. 21, 2007

Aug. 21, 2007

On 8/21/07, trulyliu <trulyliu(a)gmail.com> wrote: > Can I made Arithmetic.dll.so ? And link it against my linux App? A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called. Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine. If you want something that runs seamlessly on every operating system today, IMHO you should consider Java. > 2007/8/21, Damjan Jovanovic <damjan.jov(a)gmail.com >: > > On 8/21/07, trulyliu <trulyliu(a)gmail.com > wrote: > > > > > I have tried these code, It works well. Thanks a lot. > > > Could I use gcc/g++ instead of winegcc/wineg++ ??? > > > mplayer use gcc as it's complier？ What's the mystery in it? > > > > > > > gcc/g++ would give you the wrong ABI (eg. 4 bytes per wide char > > instead of 2 bytes), and the special code needed to set up the Windows > > memory layout and the thread extension block and structured exception > > handling wouldn't get executed, leading to segfaults when you call any > > code that tries to access them. That's assuming you can even compile > > and link. > > > > That's why you need winegcc/wineg++. > > > > > trulyliu(a)gmail.com > > > > Damjan > > > > > > > > > > -- > trulyliu(a)gmail.com > Damjan

2 2

Re: [2/5] WineD3D: Use 0/0/0 as normal if no normal is supplied
by H. Verbeet Aug. 21, 2007

Aug. 21, 2007

I'm not sure about this one. Unless explicitly checked for, (0, 0, 0) will cause a division by zero when trying to normalize it, and I don't know for sure if GL has well defined behaviour for it.

2 1

Re: [5/5] WineD3D: Fix fogstart == fogend with table fog
by H. Verbeet Aug. 21, 2007

Aug. 21, 2007

On 21/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Feel free to suggest a better way to increase the fogend. My way works, but it > is not the nicest way. > Does this really matter? To me, this looks like a rather ugly hack to get the DCT to shut up.

2 1

Re: gdi: AddFontResource needs to support a second default directory
by Alexandre Julliard Aug. 21, 2007

Aug. 21, 2007

"Dan Kegel" <dank(a)kegel.com> writes: > @@ -1727,6 +1736,22 @@ INT WineEngAddFontResourceEx(LPCWSTR file, DWORD flags, PVOID pdv) > { > INT ret = AddFontFileToList(unixname, NULL, NULL, ADDFONT_FORCE_BITMAP); > HeapFree(GetProcessHeap(), 0, unixname); > + if (!ret && !strchrW(file, '\\')) { > + /* http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q100057 > + * suggests that in older versions of Windows, AddFontResource > + * paths were relative to %WINDIR%/Fonts instead of %WINDIR%/System > + * Retry assuming that's what went wrong. > + */ This comment is misleading, fonts are in WINDIR/fonts in all Windows versions, and we never look in WINDIR/system anyway. -- Alexandre Julliard julliard(a)winehq.org

2 1

How to Calling PE Dlls on linux??
by trulyliu Aug. 21, 2007

Aug. 21, 2007

hi: I am sorry to disturb you with a question about calling PE Dll on linux. This is really an old question. I found the sameness issues in mail list. http://www.winehq.org/pipermail/wine-devel/2003-December/thread.html http://www.winehq.org/pipermail/wine-devel/2005-November/thread.html#41917 http://www.winehq.org/pipermail/wine-users/2004-August/014685.html http://www.winehq.org/pipermail/wine-devel/2006-August/050619.html I have tried the ways discussed in these threads。 But it's not clear enough how to do this. So I send this mail to you for some help. I have a PE Dll named Arithmetic.dll which exports a function, it's prototype is: void sort(unsigned int*, int num) I want to call the function in my Linux App. I used winedump to generate a spec file winedump spec Arithmetic.dll This comand generated three files: Arithmetic_dll.h Arithmetic_main.c and Arithmeticspec. What's the next exactly step I should do? What's the usage of the three files? And wow could I use them? I made reference to mplayer's implementation, It's code is a little clutter， and I don't have experience on MS D-Show. Could you give me some simple sample codes ?? Best Regards. -- trulyliu(a)gmail.com

4 5

Re: [patch] Garbage code in text string display
by Guan Xin Aug. 21, 2007

Aug. 21, 2007

Q: Can you give a simple example of such a program (preferably downloadable)? A: Yes. If you have Simplified Chinese environment, you can try: http://update.cz88.net/soft/qqwry.rar which is a freeware for IP address-to-geographical address translation. Before patching WINE, most (though not all) labels and all buttons show garbage code. None after. Q:Can you add a conformance test showing that your patch is correct? A: I have tried editplus, acdsee, and gvim in en_US and zh_CN.GBK locale/encodings. They all ran well. I also tried the German version of winrar in de locale, no problem either. I don't think we need to prove this patch is correct because it is certainly wrong and introduced a bug. However, `any sufficiently advanced bug becomes a feature'. In the source code of Microsoft Windows NT/2k/XP, or to be excact, in the file "private/windows/shell/accesory/spechars/charmap.c" they confessed there is a bug in GDI that `assumes the font's default charset is always the system default locale'. I know peeking into The source code is illegal, but I've only done this some 24 hrs after I submitted this patch. So this patch has nothing to do with my undesirable deed. Xin On 8/19/07, Dan Kegel <dank(a)kegel.com> wrote: > Xin Guan wrote: > > This patch solves the problem that many MBCS programs display garbage code > > for text strings. Because most windows programmers do not handle charsets > > properly, we have to force DEFAULT_CHARSET in here. > > Can you give a simple example of such a program (preferably downloadable)? > > Can you add a conformance test showing that your patch is correct? > - Dan >

2 4

[Winetest RFI] What do you want out of the test suite?
by Paul Vriens Aug. 21, 2007

Aug. 21, 2007

Hi, I just want to get people's opinion(s) about the needs/requirements/whishes for both the conformance tests themselves (including winetest) as well as the webpages. I'll collect the information and will put it on the wiki. Cheers, Paul.

5 16

Re: [PATCH try2 2/5] wininet: Free handle structs in WININET_Release.
by Robert Shearman Aug. 20, 2007

Aug. 20, 2007

Misha Koshelev wrote: > This is necessary so that we send the INTERNET_STATUS_HANDLE_CLOSING before, for example > INTERNET_STATUS_CLOSE_CONNECTION gets sent from HTTP_CloseConnection in HTTP_CloseHTTPRequestHandle. > This can be tested on native/with native wininet on wine because although we do not send > INTERNET_STATUS_CLOSE_CONNECTION correctly when the data is finished reading on wine as native > does, if we simply don't read all the data (or any data, changing the while TRUE's to while FALSE's > in the InternetReadFiel_test for example in wininet/tests/http.c) then these do in fact get sent > as a response to InternetCloseHandle like they do on wine, and INTERNET_STATUS_HANDLE_CLOSING > always gets sent afterwards (last). > It seems like it would be better to add a close_connection method to go along with destroy, instead of leaving the handle in a half-destroyed state. Either that, or to not use INTERNET_SendCallback to send the callback in this case so that you don't have to have a WININETHANDLEHEADER object still around. -- Rob Shearman

2 1

Re: winefile: Save font settings for registry
by Dmitry Timoshkov Aug. 20, 2007

Aug. 20, 2007

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > Changelog: > this patch add opportunity to save font option to the regestry, and load font > option from regestry in the winefile program Nothing prevents you from writing and reading the whole LOGFONT structure in one go. -- Dmitry.

1 0