August 2010 - Wine-devel - list.winehq.org

re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite
by Dan Kegel 13 Sep '10

13 Sep '10

Henri wrote: > You still have basic formatting errors like trailing spaces, mixing > tabs and spaces, inconsistent "*" placement, etc. > ... unnecessary cast... > wine-patches reviews are supposed to catch non-trivial interactions with > other parts of the code, not trivial whitespace errors. Looking at http://wiki.winehq.org/SubmittingPatches, I didn't see a nice, concise checklist of things to check for, so I added one at the top, and linked to Henri's post. Improvements welcome. - Dan

3 2

Wine Gecko 1.1.0 RC1
by Jacek Caban 04 Sep '10

04 Sep '10

HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko

4 7

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com 03 Sep '10

03 Sep '10

Octavian, >I just looked in mmddk.h and they have this: >#define MCI_INTEGER64 13 It's good you found out about MCI_INTEGER64. Yet it's completely crazy because googling it yields 6 hits in total, all about Wine bug 22146. Bing shows nothing at all. How can such a name be that invisible? >So, do you want to fix your patches and send them, or do you want me >to continue working on this patch set? I'm fine if you do (as I've plenty of other patches in my queue) especially if you also fix the parser to handle MCI_HWND (another DWORD_PTR), which is the second half needed for 64bit as I mention in http://bugs.winehq.org/show_bug.cgi?id=22146#c12 GetDWORD also needs some change to be able to parse DWORD_PTR things, e.g. window handles. I've not yet written a single test for that (no mciavi tests). I'll send you all the MCI tests I have written ASAP. Even without written tests, one can use WINEDEBUG=+mci and analyse the parser logs for individual commands sent e.g. via the interactive MCI shell you'll find in http://bugs.winehq.org/show_bug.cgi?id=20232#c10 You obviously own a 64bit system so it's easier for you to test. I don't and had to beg. Regards, Jörg Höhle

2 3

Re: shell32/tests: Test that a folder can be named when clicking "Make New Folder"
by Frank Richter 03 Sep '10

03 Sep '10

On 10.08.2010 20:22, Michael Mc Donnell wrote: > When a user clicks the "Make New Folder" button a new folder is created. > The name of the folder is selected, and the dialog box waits for the user > to either accept the name or type in a new one. The test types in a > new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.

2 1

banning spammer from the forum
by Rosanne DiMesio 03 Sep '10

03 Sep '10

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

4 5

re: RFC: test of 16 bit wine (DOS)
by Dan Kegel 02 Sep '10

02 Sep '10

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

2 5

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com 02 Sep '10

02 Sep '10

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

5 12

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)
by GOUJON Alexandre 01 Sep '10

01 Sep '10

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

4 8

Chinese translation of key pages on wiki.winehq.org?
by Dan Kegel 01 Sep '10

01 Sep '10

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

3 3

Wine 1.4 plans?
by Dan Kegel 01 Sep '10

01 Sep '10

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

4 3