World Wine News

On the other hand, while the barrier to Linux usage by employees is arguably quite low, the real barrier is more likely that management and system administrators in many organizations may not yet have a clue about how to deploy Linux effectively. A clear prerequisite is having sysadmins who understand Linux or other *nix operating systems. For example, while this desktop installation of SuSE 9.0 proceeded flawlessly --and indeed much better than I anticipated would be the case with some failing hardware in the mix-- the installation of CrossOver Office required a trivial bit of additional manual setup that certainly could have stumped Windows sysadmins who were new to Linux (CrossOver installs without issue on SuSE 9.0, but application icons do not show up on the user's desktop). Solving the nuts and bolts of minor installation issues is however just a small part of the equation. A more important aspect is the realization that tools like CrossOver Office exist and may have a number of advantages (speed, cost, ...) over alternative solutions like VMware for organizations that are looking for practical ways to deploy Linux on a wider scale than they have previously.

I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU.

There are no issues.

SUSE LINUX 9.0 for AMD64 is capable of running all WINE products, including regular WINE, CrossOver Office, CrossOver Plugin and WineX in the 32bit compat mode.

Okay, I read that to mean that you can run already built 32 bit binary versions of Wine.

What about compiling? Would compiling Wine on an Opteron work? Hmm. I suppose you could cross compile to 32 bit, couldn't you.

Well, I do ;)

SUSE 9.0 comes with full biarch toolchain support on AMD64.

Before you start, install additionally to the default packages:

• glibc-devel-32bit
• freetype2-devel-32bit
• XFree86-devel-32bit
• XFree86-Mesa-devel-32bit
• fontconfig-devel-32bit
• openssl-devel-32bit
• ncurses-devel-32bit
• alsa-32bit
• and any dependent rpms.

Then:

export LD="ld -m elf_i386"
CC="gcc -m32" AS="gcc -c -m32" \
./configure --prefix=/usr --x-libraries=/usr/X11R6/lib
make depend all


The -m32 switches gcc to 32bit mode.

If you have arts-devel installed, you might need to patch dlls/winmm/winearts/Makefile and replace lib64 by lib.

You will also need the attached winebuild patch that uses "LD" from the environment.

What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?

Mainly the filters in Quartz.dll and other basic filters that come with the OS.

if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) . I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.

DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX.

http://www.winehq.org/status_dlls

But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz......

I meant to drop you a note, ask what is the status. But you beat me to it.

I have 7 years experience in writing DS filters. I am currently working on enhancing C++ on wine. I have ATL/WTL/MFC compiling and working under winelib. I have compiled COM controls generated by ATL VC++ wizards. I have some problems with the typelibs and so. But this is beside the subject. I would be happy to help in any way I can. I have lots of code that is not MS's. Also I have MS Direct Show Classes compiling and linking under Winelib (again some problems with the typelibs.)

I have my own copyrighted DirectShow video render that is implemented on top of DirectDraw. It uses the Overlay Surfaces YUV or RGB whatever is available/requested. It will also fall back to HW (HardWare) memory surfaces that are not overlay. I did not yet implement the Memory surfaces support. (didn't need to but it should be easy to add them). I could release that code under wine I guess. If so I would also release the windows version of it. But before I do that, there are some issues to resolve (in order of importance):

1. C++ code must be accepted - This is not an area that C is good enough, and in any way I don't know C I am only good in C++
2. What is the status of the DDraw lib. Will it support HW and Overlay 2D surfaces? (does it support HW BOB)
3. I am somewhat dependent on MS DirectShow Classes. (Derivation) I have a lot, self implemented, but some of the basic stuff I used. I guess I could reimplement them but it will take time. Do you know what is the license issues with this code. I know that I have delivered them to many paying clients, and it was checked by the legal department. I all ways thought that, that code is: Do what you like no liability what so ever.

About the Graph manager: I'll think about it. I can certainly do it. But It is a big project. Do you know of a Company that would like to finance such a thing to some extent. ( condition 1 above applies C++ only). I'll think about it any way. Maybe it is not as big as I think. (Usually projects are much bigger than I think they are)

so we should start working out this one, too. First let me sketch the present picture. I've got a directory structure like this:

|
+	20030829	+ 95
|		+ 95_michael
|		+ 98
|		+ 98_joel
|		+ 98_kevin
|		+ etc.
|		` 2003s
|
+	20030916	(similar)
`	20031127	(similar)

That is, one directory for each test collection and one subdirectory for each submission of it. For a new submission I create a directory, copy the results.txt into it, create a reporter.txt next to it, add it to archs in the Makefile, and make. For a new test collection I create missing.dll.txt's (presently dsound), Makefile and tests.zip in a new directory.

Changes needed at least:

1. Windows version detected automatically.
2. Tester name and contact (?) included in the results.
3. Automatically generated tags, probably simple incremental numbers.
4. Which submission should be the principal one? The first?
5. Makefile at one level higher, archs variable autodetected.

But before doing anything, we definitely need the opinion of the website maintainer. We need a very simple CGI to handle the file uploads. Presently it is < http://afavant.elte.hu/~wferi/wine/winetest.pl >. All of the present machinery is available in that directory: Makefile, dissect, gather and the other ingredients. I don't know much about web design or anything about WineHQ's inner workings. What sort of output should we produce?

I think the above is enough for a start...

I've started mulling over an agenda for WineConf, and I wanted to bounce some ideas off of everyone.

First, at the last WineConf, while it was great fun, I think there was a strong sense that there were too many 'presentations' and not enough time for simple discussions.

So, to that end, I'd like to propose an agenda that has a fairly modest number of 'presentations', but then also includes slots for structured discussions, and lots of time for unstructured conversations.

And, of course, I think a nice chunk of the unstructured portions should be done over a meal and/or libations.

I've asked Alexandre to do a keynote, and I've asked a few of you to give targetted talks. If anyone has something they'd like to present on, please let me know.

For discussions, I'd like to suggest the following structured topics:

1. Wine 1.0.
2. In search of the magic bullet - Can we transform our processes in any way to make Wine go faster?
3. Game hack fest (this could be all night Saturday, with beers)

Thoughts? Suggestions? All feedback is welcome.

I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from SuSE 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software. I tracked all problems and reported them as bugs: (1844, 1845, 1847, 1848) together with a patch for two of them.

We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken.

Perhaps we can contribute to making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE?

If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did.

I believe that it is our lack of proper ThreadingModel support in COM. We currently ignore the registry parameter HKCU\CLSID\{GUID}\InprocServer32\ThreadingModel . I believe we do that right thing in the case of that value being Apartment and the application calling CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) . However, we don't do the right thing in any of the other combination of flags. I believe the right course of action is to use stubless proxies to marshal the interface across boundaries in certain cases. These cases are listed in the books "Inside OLE" and "Inside DCOM" by Microsoft Press. Our Local Server COM also leaves a lot to be desired but that may or may not be needed for InstallShield.

