Where is Wine going? There are some messy areas, says Czekalla. One of these is its Component Object Model (COM) implementation. After years of work, it is still not done and is at least six months away from being able to talk to a Microsoft Exchange server.

Right now about 70% of programs can install with Wine's implementation of the Microsoft Installer (msi.dll) library. In another year, Czekalla expects that number to be about 90%, though he pointed out that while most programs that install will work after being installed, there is no guarantee. One problem Wine has had is with the device-independent bitmap (DIB) engine. At the moment it supports only 24-bit color depth graphics, but many Windows programs still use only 16 bits. He described this as a problem with X.

Because Wine is a userspace program, and cannot see hardware, things such as USB devices (like a USB key) cannot be directly seen by programs running under Wine. An effect of this, he says, is that programs requiring Digital Rights Management (DRM) will not work under Wine and won't unless and until Linux gets native DRM support. Companies that use DRM, he said, are not willing to help. He gave the latest version of Photoshop as one example of a program that has implemented DRM and will not work in Wine.

I am pleased to announce that Rob Shearman has arranged for us to have Wineconf in his home town, Reading, in the UK. It will be held at the University of Reading:

http://www.fmd.rdg.ac.uk/res/CommercialAccommodation.asp

It will be on the weekend of September 16 and 17.

We have a wrinkle we need your help on. That is, as we make our deposit (which we need to do quickly), we have to tell them how many rooms we want to reserve.

The have a good deal on rooms (40 pounds/night, which is quite good, afaict).

The trick is that we have to pay for all the rooms we reserve ahead of time; we can't ask for 50 rooms and then only use 43. We have to pay for all 50.

We may be able to ask for 50 rooms, and then get another 3 or 4, although that's not guaranteed.

So, *if you want a room at Wineconf*, please fill in this form ASAP:

http://www.winehq.org/site/wineconf/survey06

If you're not sure you'll make it, but think you might, we have a choice for that too <grin>.

Act now or you'll be sleeping in Swindon...

As SerNet and the Samba team has invited me to SambaXP, I thought I'd give a short update on what happened here so far that is interesting for Wine.

The talks today were only mildly interesting from the Wine point of view, but that chatting with the Samba folks in the breaks was really productive.

I've talked to Steve French about exposing named pipes as file descriptors or fifos and he thinks that should be doable. I have to admit I'm not totally sure what those beasts are needed for, but Juan asked me to bug Steve about. I guess his talk about using CIFS on linux will be interesting, too.

On the SSPI/GENSEC side, I've talked to Andrew Bartlett and Jelmer Vernooij about isolating GENSEC from the Samba code a bit more so it's useable without pulling in too much of the other Samba code (which is also GPL and not useable). They don't seem too happy about releasing GENSEC under the LGPL either, but seem to prefer that to other, less elegant solutions like a wrapper library or a stdio interface.

On the bright side, I managed to get Wine code to compile with GENSEC using some quick hacks. That brings me a bit closer to a proof of concept implementation the Samba people want to see.

The schedule for tomorrow will see more technical talks, and I'll continue to hack on wine-gensec a bit, and of course I'll try to give another report from the conference.

Now that SambaXP is officialy over, the samba team a couple of other people have retreated to a smaller room to discuss other things.

Steve French had a talk about using CIFS on linux as a replacement to NFS which seems to be pretty cool. A couple of other talks were given, too, but if you're really interested, have a look at the schedule.

What was more interesting was that after the talks there was a panel discussion where the samba team expressed interest in continuing cooperation with Wine as discussed on last year's wineconf.

Steve asked how exactly we wanted the named pipes exposed and if we could write up some testcases for that stuff. I think if anybody is interested in working on that is to email Steve directly.

I got some more work on GENSEC done, but in order to really link this together, some more work is needed. I still have things blowing up on me when trying to use it for client-side sspi.

There are 3 things that Samba could do to help Wine:

1. Expose SMB operations in a library, including named pipe operations. The library functions exposed would ideally be similar to the Win32 functions, i.e. ConnectNamedPipe, CreateFile, ReadFile, WriteFile, CloseHandle, etc.
2. Expose an API that would allow Wine (and other applications) to register an endpoint in the Samba endpoint mapper. This API would be along the lines of samba_epm_registerep(UUID *object_uuid, char *protocol, char *endpoint), and a corresponding unregister function.
3. Create a server that would contain interfaces necessary for DCOM (specified in the draft RFC), plus some other interfaces, like the running object table and ways of registering objects to allow them to be activated. Ideally, these would be compatible with Windows to allow ole32 from NT to be used, but that would require reverse engineering some of the interfaces.

I've updated http://wiki.winehq.org/SummerOfCode, but it's a bit short on project ideas. Somewhat on purpose -- last year, people just copied and pasted our detailed project ideas. This year, lets give fewer details and more ideas... if somebody's really interested, they'll ask for details on wine-devel, and that process will generate fewer boilerplate applications.

There are two weeks before students can submit Summer of Code proposals. How can we use that time to maximize the number of successful projects this year? The students who already have their own good ideas (whoever they are) will probably succeed; we probably need to provide a set of prefab projects of sorts to give guidance to students who are new to Wine and haven't any idea what to work on.

Ideally, each such prefab project would have an active developer (or a close approximation) as project leader and mentor. Are any developers willing and able to come up with a project idea and help mentor/supervise a student to work on it?

Yes. See http://wiki.winehq.org/DIBEngine for more information on this.

This is probably feasible as a SOC project *if* you are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it.

