April 2011 - Wine-Devel - list.winehq.org

Must multimedia players check the message queue and invoke DispatchMessage?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Juan Lang wrote: >> What do you mean exactly by "message pumping"? >It's a broad topic, but yes, basically you want to call DispatchMessage >on some messages periodically. See e.g. MsgWaitForMultipleHandles. Thanks for the link to http://blogs.msdn.com/b/oldnewthing/ in another thread. That day's top post http://blogs.msdn.com/b/oldnewthing/archive/2011/03/23/10144592.aspx gave the answer to another question I had faced during my redesign of the MCI MIDI player: How does WaitFor(threadHandle) react should the thread being waited for use CloseHandle(threadHandle) prior to exiting? Back to message pumping, http://blogs.msdn.com/b/oldnewthing/archive/2011/03/04/10136703.aspx says: "Furthermore, it's a known quantity for programs that when you call GetMessage or PeekMessage, incoming sent messages are dispatched [...]" Looks like I was confused. The model of window events I have in mind is still influenced by how things work in AmigaOS; I'm not familiar with MS-Windows' behaviour. Now I know many things happen before GetMessage returns. DispatchMessage is not always needed. Unfortunately, I don't grok yet when DispatchMessage is required. http://blogs.msdn.com/b/oldnewthing/archive/2004/06/08/150929.aspx "Everybody who has messed with window messaging knows that GetMessage and PeekMessage retrieve queued messages, which are dispatched to windows via DispatchMessage." None the clearer. If I just retrieved them (they were obviously "dispatched" to my queue), why must I dispatch again? I.e. what's the kind of work that the function calling GetMessage Should/can do vs. the work to be done by whatever function DispatchMessage eventually calls? Regards, Jörg Höhle

April 8, 2011

ntdll: Remove more path trailing chars.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Juan Lang wrote: >Vincent Pelletier wrote: >> Those tests are boolean, so I doubt an "ok(pass || fail /* NT4 */)" makes any >> sense. >> I saw that it is discouraged (forbidden ?) to depend on OS version in tests, >> so I will avoid that path unless asked to follow it. >You'd want to use "ok(pass || broken(fail /* NT4 */)". No! Juan, while you generally give excellent advice, please think again about that one suggestion. It means tests never fail on native, which renders the test useless. What I've been doing several times is to write a detector and have the tests expect the specific NT/non-NT value. static BOOL TrueButNT = TRUE; Don't query OS version! Instead, the first test that sees the difference in behaviour does this: ok(rc == DO || broken(rc == DONT /* NT */), "bla\n"); TrueButNT = (rc==DONT) ? FALSE : TRUE; All later tests use ok(rc == TrueButNT, "bla2\n"); It even works with todo_wine. Any other means to detect NT *that is relevant for your test* is fine, i.e. don't query the DLL version or use some function outside of your test domain. Typical detectors are different GetLastError() values. I call this "coherence testing". Regards, Jörg Höhle

April 8, 2011

Re: Project: x86 to ARM binary translator

by Yale Zhang

