All the news that fits, we print.
This is the 194th issue of the Wine Weekly News publication. Its main goal is to slip on scree. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
This week, 161 posts consumed 519 K. There were 62 different contributors. 34 (54%) posted more than once. 36 (58%) posted last week too. The top 5 posters of the week were:
|
News: CrossOver Office 2.1 | 10/25/2003 | Archive |
---|---|---|
News
CodeWeavers rolled out an updated CrossOver Office this week adding support for Macromedia products: "Now, with additional support for Macromedia Dreamweaver MX and Flash MX, combined with our existing support for Adobe Photoshop, CrossOver Office 2.1 gives web developers and design firms the first Linux solution for their most important design applications." I missed reporting a TransGaming deal offered to subscribers. Last week they had discounts on their products. Of course, if you're subscribed I'm sure you received an email. Also in the news is the appointment of Leonard Brody to the TransGaming Board of Directors. Also this week, Dan Kegel pointed out that HP World magazine (available with registration ) has references for using CrossOver Office to run Windows programs: On page 20 of the Nov 2003 issue, for instance, titled "POPping Up Terrabytes", they reviewed FIA's POPnetserver NAS 4600 model 720, and said in part
|
Winesetuptk 0.7 Released | 10/28/2003 | Archive |
---|---|---|
Configuration
Ivan Leo Murray-Smith announced: Winesetuptk 0.7 is at the wine sourceforge page This new version contains an updated winedefault.reg, you don't need to run regedit winedefault.reg any more, and it's updated to configure all the latest and greatest features of wine. This release was possible thanks to the help and contributions of Vincent Béron and Alex Pasadyn. Without them, winesetuptk 0.7 wouldn't exist. Download and enjoy! |
Updated Winetests | 10/27/2003 | Archive |
---|---|---|
Testing
Wanna run some conformance tests on Windows? Jakob Eriksson updated his testing program: Since winetests has not yet made it to CVS and I found some spare time, I have now compiled a new winetests.exe. Tests built with MSVC 7 from CVS 20031027. (Testing shell cross built with mingw32.) All you have to do is download winetests.exe and just run it. All of the collected results get displayed in a browser window with the option of submitting them to the wine-tests-results mailing list. |
New Valgrind For Wine | 10/29/2003 | Archive |
---|---|---|
Debugging
Valgrind has helped developers find lots of problems with Wine over the past few months. Adam Gundy announced this week: A new tarball of valgrind modified to work with WINE is available from the valgrind home page: this is based on the latest stable valgrind release. use a current CVS or the latest snapshot of WINE. |
InstallShield 7 Notes | 10/29/2003 | Archive |
---|---|---|
Fixes
Carlos Lozano shared some info concerning apps using InstallShield 7: Here goes some notes about how to install installshield 7 programs with the actual wine releases (sorry, i haven't been able to install without some natives DLLs). You need 3 native DLLs (ole32.dll, oleaut32.dll and rpcrt4.dll), and 2 .tlb files (stdole32.tlb and stdole2.tlb). Copy this 5 files to your windows/system directory, and edit your ~/.wine/config, using:
[DllOverrides]
Even using this natives dlls, you will have problems with the windows order, what you will not leave you see the windows and install the program. The easier way to install it, should be enable the Desktop mode, in ~/.wine/config:
"Managed" = "N"
I have found some programs, what give problems with Desktop mode, exiting during install with X11 errors (Praetoriams demo for example). In this cases you can use yet another trick. Disable Desktop, and enable "Managed" = "Y", then in the file "dlls/x11drv/window.c", you will find the function "inline static BOOL is_window_managed( WND *win )", in the end of this function, there are this 3 lines:
/* default: not managed */
replace, "return FALSE;" to "return TRUE;", and run make install again. Remember after of install the program change again this line to "FALSE", because you could have problems later with other windows. Greg Turner offered to look at the problems with Wine's builtin DLLs if someone could give a pointer to a free installer he could test with. |
Keyboard Detection | 10/27/2003 | Archive |
---|---|---|
Internationalization
Sylvain Petreolle mentioned that although his keyboard works fine in Wine there seems to be problems detecting it. Dmitry Timoshkov explained some of the issues: I think that this topic was explained many times already. Anyway, here is yet another attempt.
Shachar Shemesh pointed out a related problem, In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard. He went on to explain: The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard. I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the effect it has over X keyboard detection. Dmitry wondered how that info could be queried from X. Shachar tossed out some ideas: I was thinking of one of two options. Unfortunately, both require us to know each keyboard layout we support (though, not necessarily know exactly).
2 will mean that we reduce the keyboard source to a table of names, and their respective language IDs. I.e. - "us" means English, "fr" means French, "he" means Hebrew etc. This will probably make adding new keyboard easier (and less error prone), but will ONLY work on XKB. Then again, keyboard selection (also part of the currently missing APIs) will only work on XKB anyways, so we're probably going to have to soft-depend on XKB whatever we do. |
Longhorn Info | 10/28/2003 | Archive |
---|---|---|
Microsoft Windows
Microsoft began unveiling parts of their next generation operating system (codenamed Longhorn) this week. Mike Hearn provided some links to some of the MSDN info that appeared: Of course, as we don't actually implement the "new" XP APIs yet, this is all rather academic. Still, why not take a look at what we'll be reimplementing in 2010 ;)
|
Stubless Proxies | 10/29/2003 | Archive |
---|---|---|
RPC / COM / OLE
If I try to think about this too much I'll get a headache. However, given Greg's nice explanation it's probably worth saving this for reference. Mike Hearn asked, Greg recently mentioned "stubless proxies". Does anybody know where I can read about these? Greg answered: Unfortunately, there isn't a ton of documentation -- or, more accurately, the documentation that you may find is scattered throughout MSDN and the internet, instead of being in an "obvious" place. The MSDN documentation for NdrClientCall2, for example, is almost worthless from the wine implementer's perspective, just stating something like "This is the entry-point for stubless proxies." From the perspective of most users, stubless proxies are a behind-the-scenes implementation detail that isn't worth learning too much about. The end-programmer's perspective is as follows: pass /Oicf to MIDL, and MIDL will magically generate stubless proxies. I forget if /Oic is considered "stubless" as well, I think it may be. The resulting client proxy code generated by MIDL will contain "NdrClientCall2" or "NdrClientCall" instead of the usual multi-step proxy code (there is no in-proxy marshalling, exception-handling, etc -- just the single call). In wine, NdrClientCall2 (the more common entry-point) is totally unimplemented -- it simply emits a FIXME and returns indicating success. The server side is analogous. You will see some code by Ove floating around to generate the manager entry-point thunks in asm, but I don't think they are used yet (?). Unfortunately, stubless proxies have been the recommended (by Microsoft) mode of generating code from MIDL for many years. Increasingly, I see calls to NdrClientCall2. The only solution (aside from coding wine) is to use native rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dlls or else you will bump up against the missing "Ports" API if ncalrpc is used (it usually is -- this is why I keep musing that I want to take a crack at implementing this). I think, the way to code those is to use the structures provided by MIDL (and eventually widl) to determine the necessary steps. In particular, I think this is where the format strings come in handy -- presumably, NdrClientCall2 should parse the format strings and determine what to marshall/unmarshall using those. My theory is that the steps taken in NdrClientCall2 would look very much like those MIDL would spit out in /Oi mode. Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine. Unfortunately, it doesn't make much sense to start working /Oic[f] until /Oi mode is working a lot better. Things like the OXID Resolver, IObjectExporter, RpcObjectSetType, etc, really ought to be in place before we start complicating matters by implementing subless proxies... of course, if someone wants to prove me wrong, be my guest ;) Mike also found some info: Your theory is correct. Somehow I stumbled upon this article: which explains the whole thing. It also talks about how the MS typelib marshaller is implemented - basically it generates format strings from the typelib data then feeds that to the Ndr format string interpreters. |
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.