Alexandre has very specific ideas about how he wants a DIB Engine done.

Integrating a DIB engine into your own tree may not be too difficult. The hard part is integrating it into the Wine tree in small pieces without breaking everything else and keeping Alexandre happy as you go.

Various projects have re-implemented the code necessary to host Win32 DLLs in-process, for instance Xine, MPlayer and GStreamer all have (different) forked, badly hacked copies of the Wine codebase inside themselves to load and use codec DLLs. The GIMP now has the ability to use Photoshop plugins using Wine. And so on.

It'd be nice if there was a simple API programs could use to do this, for instance, wine_dlopen("whatever.dll"), wine_adopt_thread() and so on to make re-use of Win32 components and COM objects easy.

This has been discussed before and Alexandre wasn't sure it was worth it as it'd be a significant extension to the (stable??) Wine APIs, so IMHO this one shouldn't be judged on whether it gets checked in or not but rather whether it works and how easy it is to use.

Thoughts? I know roughly what needs to be done so I could mentor this one, but students be warned - it requires _excellent_ understanding of operating system design and things like threading. There's a reason such a thing doesn't already exist, and it's because it's hard. On the flip side it's not a massive amount of code IMHO so the work would mostly involve learning, debugging, etc rather than simply being a hard typing slog.

Also, a student has all summer and the nice thing is, it's mostly generic computing knowledge that'd be useful for future work (whereas learning a specific api in depth probably isn't ...).

Such a thing has many uses:

• Hosting ActiveX controls inside a native Firefox
• Allowing more apps to use plugins from popular Windows apps. GIMP is a bit weird in that its plugin system is out of process and has a simple wire protocol .... a hangover from the days before ELF (!!), but most programs aren't like that. EG imagine being able to use WinAmp visualizion plugins in your music player of choice.
• Maybe getting the xine/mplayer/gst mess sorted out a bit (on the other hand they need to run only a small, relatively unchanging amount of code so it may not be worth it)
• Allowing piece-by-piece porting of a modular Windows app without Winelib (which is annoying as you have to switch toolchains all at once, you may not even have the sources to some DLLs etc ...)
• Actually there is a huge component marketplace in Windows which is especially rich in the boring sort of business components (grid views etc) that open source hackers tend to ignore ... this could allow developers to embed some of the very sophisticated Win32 business objects into native Linux apps, so reducing development costs (of course the result would not be free software, but for in house custom apps that's not really a concern anyway)

I'm sure you can think of some more. Discuss! :)

I would like to propose the SafeDisc Project for wine.

Main Objective: Support for SafeDisc (basically ver 1 Support) Part 1 (Getting the basic IRP support)

Secondary Objective: Have wine specific ntoskrnl.exe that handles this

Requirements: Needs to have in depth knowledge of Win32 Internals as well as wine server internals.

Difficulty: Moderate to High

Mentors: Vitaly Margolen(vitamin) and Alexander Julliard

Details: To implement the SafeDisc Support. The progress and details can be found here

http://wiki.winehq.org/VitaliyMargolen

A lot of applications rely on Sun's JRE, some even use it in their installers!

(cf. http://bugs.winehq.org/show_bug.cgi?id=5040 )

Getting Sun's JRE working properly on Wine would be a great project.

wcmd isn't thought of as sexy, but it's important; for instance, some installers use it under the hood.

Things like

if "%1" == "%2"

and the /wait commandline flag are not yet implemented. It wouldn't be all that hard to get wcmd far enough along to make those installers happy; I think it'd make a good SoC project.

Another potential proposal for SOC would be upgrading valgrind to work with Wine.

I've tweaked it a bit (some patches still floating around), but:

• that's not complete (some items still don't work)
• what's also completly missing is the support of native modules (especially when generating backtraces)
• 16bit support (but we can safely leave it out for now)
• and testing (and fixing) most of the implementations we have

I've updated the Wiki page accordingly.

It would be really good for valgrind know about our heap implementation so that it could report memory leaks. A solution I've done in the past is to change all of the references to HeapAlloc/HeapReAlloc/HeapFree to malloc/realloc/free so that it can report leaks, but that isn't very convenient.

I think that is something that could benefit Wine a lot and wouldn't require very much Wine knowledge at all (although, it could require some knowledge about valgrind).

We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts.

So I have a couple of questions.

Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this.

Should These bugs marked a duplicates? [1]

• http://bugs.winehq.org/show_bug.cgi?id=2389
• http://bugs.winehq.org/show_bug.cgi?id=4162
• http://bugs.winehq.org/show_bug.cgi?id=5052

I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins.

From a trace, the margins are getting set to 2 in EDIT_WM_SetFont(), with the call:

EDIT_EM_SetMargins(es, EC_LEFTMARGIN | EC_RIGHTMARGIN, EC_USEFONTINFO, EC_USEFONTINFO, FALSE);

Commenting out that single line makes the Xilinx installer work fine. Not that it is the correct fix ;)

I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.

Another interesting thing is that when it does set margins they are often not symmetric left/right (although you tend to have to use larger font sizes to see this) - it's presumably using some pair of font metrics to set these and despite spending quite a while hunting I drew a blank.

Now your problem could simply be that you don't have the font that the app wants to use in this edit control. It'll create the edit control with a size that would work with that font under Windows (and probably also under Wine), however if you don't have that font and Wine picks one which ends up being slightly larger then you've got a problem. It's difficult to know how to fix this. The other possibility is that you have the correct font but the '**' algorithm is slightly wrong (it is) and that you're right on the edge of it kicking in.