Thanks everyone for their comments. I took some time to reread the FX!32 and Transmeta Crusoe publications (I 1st read them 3 years ago while I was at Georgia Tech) to see what the challenges are. The simplest approach is what Stefan proposed: run the Windows app inside x86 wine, inside of QEMU (target = x86, host = arm). Pretty clever, but the 2 layers of translation, instead of 1 layer, might cause problems. Also, I said earlier, I don't think QEMU's code generator produces fast enough code, so that will need to be improved (no change to Wine). I will try it and see what happens. The 2nd approach, which is almost identical to FX!32 (runs x86 Windows programs on Alpha Windows), will be to do what Stefan proposed 2nd: create a stand alone process VM to run x86 Windows apps on ARM Windows, using wrappers to translate x86 Windows functions to ARM Windows functions. I think those wrappers/jackets can be generated automatically by scanning header files. I still don't like this approach due to doing the API translation and instruction set translation in 2 separate programs. Ideally, I would take the Darwine approach of doing both API translation and binary translation both in Wine. To me, the API translation is less interesting than doing x86 to ARM translation efficiently. I said earlier, QEMU's approach of translating target instructions => micro ops => host instructions is inefficient due to generating redundant operations. 1. Transmeta code morphing software no emulation of x86 instructions: always translates to native instructions (though not always with optimizations). Hot code is retranslated with optimizations. 2. FX!32 first emulates x86 instructions, then picks candidates for translation to Alpha instructions I'm tempted to do a quick and dirty x86 to ARM translation for cold code that isn't a candidate for optimization. But since any non-trivial code transformation/optimization is best done on a *simple* intermediate representation, I will have use an intermediate representation for hot code that needs to be optimized. But writing a direct x86 to ARM translator will be a lot of work and not portable to other targets (resurgent MIPS ?) Therefore, another approach would be to use QEMU as is, but use LLVM optimizations for hot candidates like was done earlier in a Google SOC project. This will be very slow on a the 1st run of the program, but a persistent translation cache like FX!32 and .NET assembly uses, will make subsequent executions much faster. The static persistent translation won't be complete however, due to unknown indirect branches, so it will keep growing. I think the main reason FX!32 uses a persistent translation cache is because it uses emulation, which would be otherwise intolerable if done on every application launch. Other issues: x86 condition flag evaluation - I want to do this lazily, but how do I know the liveness of those values (given an instruction that uses a condition flag, how do I find the instruction that generates the condition flag)? Stefan, --------------------------------------------------------------------------------------------- "ARM doesn't need [dealing with unaligned loads/stores], but PPC does" OK, good to know. Earlier, I thought ARM didn't allow unaligned loads/stores at all, but apparently ARM6+ does. Andre, ----------------------------------------------------------------------------------------------- "Maybe first to ARM Linux and then to ARM Android?" Yes, if I can figure out how to install Ubuntu onto my Xoom. I saw someone do it here <http://www.youtube.com/watch?v=xDB0PMrGdN0>, but he's just running the userspace part of Ubuntu on top of Android, so I'm not sure if that will be as compatible as running a native Linux kernel "I know about that and was told it was never implemented because of problems with the endianess" Right, if the endians are different and required byte swapping on every load/store, that will kill the performance. Luckily ARM can operate in both little and big endian. Damjan, ------------------------------------------------------------------------------------------------- In theory, binary translation will allow Flash Player, Java JVM, to run on ARM, but there might be complications because those programs generate and execute x86 code. Also, I agree improving QEMU binary translation would be the simplest approach, but like I said earlier, I get a feeling that doing API translation and instruction set translation in 2 separate programs, might cause problems. Yale On Sat, Apr 2, 2011 at 9:06 AM, Damjan Jovanovic <damjan.jov(a)gmail.com>wrote: > On Sat, Apr 2, 2011 at 2:19 AM, Yale Zhang <yzhang1985(a)gmail.com> wrote: > > Fellow developers, > > I'm thinking of starting a VM project to allow running x86 Windows apps > on > > ARM Android. This will obviously involve binary translation. I've read > about > > QEMU's tiny code generator and think for a usable experience, > > the intermediate micro-op representation will have to be abandoned, and > use > > a more efficient, though less portable x86 to ARM translator. I also saw > > some Google SOC project that tried to incorporate LLVM into QEMU, but > with > > disastrous slow down if done naively. I still think it's worth to do so, > but > > lots of care will need to be done to only optimize code that needs it > like > > Sun's HotSpot Java compiler does. > > Questions: > > 1. How useful would this be and how much interest? > > Obviously, this will be a huge project, and I just want to gauge the > > interest before I jump in. Microsoft will be releasing Windows for ARM > soon, > > so there will be no need to worry about > > running Office, Matlab, Visual C++, etc on ARM, leaving only legacy > > applications and games to benefit from binary translation. I'm mostly > > interested in seeing some 3D games run on my > > I would love such a project and am willing to help. Good x86 on ARM > emulation is essential, and not just for Wine: Flash doesn't work on > ARM, Java (in the form of OpenJDK) doesn't support ARM yet, there's > the MPlayer win32codecs, etc. > > Complete and correct x86 emulation is mighty difficult. The total > number of all 16/32/64/MMX/SSE instructions (as seen by the udis86 > disassembler) is 710(!!). This is excluding instruction prefixes which > change what instruction do (eg. 16 vs 32 bit memory access). When last > I checked, qemu didn't support all of those instructions. > > > Xoom. > > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > > wine)? > > Process VM: > > + easier to incorporate 3D acceleration at API level > > + uses less memory > > + better performance (e.g. no need for MMU translation when accessing > > memory) > > + much better integration with host OS > > - needs to maintain custom Windows API implementation (Wine) > > * To get 3D acceleration, user-space x86 X/OpenGL drivers would have > to be able to talk to the ARM kernel driver for that graphics card, or > you'd need x86 to ARM wrappers for X and OpenGL libraries, or you'd > need to use x86 kernel driver and do x86 emulation in the kernel too > (very hard), or do whole system VM and the kind of 3D acceleration > passthrough that VirtualBox does at the moment (which works poorly, in > my limited experience). NVidia's ioctls are undocumented IIRC, so even > if they provide an ARM port, translating those between x86 and ARM > might be difficult. > > > Whole system VM: > > + simpler, more unified to implement > > + much better support for apps that are dependent on new, proprietary, > > obscure Windows libraries, interfaces (moot because Office, Matlab, > etc > > will soon be available for ARM) > > * poor integration with native desktop/filesystem > * more to emulate -> slower > > > Given the aims of only running legacy applications and games, it seems a > > foregone conclusion that Wine's process VM approach is best. Comments? > > Agree, but it doesn't have to be done as part of Wine. What Darwine > did - IIRC try to make Wine DLLs PowerPC based and only the > application x86 - seems like a bad idea: the application/Windows API > split is badly defined and many things (eg. COM) are > difficult/impossible to do correctly. I prefer qemu's approach: all > user-space is x86, only the kernel is ARM. > > qemu-i386 doesn't even run 32 bit Wine on amd64 long mode at the > moment (segfault on startup), I'll have to investigate at some stage. > > > 3. Will Wine ever incorporate binary translation? > > My proposed design will obviously use Wine's implementation of the > > Windows API, which is huge. I'm not sure how disruptive of a change > binary > > translation will be to Wine. > > > > If Wine does incorporate binary translation, maybe they can change the > > name to Wine Is Now an Emulator > > > > If your're interested in this project, please reply. > > Replying. > > The best way to go here would probably be improving qemu. If it turns > out not to be good enough, rewriting the CPU emulation but keeping the > system call translation is probably easier than a whole new project > written from scratch. > > Damjan >

