With Version 1.1, CodeWeavers is officially supporting both Microsoft Outlook and Internet Explorer, in addition to the already-supported Microsoft Word, Excel and PowerPoint, and IBM Lotus Notes. This enables organizations to make the transition to a Linux desktop without having to completely replace their internal systems. "With Outlook and Internet Explorer support, we feel that we have rounded out the most important features of the Microsoft Office Suite, and have made it simple and painless for an organization to adopt the Linux desktop" said Jeremy White, founder and CEO of CodeWeavers.

Hi everyone,

The past several months have seen a dramatic change in Wine's license, and TransGaming, like many others organizations, has had to take the time to consider how the license changes impact us, our subscribers, and our partners. We have also taken the time to listen carefully to the comments on the Wine-License list, and those we have received in private emails. Ultimately, we have a responsibility to make pragmatic business decisions that will ensure the continued growth of our company while also preserving the interests of our supporters.

In an endeavour to bring a halt to the ongoing contention regarding the license change, we have decided to concentrate our efforts on the ReWind tree. We hope that developers who recognize the value of the contributions we have made and are continuing to make will support us by making their patches available to ReWind under the X11 license.

Over the next few days, we will be merging a number of contributions into ReWind, including those that were initially offered for trade, as well as some things that were not previously offered. Some of the more exciting bits are the DIB engine that we've been developing, as well as our new DCOM architecture. The new DCOM work eliminates many of the problems that the previous typelib-only marshalling in both WineX and Wine had. It supports inter-thread marshalling, and will support application defined (non-typelib-based) marshallers, in addition to the previous OLE Automation (typelib) marshallers. It also includes a preliminary IDL compiler that is currently suitable for automatically building Wine-style COM macro definitions from IDL. The IDL compiler won't actually output marshalling bytecode yet, however.

The new DCOM system is still a work in progress, and we are a little ways away from fully supporting InstallShield 6 with it. We hope that anyone interested in DCOM and OLE support will work with us to improve it. There are several things that remain to be done (including the marshalling bytecode interpreter) that Ove will elaborate on shortly.

Until the ReWind (and WineX) trees have better DLL separation support, TransGaming will not be able to directly participate in any LGPLed development, due to the legal and business considerations that we've discussed before. Other developers are of course free to integrate the work that we are contributing to ReWind into the LGPLed Wine tree.

We will be working on DLL separation in the ReWind tree in order to be able to take part in LGPLed development on a component by component basis in the future. Any assistance offered by other developers would be appreciated, including the re-licensing of patches that are currently LGPL-only. Without any help, it may be some time before we are able to share any of our work directly with the Wine tree.

We are continuing our participation in the development of ReWind and Wine to the extent that our legal and business situation allows, and we are doing everything in our power to offer Linux gamers the best possible solution for running the games they want on the platform they love. We greatly appreciate the support of not only our subscribers and supporters, but of all the individuals and organizations who have contributed to Wine over the years. Through our joint efforts so far, we have been able to bring hundreds of Windows games to Linux users' desktops, and TransGaming has been able to contribute tens of thousands of lines of code to the Wine project. We look forward to continued collaboration.

Thanks,

-Gav

I'm just writing to "report" from WINE's booth during LinuxTag in Karlsruhe, Germany. Andreas Mohr and Uwe Bonnes were the developers staffing the booth. Generally, there was significant interest and high hopes for the WINE project, requests for application support was centered on MS Office (Word and Access mainly, also secondary MS apps like Visio and MS Project), Lotus Notes (but that one works quite well already, although we didn't demo it), WYSIWIG Web editors (Dreamweaver, Homesite) and DTP application (very common was support for PageMaker, which is the predecessor to Adobe InDesign). Illustrator and Photoshop were also common requests. The other notable application was Act 2000, which is some kind of Personal Information Management Software (and it did not work :)). CAD software was also commonly requested, though requests were spread on a lot of products.

We tried to analyze most of the problems - I hope I can put in some bug reports later. We were able to solve *two* problems - Rhinoceros 3D modelling software (Andi will mail the patch later) and some fixes for BuildCommDCB (for some special hardware development software).

A personal wishlist item: I'd like to have some overview documentation for the tricky areas in Wine, like Interprocess communication and window management (how to debug this, mainly).

We found out that the wine debugger doesn't really work that well yet :-) (for me, it only worked after setting it to not using an xterm/wconsole)

Marcus Meissner also stopped by and found out that most apps (Homesite, Dreamweaver, Adobe InDesign 2.0) were using encryption to protect their application file, we didn't get the decryption working. A lot of apps would probably start working if we could support "encrypted" binaries. I'll try to put in more detail later, however, you can download their trial applications and see for yourself :-)

Another area of consternation was installer support, however, most InstallShield-based installers worked with a native stdole32.tlb (maybe a message to the user that (s)he needs this would be a good idea while we can't generate the typelib file ourselves, or is there some rewind stuff we could use?).

About games: we showed Half-life, Diablo 2, Starcraft and Grim Fandango, we used winex for that, though. Reaction to the proprietary extensions of Transgaming (and sometimes Codeweavers) were varied. It was a bit sad that most non-game applications each had some flaws (the WordArt bug for Office, dibengine problems for MS IE, the non-working compiler backend for Visual Studio (could be a problem with the specific computer) and well... there weren't many more apps we could show because most didn't start up :))

Links to trial applications: (those I mentioned above)

