World Wine News

It basically involves implementing the ICreateTypeLib interfaces in our OLE dlls. Nyef did some great work on this but for stdole32.tlb we need the other version, I think.

Once this is done maybe we can pull the stdole32.tlb generation program used in CrossOver upstream. Right now it's pretty useless for Wine as it has to be run on Windows to work.

The ICreateTypeLib2 interface is used to create the new-style MSFT typelibs. The older ICreateTypeLib interface is used for the old-style typelibs. While the newer interface also implements the older one, when you ask for the old interface with CreateTypeLib() you get a completely different implementation.

I don't see why it necessarily follows that stdole32 wouldn't work as an MSFT typelib, but the implementation of ICreateTypeInfo2 is badly incomplete in places, and I would trust it to completely mess up any semi-complex type library you attempt to create with it. Specifically, any type library that involves functions or variables.

After a quick google search. I don't know if this will give you all the information you need but it does have a sample program that can do simple dumping of typelibs.

http://www.microsoft.com/msj/0399/comtype/comtype.aspx

A book I have described how it works...

The Windows scheduler is in its most basic form remarkably similar to the scheduling policy known in Linux as SCHED_RR, with a few "enhancements". For example, the thread owning the foreground window gets a priority boost relative to other threads in the system. There's also some stuff in there to help deal with the priority-inversion problem known to real-time programmers, I think. (When a low priority thread can keep blocking the execution of a high priority thread by holding a lock the high priority thread needs, with the result that medium priority threads get to run but the high priority thread does not, it's called priority inversion, if I understand right.)

Also note that Windows allows a Win32 process to boost its own priority all the way to what they call "real time". Only root can do this under Linux. I'm not sure if you need administrator privileges to do this under Windows (probably not), but since every Windows user runs as administrator anyway, it's probably not unlikely that many applications expect this ability anyway.

Internally, Windows assigns each thread a priority, determined by process priority class, thread priority class (all programmatically set), and some other factors such as whether it's running in the foreground (owns the foreground window) or not. Threads with the same scheduling priority are scheduled round-robin. Threads with higher priority preempt anything with lower priority, so that lower priority threads will not get to run as long as a higher priority thread is runnable. It is of course recommended and assumed that applications use high priority only for threads that won't use much CPU, since if they do, execution of that thread will block all threads with lower priority than itself.