April 8, 2011

Re: wine.inf: Add shell handler for .url files.

by Jacek Caban

Hi Hans, On 4/8/11 9:22 AM, Hans Leidekker wrote: > diff --git a/tools/wine.inf.in b/tools/wine.inf.in > index d4a457b..048b5bb 100644 > --- a/tools/wine.inf.in > +++ b/tools/wine.inf.in > @@ -161,6 +161,7 @@ HKCR,.lnk,,2,"lnkfile" > HKCR,.msi,,2,"Msi.Package" > HKCR,.msp,,2,"Msi.Patch" > HKCR,.rtf,,2,"rtffile" > +HKCR,.url,,2,"InternetShortcut" > HKCR,.wri,,2,"wrifile" I'm not sure about other changes, but this should go to shdocvw. I have a patch in my queue for that. Jacek

April 8, 2011

Re: wine.inf: Add shell handler for .url files.

by Hans Leidekker

On Fri, 2011-04-08 at 09:35 +0200, Damjan Jovanovic wrote: > Aren't most Internet-related file associations created by > dlls/mshtml/mshtml.inf instead of tools/wine.inf.in, and should we > maybe change that or move your patch there? Looks like InternetShortcut is registered both by shdocvw and mshtml. I'm not sure about moving this stuff there, winebrowser should perhaps always be available as a fallback, even if our builtin browser is unregistered.

April 8, 2011

Re: wine.inf: Add shell handler for .url files.

by Damjan Jovanovic