• InDesign 1.5: ?
• InDesign 2.0 (PageMaker would also be interesting, get it from the same URL)
• Illustrator 10
• Act 2000
• CoolEdit 2000
• Homesite (note: registering should not be necessary, click on "continue w/o login")
• Dreamweaver
• Rhinoceros 3D (this one works great with Andi's patch!)

(and those that were rarely or just once mentioned, and not mentioned above)

• Gandke & Schubert EAR and GS-Verein
• Lemmings Revolution
• Mindmap (with registration)
• Q-Stat (no free download. contacting them via mail requesting a demo per snail mail should work)
• Xara X

Photos: We made few. I hope Andi will mail an URL with them to wine-devel later.

(I hope I can post some debug logs later and put some entries in the bug tracking system. No firm promises though, but you can always try most apps yourself)

1. make a fake_windows in the $HOME/.wine
   
   http://chem.skku.ac.kr/~wkpark/kle/wine/dotwine/make_dotwine
2. install some ttf fonts($ wine NEWFNT32.exe;wine corfnt32.exe)
   
   wget ftp://ftp.microsoft.com/developr/drg/TrueType/NEWFNT32.EXE
wget ftp://ftp.microsoft.com/developr/drg/TrueType/corfnt32.exe
3. install dcom98.exe($ wine dcom98.exe)
   
   wget http://download.microsoft.com/msdownload/dcom/98/x86/en/dcom98.exe
4. install ie5setup.exe ($ wine ie5setup.exe)
   wget http://download.microsoft.com/download/ie501sp2/Install/5.01_SP2/WIN98/EN-US/ie5setup.exe
5. delete .wine/fake_windows/Windows/WinInit.ini (?) see Wininit.ini and you can find some instructions...
6. run explorer.exe with following config; (explorer.exe!! not iexplore.exe, you may copy it from some windows boxs) i think.. when explorer.exe executed.. some registry entries are created which iexplore.exe need.
   [AppDefaults\\explorer.exe\\x11drv]
"Managed"="N"
"Desktop"="800x600"


[AppDefaults\\explorer.exe\\DllOverrides]
;;
"gdi32" = "builtin"
"kernel32" = "builtin"
;;"shell" = "native"
;;"shell32" = "native"
;;"commctl" = "native"
;;"comctl32" = "native"
"shell" = "builtin"
"shell32" = "builtin"
"commctl" = "builtin"
"comctl32" = "builtin"
;
"imm" = "builtin"
;"ntdll" = "native"
"shdocvw" = "native"
"shlwapi" = "native"
"wininet" = "native"
"*" = "native, builtin"
7. run iexplore.exe !!
   
   
   [AppDefaults\\iexplore.exe\\DllOverrides]
;;
"gdi32" = "builtin"
"kernel32" = "builtin"
;;"shell" = "native"
;;"shell32" = "native"
;;"commctl" = "native"
;;"comctl32" = "native"
"shell" = "builtin"
"shell32" = "builtin"
"commctl" = "builtin"
"comctl32" = "builtin"
"imm" = "builtin"
;"ntdll" = "native"
"shdocvw" = "native"
"shlwapi" = "native"
"wininet" = "native"
"*" = "native, builtin"

this is my screenshot.

• ( with "Windows"="win95" )
• ( with "Windows"="win98" )

• it would prevent us from reading the information in the '.lnk' file... at least for 'supported' '.lnk' files
• it's not entirely clear to me what they do with unsupported '.lnk' files. Are they just dead symlinks or can one read their contents? In the first case Wine is SOL again, and in the latter case we'll have to play games to know which kind we got.
• it was suggested to implement a hack to let Wine access the '.lnk' data. Why implement a hack which is going to be Linux specific when doing nothing works just fine and on any Unix system?
• making it a default option does not help Wine at all. Then we have to keep telling users that they have to modify their fstab if they want Wine to work.

Attached is an extremely preliminary BiDi patch. Here are the things this patch contains, and the points I would love to hear the list's comments about. This patch is under the LGPL only, at this stage.

Changes:

• Fixed the heb.nls file so that LANG=he_IL will be accepted
• Implemented a skeleton for GetFontLanguageInfo.
• I have filled in the skeleton where I knew what to fill it with. I would guess that a lot of stuff is still missing.
• I would apretiate input on the aprorpiatness of using GetTextCharsetInfo as the source of information.
• I have removed the FIXME, but a lot of stuff is still unimplemented. I didn't quite know what to put there instead.
• GetCharacterPlacementW - This is certanly one of the more overloaded functions in the Win32 set (Select object comes to mind as a competitor, and this one has way more execution flows throught it). So far, as far as I could tell, only the flow that matched Latin fonts was implemented. I have added some (very basic) reordering. I would like to hear your comments about the following points:
• I followed the autodocumentation instructions. Is this at all still supported or required?
• The algorythm I used is far from a good one. It still doesn't support right to left paragraphs, neutral boundry characters, and a bunch of other necessary stuff. All it does, at the moment, is make sure consecutive runs of one direction are, more or less, readable.
• I have added a fastpath option when no work is necassary. When all that is supported is reordering, this may make sense. However, I am somewhat worried that when kerning, ligation, glyphing etc. are added, the fastpath will be meaningless. Opinions?
• ExtTextOutW
• I am calling GetFontLanguageInfo for each and every ExtTextOutW (which is a focus point for all Text rendering functions). What performance implications will that have? Don't forget that what I pay for in asking whether reordering is necessary, I get back in not calling GetCharacterPlacementW, and in not allocating a buffer. Then again, some Unicode fonts will suffer both allocation and no reordering.
• I am calling the backend text printing function in two flows. One is using the allocated buffer used for GetCharacterPlacementW, and the other is the original (no point in allocating a buffer if no processing was done). Should I work hard to merge the two calls?
• I am assuming that the backend driver will not perform any reordering. I am not sure how correct that assumption is under, say, KDE3 (Hetz?).