This mostly affects visuals I think - the last "known good" point of InstallShield on Wine was that it did work, and installed without crashing, however it looked ugly because repainting didn't work well (due to the lack of proper interthread marshalling). There have been regressions since then though, Marcus fixed one bad one lately (in-place coercion of arguments to IDispatch::Invoke).

Ove's work on interthread marshalling has been X11 licensed and I produced a patch that merged it with WineHQ (and fixed a minor bugs and such). I think Mike McCormack has a copy I sent him, but I never submitted it. I need to do that sometime really.

"Essential COM" by Don Box is another good book, but a lot of the knowledge required is available on MSDN and MSJ articles, it's just scattered all over the net (the DCOM spec is a good reference too).

I have just compleated a full install of OO 1.1 under WINE. No outside packages are required to install and configure OpenOffice for Win32 under Wine. There are a few minor bugs with some of the strings in menus but I would rate it at 99%. If anyone is interested in a good hobby project a Winelib port of this would be nice to see.

With a little luck we may be able to have this running for WineConf under ReactOS.

Now that I have IDA nearly sorted, I was wondering.. who maintains the imagehlp dll? It seems kinda empty, and I'm sure it was at one point more complete (I looked into wine some time ago).

There are quite a few, aren't there? Full marks to anybody who can actually describe what they all monitor :)

• accel
• adpcm
• advapi
• animate
• aspi
• atom
• avicap
• avifile
• bidi
• bitblt
• bitmap
• cabinet
• capi
• caret
• cdrom
• cfgmgr32
• class
• clipboard
• clipping
• combo
• comboex
• comm
• commctrl
• commdlg
• computername
• console
• crtdll
• crypt
• curses
• cursor
• d3d
• d3d_shader
• d3d_surface
• datetime
• dc
• ddeml
• ddraw
• ddraw_fps
• ddraw_geom
• ddraw_tex
• debugstr
• devenum
• dialog
• dinput
• dll
• dma
• dmband
• dmcompos
• dmfile
• dmfiledat
• dmime
• dmloader
• dmscript
• dmstyle
• dmsynth
• dmusic
• dosfs
• dosmem
• dplay
• dplayx
• dpnhpast
• driver
• dsound
• dsound3d
• edit
• enhmetafile
• environ
• event
• eventlog
• exec
• file
• fixup
• font
• fps
• g711
• gdi
• global
• glu
• graphics
• header
• heap
• hook
• hotkey
• icmp
• icon
• imagehlp
• imagelist
• imm
• int
• int21
• int31
• io
• ipaddress
• iphlpapi
• jack
• joystick
• key
• keyboard
• listbox
• listview
• loaddll
• local
• mapi
• mci
• mcianim
• mciavi
• mcicda
• mcimidi
• mciwave
• mdi
• menu
• menubuilder
• message
• metafile
• midi
• mmaux
• mmio
• mmsys
• mmtime
• module
• monthcal
• mpeg3
• mpr
• msacm
• msdmo
• msg
• mshtml
• msi
• msimg32
• msisys
• msrle32
• msvcrt
• msvideo
• mswsock
• nativefont
• netapi32
• netbios
• nls
• nonclient
• ntdll
• odbc
• ole
• oledlg
• olerelay
• opengl
• pager
• palette
• pidl
• powermgnt
• print
• process
• profile
• progress
• propsheet
• psapi
• psdrv
• qcap
• quartz
• ras
• rebar
• reg
• region
• relay
• resource
• richedit
• rundll32
• sblaster
• scroll
• seh
• selector
• server
• setupapi
• shdocvw
• shell
• shlctrl
• snmpapi
• snoop
• sound
• static
• statusbar
• storage
• stress
• string
• syscolor
• system
• tab
• tape
• tapi
• task
• text
• thread
• thunk
• tid
• timer
• toolbar
• toolhelp
• tooltips
• trackbar
• treeview
• ttydrv
• twain
• typelib
• uninstaller
• updown
• urlmon
• uxtheme
• ver
• virtual
• vxd
• wave
• wc_font
• win
• win32
• wineboot
• winecfg
• wineconsole
• wine_d3d
• winevdm
• wing
• winhelp
• wininet
• winmm
• winsock
• winspool
• wintab
• wintab32
• wnet
• x11drv
• x11settings
• xdnd
• xrandr
• xrender
• xvidmode