On Fri, Apr 8, 2011 at 9:22 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=26673 > --- > tools/wine.inf.in | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/tools/wine.inf.in b/tools/wine.inf.in > index d4a457b..048b5bb 100644 > --- a/tools/wine.inf.in > +++ b/tools/wine.inf.in > @@ -161,6 +161,7 @@ HKCR,.lnk,,2,"lnkfile" > HKCR,.msi,,2,"Msi.Package" > HKCR,.msp,,2,"Msi.Patch" > HKCR,.rtf,,2,"rtffile" > +HKCR,.url,,2,"InternetShortcut" > HKCR,.wri,,2,"wrifile" > HKCR,chm.file,,2,"Compiled HTML Help File" > HKCR,chm.file\shell\open\command,,2,"%10%\hh.exe %1" > @@ -215,21 +216,25 @@ HKCR,xmlfile\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,xmlfile\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,xmlfile\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,xmlfile\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,ftp,"URL Protocol",2,"" > HKCR,ftp\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,ftp\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,ftp\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,ftp\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,ftp\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,http,"URL Protocol",2,"" > HKCR,http\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,http\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,http\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,http\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,http\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,https,"URL Protocol",2,"" > HKCR,https\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,https\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,https\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,https\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,https\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,mailto,"URL Protocol",2,"" > HKCR,mailto\shell\open\command,,2,"%11%\winebrowser %1" > ; FIXME: the following should be done by the dll registration > HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\1.0\0\win16,,,"stdole.tlb" > -- Aren't most Internet-related file associations created by dlls/mshtml/mshtml.inf instead of tools/wine.inf.in, and should we maybe change that or move your patch there? Damjan

April 8, 2011

Re: riched20: Remove the unneeded DEFINE_STDCALL_WRAPPER.

by Austin Lund

On 8 April 2011 08:09, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > > I don't know if this will help but... > > Both Clang and (recent) GCC have direct support for > __attribute__((thiscall)) (and I would know about Clang, I added it to > the LLVM side). We could potentially take advantage of this and not have > to declare thunks like this. That's definitely not portable. It could be used with ifdefs, but then one would have to ask if it is worth the effort. Is there any speed or security or other reason for preferring this method on compilers that support it?

April 7, 2011

Re: Google Summer of Code project

by Jacek Caban

Hi Michał, On 4/8/11 12:28 AM, Michał Ziętek wrote: > Hello, > > My name is Michal Zietek, I am studying Computer Science at Wroclaw > University of Technology. I would like to take part at Google Summer > of Code. Lately I saw Jacek Caban presenting Wine at the university > and he said there could be a possibility to start in Google Summer of > Code and work on Wine. I talked to Jacek about project related to > WScript. I am interested in working on this project but I can't find > it on the Google Summer of Code website. The only place I found any > information is > http://www.winehq.org/pipermail/wine-devel/2011-February/088839.html > > Do you consider putting this project into Google Summer of Code? Sure, the project is fine, I just forgot to put it on wiki. Feel free to send an application, but note that the deadline is tomorrow. Jacek

April 7, 2011

Re: Google Summer of Code project

by Charles Davis

On 4/7/11 4:28 PM, Michał Ziętek wrote: > Do you consider putting this project into Google Summer of Code? You can propose whatever you want for GSoC (as long as it's relevant to Wine, or whatever organization you're proposing to). That page is just a list of ideas to get you started. In fact, I proposed something myself you won't find on that list: a graphics driver that uses the native graphics system on Mac OS X. Chip

April 7, 2011

Re: Google Summer of Code project

by Austin English

On Thu, Apr 7, 2011 at 15:28, Michał Ziętek <smierc.w.wenecji(a)gmail.com> wrote: > Hello, > > My name is Michal Zietek, I am studying Computer Science at Wroclaw > University of Technology. I would like to take part at Google Summer of > Code. Lately I saw Jacek Caban presenting Wine at the university and he said > there could be a possibility to start in Google Summer of Code and work on > Wine. I talked to Jacek about project related to WScript. I am interested in > working on this project but I can't find it on the Google Summer of Code > website. The only place I found any information is > http://www.winehq.org/pipermail/wine-devel/2011-February/088839.html > > Do you consider putting this project into Google Summer of Code? Under Google Summer of Code, you have to apply for your own project. In other words, you tell Wine what you would like to do to make Wine better. The application for applications is tomorrow: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/fa… http://www.google-melange.com/gsoc/events/google/gsoc2011 There is some more information here: http://wiki.winehq.org/SummerOfCode Good luck! -- -Austin

April 7, 2011