The book described no kind of dynamic scheduling based on how much CPU time a thread is spending, only the aforementioned "is in foreground" thing. Does imply that a Win32 app running an infinite loop could run fine in the background, but would hang the system if brought to the foreground, I think (assuming Windows doesn't see that it has hung, which it probably checks by seeing if it responds to messages).

As decribed here:

http://www.winntmag.com/Articles/Index.cfm?IssueID=22&ArticleID=302

There are 31 priority levels and only users with Administrator privileges can set processes to the highest priorities of 16-31. I doubt there are programs that require these high priorities, although we could find potential targets by printing a message for programs that try and set their priority to a high level.

OK, so you need administrator to set a realtime priority, but you are still able to set a high priority on yourself without being an administrator under Windows. This is not possible under Linux, where a non-root process can only reduce, not elevate, its own priority.

For what it's worth, at TransGaming we know for a fact that some games (maybe it was Battlefield 1942) does; they elevate the priority of one of their most critical threads, and seem to use interesting mechanisms to regulate how much time this high-priority thread uses relative to the other threads. In any case it does help the game's smoothness to experimentally elevate this thread's priority under Linux, but this is not really a solution because of permissions.

we still consider 2.6 too unstable to support the use of, but the problem is probably related to what's being discussed here, which is why I'm interested.

One interesting problem we've seen is the one of wineserver using a whole lot more CPU now than before. A scenario where this could happen is if the game has a relatively low-priority thread which gets to do a lot of waits on critical sections, and some high-priority threads that does interesting stuff, also usually holding those critical sections, so there's always contention. The game might not care much exactly how often the low-priority thread gets scheduled, as long as the resource protected by the critical section is not in use whenever it does get scheduled (which it probably usually isn't if the Win32 thread priority system is used).

Well, my theory is that in this situation, with the great new interactivity-boosting Linux scheduler, the wineserver is considered very interactive, and gets scheduled a lot more than the high-priority threads, just so it can satisfy the wait requests of the low-priority thread.

This particular situation is a problem which the shared-memory wineserver we have in Cedega now should help somewhat against, I suppose, but that probably doesn't make this problem less interesting for you.

And of course there are threads we use that gets penalized a lot. For example, the DirectSound mixing thread would by no means be considered interactive by the scheduler. We would love to elevate the priority of this thread, for example, but it's not possible because of permissions.

To be honest, knowing how linux manipulates priorities dynamically and that more of the OS is threaded at different layers from windows, it is a miracle than any of the high performance gaming might run smoothly.

Audio runs as a separate thread outside of wine potentially through who knows how many layers as a combination of both process and kernel context so that's already complicating the issue by having a separate thread. X does the same again. So what the win32 game is doing under wine when it asks for audio or graphics to be done will be handled completely differently to windows. How blocking is done between the graphics and audio calls, when you have a highly cpu bound task (the game) as well is definitely complex and not just the kernel that is responsible here. Add to that the fact that wine itself runs a few threads and as I said before, it's a miracle it runs smoothly at all.

After much talk, the patch seems ready for commit. Since there are many systems with slightly older glibc that have the header but do not have the implementation in glibc, or that have a stub implementation that is guaranteed to fail, we are calling the kernel functions directly. This also allows compiling on older systems than the code actually ships to.

Accordingly, the autoconf checks for epoll_create in glibc were dropped.

ChangeLog:
Shachar Shemesh
configure.ac
configure
include/config.h.in

• Detect whether the sys/epoll.h header is available

server/fd.c

• Change the type of the poll_users list to also keep track of the state of the node. Change the fd pointer to a union for better implementation of free list without casts.
• Switch to relying solely on the free list to determine where our next free node is at.
• Switch the freelist to use integer offsets into poll_users, rather than pointers. The list can now be realloced without being invalidated.
• Implement epoll waiting over the same infrastructures

Guys, pretty pretty please, just use the glibc function, add a regular configure check and use it if it does not return -ENOSYS.

All this confusing handling of dlopening etc etc is way overblown.

I'm going to play with the richedit control to try get it to draw RTF documents with formatting. My plan is to write a program that can display but not edit, then let somebody else add the editing functionality afterwards :) Once I can get the attached program to work, the plan is to change the code in text-writer.c to add the formatting information to the richedit control via standard richedit messages. If anybody is already working on it, or wants to have a go, let me know.

We are currently porting Wine to Mac OS X. Currently Wine has a display driver for X11, and we would like to continue to use it for the Mac OS X port: to display the GUI interface, we don't need the Aqua UI elements since we prefer to use Windows theming system, and given the complexity and amount of work done in x11drv . But we also would like to be able to build something that behaves like a normal Carbon or Cocoa App, with a Dock Icon, and a Menu Bar, which would be managed by some Carbon code in Wine itself.

I had a look to the X11CallCarbonAndCocoa [1] sample code, but the trouble is that the X11 window still belongs to X11.app, a mouse click in the Dock to get the App's Windows to the front doesn't work for the X11 Window, and the menu bar for this Window is still the X11.app's menu bar. So I'd like to know if there is a way for the Wine Carbon instance to own the X11 Windows Wine created. At least it would be a feature that we'd like to see :)

I have some questions about Wine and how/if it can be used with industrial communication like OPC (Microsoft Com/DCom objects, DDE and more)

My short question is: Can I use Wine to make OPC communication work on a Linux system?

OPC "OLE for Process Control" A "general" standard for communication in industrial systems, that unfortunately is totally depending on Windows(DCOM)

On www.opcfoundation.org there are some companies who have made Unix OPC clients, but the license costs are high. There is also OPC true XML that is now a real product, that looks promising.

I'm in need to make/use some kind of OPC api (Wine DCom) for Linux, an api like that would make many company's in the industrial computer interested. Or as a backup I could have a Win program running in Wine on the Linux machine talking with the main app on the same computer and talking OPC to other machines that need that.

I hope Wine and/or you can help me in this case. It would be a tragedy if we had to switch operating system just because of this.

Answer: almost certainly yes, with a catch:

1. Wine's current builtin DCOM is not up to scratch for what you want, and it will take a long time to get there. Really, given how unglamourous network DCOM hacking is and how few people have worked on it, it's unlikely to happen until funding is available.
2. So ... you'd have to use "native" DCOM. This is a redistributable that can be downloaded from microsoft.com and installed into Wine. You'd have to read the EULA very carefully but I suspect you need a Windows license in order to use it.

However, even if you do, simply buying a copy of Windows then throwing away the box may actually still be easier than switching your project to another OS entirely.

I think it may have been used for Exchange5/Outlook connections, but you are right in that I don't know if this works.

Wine's sockets support is good though, far better than its builtin DCOM. Based on what I know of the DCOM network protocol, I don't think we'd have any problems with it.

Only issue would be if you needed NT only features, as only DCOM for Windows 98 works natively on Wine.

Off the top of my head, I can't think of any big issues. Maybe dcomcfg doesn't quite work yet etc, but fixing any problems that arise would be much easier than migrating to a totally different OS, or bringing our own DCOM up to scratch

I can think of a couple, but they may be able to be worked around:

• incoming connections (DCOM servers) won't be supported. If this guy's clients are going with WinCE that won't be an issue, it doesn't support them either AFAIK.
• only DCOM over TCP is likely to be supported. DCOM over named pipes definitely wouldn't be.

The reason I've backed off from this is that it's hard to do correctly, and anything less than completely correct isn't going to be accepted by A.J. Ideal for us would be a file descriptor that we can do atomic operations on; that'd be duplicable like the rest of our handles. Not sure how we'd get that from smbd (see below for a different idea), and Samba3's public API is too high-level to be of much use to Wine. (Samba4 might be better.)

The ports issue prevents us from receiving connections, i.e. acting as a DCOM server. This is probably less important than being able to act as a client, at least for a while.

I asked Steve French (Linux CIFS module) whether he'd consider exposing named pipes in the Linux filesystem. He said he would, then asked me whether I'd given any thought to naming convention. I hadn't and I haven't had as much time to experiment with this of late, so I haven't responded. This method would allow us to act as a CIFS (TCP port 445) client. Acting as an SMB (TCP port 139) client isn't handled by the CIFS module, it's done by the SMBFS module. Not sure what Steve's plans are here.

Anyway, any of you guys interested in seeing RPC work under Wine (Greg, you still lurking around here?) might want to play around with this if you have time. I might myself once I land somewhere for a while, but no promises.