Why do we bother with DllCanUnloadNow?
Is there a specific reason for implementing this function anymore? The resource savings don't seem worth the new potential for bugs. If all of them were simply returning FALSE then what would be the loss? thanks -mike
Re: WineConf this weekend
I'll ask Lucy about videos tomorrow. I don't know how long we can record using the Google equipment but we make videos pretty regularly, so an unedited video stream might be plausible. Otherwise if somebody has a camera they want to bring along, feel free ... don't trust me to get video-recording sorted at this stage :/ On 10/2/07, James Hawkins <[EMAIL PROTECTED]> wrote: > On 10/2/07, Mike Hearn <[EMAIL PROTECTED]> wrote: > > Hello, > > > > If you're on the wineconf mailing list, you already received all the > > details for this weekend. If you weren't planning on coming, but are > > near Zurich and want to tag along anyway, feel free! We'll be on the > > 5th floor of Freigutstrasse 12: > > > > http://maps.google.com/maps?q=freigutstrasse+12,zurich > > > > Hope you see you all there! > > > > Hi, > > Speaking on behalf of those that can't make it to WineConf this year, > will someone be taking notes or A/V? It's bad enough that we can't > join everyone at the pubs, but it's even worse that we miss the > information exchanged during the discussions. > > Thanks, > James Hawkins >
WineConf this weekend
Hello, If you're on the wineconf mailing list, you already received all the details for this weekend. If you weren't planning on coming, but are near Zurich and want to tag along anyway, feel free! We'll be on the 5th floor of Freigutstrasse 12: http://maps.google.com/maps?q=freigutstrasse+12,zurich Hope you see you all there! thanks -mike
Announcing WineConf 2007
Yes, it's true! The moment you've all been waiting for! On 6th/7th October, once more Wine hackers from around the world will meet to eat, drink, make merry, and discuss the finer details of reimplementing the Windows API. This year it's Googles turn to host it, and it'll be at the engineering office in Zurich. You too can chill out with these awesome froods by signing up for the wineconf mailing list, and surfing over to: http://wiki.winehq.org/WineConf2007 ... which is currently a bit sparse but will populate nearer the time. Fascinating talks! Interesting people! Hackfests galore ... and maybe even fondue! 6th/7th October. Be there or be square.
Re: Wine and menu integration
Hi David, Sounds great! To submit those files, you need to make a patch ... git can do this but I don't remember the exact command to use (depends on your setup also). Or you can do it the old fashioned way using diff directly. Feel free to ask if you'd like more guidance with this. Once you have a patch, email it to [EMAIL PROTECTED] so Alexandre and the others can review it, suggest improvements etc. Good luck! On 2/15/07, David Saez Padros <[EMAIL PROTECTED]> wrote: Hi !! I saw your post at http://wiki.winehq.org/GnomeMenusIntegration and i made some freedesktop compliant files which: - add a global Wine menu item in the Aplications menu (seen by all users) with WineFile and WineMine, which also merge all user specific wine installed programs. - add a global menu item for winecfg in System -> Preferences (seen by all users) I also have what should be add to installation so .exe files are executed with wine when double-clicked (tested in ubuntu) How could i submit those files ?? I cannot din anything related to this in the bugzilla :( -- Best regards ... I am Homer of Borg. Prepare to be assim... , donuts. David Saez Padroshttp://www.ols.es On-Line Services 2000 S.L. e-mail [EMAIL PROTECTED] Pintor Vayreda 1 telf+34 902 50 29 75 08184 Palau-Solita i Plegamans movil +34 670 35 27 53
Re: Update RelayExclude and add RelayFromExclude filter in order to avoid not useful APIs in the traces
On Thu, 19 Oct 2006 06:28:28 -0600, Vitaliy Margolen wrote: > Please don't. Kernel32 is the source of all core functionality. As well > as winex11drv, user32 and gdi32. No this will generate more broken bug > reports. Kernel mainly calls into ntdll these days so you see a lot of wrapper API calls that don't add much useful info.
Re: use wine as screensaver for x
Yep, I've done this before but it was an evil, awful hack and I don't have
the patch anymore (probably just as well) :)
The way I did it was just to redirect the first created window, but again,
it was hacky. Hopefully you can find a better way.
On Thu, 19 Oct 2006 00:04:39 +0200, Detlef Riekenberg wrote:
> Hi.
>
> While waiting for the commit of my localspl-Patches,
> i want to picked up an fun project:
>
> Has anyone an Idea, how to modify "user32.dll" and
> "winex11.drv" to open a Window, when I already have the
> X11 Window-ID (example: XSCREENSAVER_WINDOW=0x280020)?
>
> My Idea is to include the wrapper code in explorer.exe
> and use similar code as already present for "/desktop".
>
> The Window width and height is not known on startup
> and does not match a well-known Desktop Size.
> I think, I need to add an Export to winex11.drv to fetch
> the size and reuse "X11DRV_create_desktop()" or add an Export
> to someting similar as "X11DRV_create_desktop()".
>
>
> The client registers a Window Class with a known name
> ("WindowsScreenSaverClass") and then CreateWindowEx must be
> redirected to the already created X11-Window.
>
> A lightwight solution might be to implement minimal features
> from "scrsave.lib" (RegisterClass) in "explorer.exe"
> and then call "ScreenSaverProc" directly.
>
>
> Any Ideas?
Re: Execution Trace of Application in Wine
On Mon, 23 Oct 2006 11:59:57 -0400, Sujata Doshi wrote: > I know I could manually single step via winedbg but I would like to > automate this process. WineDbg just uses the debugger APIs like any other app. So you could write your own program that uses the debugger APIs to do this. thanks -mike
Re: Run-time error 445
I usually do a +msgbox,+ole,+olerelay trace to get a basic idea of what's going on here, moving up to +relay if necessary. If it's Visual Basic stuff most likely you can see what's going on by monitoring OLE Automation. Good luck! -mike
Re: Should I give up?
On Wed, 06 Sep 2006 04:25:02 -0700, Damjan Jovanovic wrote: > I've submitted a test and patch to wine-patches 7 > times now, and received very little feedback, which > I've always followed. It may be just that Alexandre is a bit overloaded ... have you tried chasing him in IRC about it? Vitaliys feedback seems sound but if Alexandre really objected to those issues he'd probably have let you know. I suspect it is somehow slipping through the cracks (maybe a spam filter). Please don't give up! We've all been in this situation, it is not much fun I know ... thanks -mike
Re: RFC: XEmbed Systray Patches
On 8/15/06, James Liggett <[EMAIL PROTECTED]> wrote: Just FYI--I figured out what was wrong with my X test app. I just needed to set some size hints on the window, and now the size is perfect when the window docks. Now I've got my test app, a GNOME program, and some wine apps all peacefully coexisting on my tray, and they all dock perfectly. Guess there wasn't a bug in GNOME after all... ;) Great work! Now let's hope Alexandre accepts it.
Re: RFC: XEmbed Systray Patches
On 8/9/06, James Liggett <[EMAIL PROTECTED]> wrote: way to handle it. What we need to do is get the extended style of the window, but this seems to involve a bunch of wineserver calls that I'm not familiar with. Can you help me out on that? Thanks! You can always stick some needed field in the X11DRV private data (you can see how to access that in the code itself). I'm not quite sure about that one--I've got an X test app that docks, but I can only get 1 pixel wide. :( On wine, this isn't a problem though. Still trying to figure out what I need to do. Oh dear :( Maybe you should ping one of the GNOME guys? thanks -mike
Re: RFC: XEmbed Systray Patches
On 8/9/06, James Liggett <[EMAIL PROTECTED]> wrote: Actually, I don't think it has to do with synchronization--I think it has to do with window mapping. Ah awesome, good work! I know when I looked at this originally it seemed you could set a flag that told the embedder whether it was already mapped or not, maybe that doesn't work properly. There was also a problem where a window would dock but only be allocated 1 pixel, I think that was a bug in GNOME that is now fixed. Hopefully we can nail this all finally. thanks -mike
Re: RFC: XEmbed Systray Patches
On 8/7/06, James Liggett <[EMAIL PROTECTED]> wrote: Turns out you're right, Mike. If I add a small (2 ms) sleep after the dock event is sent, things work perfectly. :) But, this really strikes me as a hack that doesn't stand a chance of getting into Wine. Is there a better way to slow down the execution of this code. It's not that we need to slow it down - slowing something down is never an acceptable solution to a race. We are missing some kind of synchronisation somewhere, or perhaps we are doing something funny to the window immediately after we try and dock it, which causes it to undock. You need to trace exactly what happens to that window after it's docked. thanks -mike
Re: RFC: XEmbed Systray Patches
On Sun, 06 Aug 2006 20:10:19 -0700, James Liggett wrote: > so I suspect that this has something to do with stack problem More likely it's a speed issue - logging slows the code down a lot which could "fix" a race condition. X is sort of susceptible to this kind of thing it seems.
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
On Sat, 05 Aug 2006 10:32:15 +0200, Alexandre Julliard wrote: > Still, doing that stuff in APCs is a step in the right direction, you > just need to make sure you can safely run these APCs from the SIGUSR1 > handler. How is the thread to interrupt to be selected? I really am not seeing what's wrong with a service thread here, it seems the safest and simplest way forward. We can easily put it into stealth mode by disabling the attach/detach notifications. thanks -mike
Re: ntdll: CreateRemoteThread and friends for remote processes, take 3, via APCs
On Thu, 03 Aug 2006 02:08:26 -0500, Thomas Kho wrote: > APCs are queued per-thread, so I made minimal changes to add a per-process > APC queue. Of course, this implementation suffers from the limitation that the > remote process must go into an interuptible wait for the operation to succeed; > an operation targeting a suspended process would block. I'll let Alexandre do the review this time. Just one thing - can you try it with something copy protected? I think some programs rely on being able to CreateRemoteThread into a program that runs all the time and never sleeps (eg games that try and get the highest FPS possible). thanks -mike
Re: ntdll: CreateRemoteThread and RtlCreateUserThread for remote processes, take 2
On 8/3/06, Dan Kegel <[EMAIL PROTECTED]> wrote: The goal is to get rid of the service thread; the service thread was just there as a placeholder. Once it's gone, signals are appropriate. The realtime signal is just there as a placeholder until we figure out how to squeze this down into SIGUSR1 and SIGUSR2. Hm so you'll have to co-ordinate switching the signal mask between threads as they start up and shut down? I'm not sure that can be done atomically. thanks -mike
Re: ntdll: CreateRemoteThread and RtlCreateUserThread for remote processes, take 2
On Tue, 01 Aug 2006 20:41:54 -0500, Thomas Kho wrote: > This is an implementation of CreateRemoteThread and RtlCreateUserThread for > remote processes that re-introduces a service thread for each process and uses > a signal to flag pending operations. Operations are guarded by a global mutex > for each process. Hey, great, this is a big improvement on last time. Still I have a few questions about the approach: - The service thread seems like a good idea to me. But why use a signal in this case, when there are simpler ways to achieve the same thing, for instance with a named pipe? - I'm not sure using the realtime signals will work. I don't remember the details, Alexandre is the signals guru, but I remember them being "awkward" - There is a lot of stuff to handle the global mutex. Why is this necessary? I'm afraid I really don't see where the lock is needed here; if you were using a pipe then the service thread would serialize the requests in its main loop - Writing to a remote process by taking the address of a variable in the current one?! What if the DLLs are located at different base addresses? I know this is unlikely to happen in Windows but on Linux we have ASLR and they introduced this for Vista as well. Assuming a pointer that is valid in one process is also valid in another is not a good idea, in general. And there are a few small style nits, for instance there's usually no reason to change "void *foo" to "void *foo = NULL", you want it to remain uninitialized because that way the compiler will warn if it's ever used before being set to something: superior to blindly using a NULL ptr with no warning I'm sure you'll agree. Also watch the code style - internally Wine tends to use unix_style not hungarian notation, which is usually confined to the API definition itself. Anyway, assuming Alexandre concurs with what I've said, here's where you want to go next: * Drop the signal, and use a named pipe instead * This should let you drop the global mutex and WriteProcessMemory calls, I think? thanks -mike
Re: Audio stuttering issue
On Thu, 27 Jul 2006 15:05:12 -0700, Chris wrote: > It does. You don't really have to change anything. I thought the user would have to change the limit in their startup scripts or the like? That isn't going to work, we need it to be fully automatic with no configuration changes needed. > RLIMIT_RTPRIO value for the user. I just think it'd be nice to let users of > that patch know they don't need to run Wine with root privs if they don't > want. Sure, we should add it to the wiki page or something ... > I personally don't see what's wrong with letting the user decide. > Without setting the suid root bit, Wine won't get any more privileges > than any other Linux app run by the same user would get. Well, using the suid-root bit seems more secure than this ... the limit allows any application to gain realtime privs easily whereas having wine acquire CAP_SYS_NICE means only Windows apps can get it (or rather it's very hard for other apps to use Wine to get it). thanks -mike
Re: Audio stuttering issue
On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote: > Or if you still don't want something like that merged in, I'd like to alert > the author of that patch that it doesn't require root privs to work. It just > needs a non-0 value for RLIMIT_RTPRIO (ulimit -r). Thanks for the heads up. I'll let Alexandre comment on the other stuff but I wanted the patch to work out of the box for all users, with no configuration necessary. I don't see any way to resolve this issue satisfactorily. Windows apps require hard real time support, the kernel won't give it to us without privileged access, Alexandre doesn't want to let Windows apps do that. So it seems we lose (unless somebody conjures something that works just as well as that patch does, which so far hasn't happened). thanks -mike
Re: ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
On 7/16/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: Cloning a new thread is not going to help with this at all, since it still uses the Win32 context of the original thread, so it only makes things worse. What then is the solution? A service thread? I think it'd be OK to have the hijacked thread be holding a lock, as CreateThread doesn't seem to wait on the newly created thread anywhere. thanks -mike
Re: ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
On 7/16/06, Dan Kegel <[EMAIL PROTECTED]> wrote: I'd rather not take the chance of doing anything that messes with the poor thread we're hijacking.Hmm... http://lwn.net/Articles/7577/ makes me think that converting a linux thread to a win32 thread might require initializing the thread's TLS area. We'll look at that a bit. Basically everything along the Wine CreateThread codepath setting up a server connection, registering it with the server, initializing the TEB, signal setup, synchronizing the Wine VM list with the Linux VM list, allocating a guard page, doing thread attach notifications and finally calling the entrypoint inside a SEH backstop handler. Quite a lot of work, really, so I think it's easier to create the thread from another Wine thread somehow. thanks -mike
ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
[forgot to hit "reply to all" instead of just reply ...] On 7/15/06, Dan Kegel <[EMAIL PROTECTED]> wrote: The right thing to do would be to promote the linux thread to be a win32 thread, but as a temporary stopgap, Thomas had the linux thread just do CreateThread and exit, hoping that the newly create Windows thread was healthy. Well, I think calling CreateThread directly from the context of the hijacked thread would be simpler, though I understand that gets hairy as well if the hijacked thread is holding (say) the loader lock Maybe we should look more carefully about what it takes to build a normal, healthy win32 thread from a posix thread. This has been looked at in the past for sure, but I'm not sure if it's documented anywhere. Well, kind of. Signals are only delivered when syscalls return, so they won't work well if the thread you pick to molest happens to not make any syscalls for a long time. Hm, really? I haven't come across this before ... how then is it possible to debug a program that is sitting in while(1); if SIGSTOP cannot be delivered? Also we already use SIGUSR1 to suspend a thread and that has to work at any point, so maybe it might need to be changed. > You don't preserve the register state. Really? What's ptrace(PTRACE_GETREGS, pid, NULL, regs) then, chopped liver? :-) Oops, my mistake! Sorry Thomas, I didn't see that. If you switch EIP to a register function though you get all this for free ... Well, if Alexandre thinks that's the way to go, that'd be fine. I thought those only fired when the thread in question performed an alertable wait condition (so says http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp ) so it didn't seem like an obvious way to go. Right but if the thread is suspended then it's waiting, and we could maybe hack it to do an alertable wait. Though doing an alertable wait during a suspend is surely the wrong thing to do in most cases, presumably the server could easily queue an APC itself but not allow other clients to do the same. thanks -mike
Re: ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
Heya, First of all 'mad propz' to you for tackling this. I have no strong opinion on whether this approach of hijacking a thread is better than having a service thread, that's Alexandres call. But a few comments on the way you've done things here: I don't think there's any reason to use Linux specific syscalls to do this. IMHO it can probably be done using only Wine provided APIs and infrastructure. I am not how this works. You create a new "raw" kernel thread using clone, then run NT code using it. But that isn't valid and may not work - only threads created by Wine may use Win32. You are using ptrace instead of signals. That seems over complex - signals are designed to interrupt a thread and have the necessary support to restart syscalls, preserve registers etc. I know both SIGUSRs are taken but SIGUSR2 is currently used for the DOSVM which Alexandre wants to change. You could disable it for your tests, and anyway if it comes to the crunch SIGUSR2 can always be multiplexed. You don't preserve the register state. This is something you get for free with signals, but you'd need to use a register function if you want to do it outside a signal handler. There seems to be a race condition - if the main thread is in the middle of shutting down you might be able to hijack it just as it's about to exit(), at which point the newly created sacrificial thread will also be torn down, leaving CreateRemoteThread hung. It could also cause the newly created thread to try and communicate with the wineserver after it's been disconnected. A service thread seems like a cleaner solution in general but if I were you I'd take this further by using SIGUSR2 to do the remote thread creation. Alternatively, you might be able to suspend the remote thread and queue an APC to it. thanks -mike On Fri, 14 Jul 2006 19:59:51 -0700, Thomas Kho wrote: > ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes > > Greetings,
Re: git annoyances: git fetch does nothing; git pull works?
On Thu, 13 Jul 2006 08:06:56 -0500, Jeremy White wrote: > But I have to confess that git makes my head hurt. > That just could be because this old dog can't learn this > trick. Doubtful, it's always made my head hurt too and I was playing with arch, svk and similar tools years ago :) I think it's just not got a very well designed user interface (though gitweb is pretty good). SVK may not have been strictly as powerful but it managed to get by with about 13-14 pretty obvious commands, and using it was mostly like using CVS in the common case. Oh well ...
Re: Debugging _CheckNotSysLevel() errors?
On Fri, 07 Jul 2006 00:24:49 -0700, Dan Kegel wrote: > http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash > on exit from a VB6 app due to a _CheckNotSysLevel() error. > What typically causes these - are they a bug in the windows > program? And is there a good reference from understanding > the whole syslevel thing in gdi? > Thanks! The developers guide talks about this, because I once asked exactly the same questions :) Syslevels are an internal mutex that understands ordering constraints, if a syslevel violation occurs it's always a bug in Wine and a backtrace can be useful to see how Wine got into the invalid state. thanks -mike
Re: wine packages for Fedora Extras
That's great, thanks!
Re: wine's fullscreen code has no effect on metacity
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote: > So, uh, metacity people, under what circumstances would metacity be > likely to put a window that had sent the proper _NET_WM_STATE_ADD > message for _NET_WM_STATE_FULLSCREEN behind panels? Run metacity from the command line so you can see what it prints; metacity helpfully outputs warnings when applications violate the specs or do something weird. Maybe we can find out what's going on there. thanks -mike
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/27/06, Steven Edwards <[EMAIL PROTECTED]> wrote: I don't think they are wrong about feeling that the site just seems to totally ignore OS X. I guess the FreeBSD and Solaris guys feel the same way reading over recent discussions. Alexandre does not treat patches from anyone as a second class citizen but the site does seem to be very Linux centric rather than platform agnostic. Like read the Myths page. Its all about Linux. I am happy to rewrite some bits of the site to make it broader in scope. That's true, but then what the myths page says could really apply to any "alt" operating system. But writing "Linux/FreeBSD/OpenSolaris/MacOS/BeOS" every time is unwieldy, especially as most of our users are on Linux anyway. I guess you could rephrase it all in terms of non-Windows systems.
Re: Wine developers?
On Mon, 26 Jun 2006 08:27:10 +1000, Troy Rollo wrote: > On Friday 23 June 2006 22:50, Mike Hearn wrote: >> A very specific legal interpretation that would require the >> company behind Thinstall to want to hurt the Wine project be careful, >> none of us are lawyers here. > > That's not entirely true. We have IP lawyers on wine-devel? Can you say who? thanks -mike
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On Mon, 26 Jun 2006 04:08:30 -0400, William Knop wrote: > Oh... Sorry about that. I suppose I did come off a bit critical. I think your email was OK, but wine-devel gets a constant stream of Mac users/developers telling us how many Mac users want Wine, how they would be a big benefit to the project, how Apple-land is a land of milk and honey etc ... whereas not many people here are actually Mac users. Telling people that's it's super important won't actually speed anything up. Not aimed specifically at you, this is just a general trend that's been on the increase lately. You know what they say about wishes and horses ... thanks -mike
Re: SecuRom investigation
On Sun, 25 Jun 2006 02:34:24 +0100, Martin Owen wrote: > which if we could get our hands on the source code would at least give > us more information about how this security works and may even allow us > to work around it perminently with in wine. The goal is not to work around it, the goal is to make it work! That is, it should not be any easier to copy games by using Wine. As for getting the SR code itself, no can do. We just need to solve this one the hard way and that means just bashing away at the bugs one at a time. All copy protection uses kernel drivers these days so the NTOSKRNL work is required first.
Re: Patch: winex11drv create_cursor Loading 32bit rgba cursor image
Heya Pauli,
A review is enclosed. To submit a patch please send it to
the wine-patches list, where it'll enter Alexandres queue for review.
Firstly I'm kind of surprised this doesn't require the XCursor extension.
Handling the case of a solid alpha channel by converting it to a mask is
fine but you should note with a FIXME cases where it doesn't work properly.
> @@ -422,16 +422,18 @@ static Cursor create_cursor( Display *di
> }
> else
> {
> -int rbits, gbits, bbits, red, green, blue;
> +int rbits, gbits, bbits,abits, red, green, blue, alpha;
abits doesn't seem to be used anywhere (apart from the assignment in the
32bit case).
> +alpha = 255; // This is vissible?
Yes, 255 is visible/max opacity (note spelling). Use C /* */ style
comments, we require this.
> +if (ptr->bBitsPerPixel == 32)
> +{
> +theChar = theImage[byteIndex++];
> +alpha = theChar;
> +}
> break;
I'm not sure even why "theChar" exists, apart from in one usage it seems
to be worthless. You could just directly assign it here (with the right
cast). Really this whole function could use a bit of spring cleaning.
> +
> +//bg or fg?
> +// If there is alpha for fg color then we should
> calculate avarange
> +// alpha and use that to create transperancy for cursor
> (at least my gnome
> +// has transperancy with xorg 7)
I'm afraid it's really not clear what you're doing here. Standard X
cursors cannot have an alpha channel, support for this was added with the
XRender/XCursor extensions which you don't seem to be using.
Here you seem to have decided that any value larger than 8 for the alpha
channel is solid and anything less is transparent. This makes no sense. A
much simpler way is to just compare against zero and 255, like this:
if (alpha == 0)
{
/* Transparent (note spelling) */
pAndBits[xorIndex] |= bitShifted;
}
else if (alpha < 255)
{
static BOOL warned = FALSE;
if (!warned)
{
FIXME("non-simple alpha channels are currently unsupported, expect
visual glitches!\n");
warned = TRUE;
}
/* assume we should display partly transparent pixels anyway */
}
not this ...
> +if (alpha < threshold>>3)
> +{
> +// Transperant
> +pAndBits[xorIndex] |= bitShifted;
> +}
The other thing that confuses me about this code is that on
first inspection it appears to be backwards. Surely if the
pixel needs to be transparent then that bit of pAndBits
should be zero, which is what it's initialized to, and it
should be set if the pixel is opaque?
I expect I'm confused, after all you tested this. But I'd like
somebody to explain it
> +// What is going on?
> +/* TRACE("Cursor file pixel,
No dead code please. If you found this helpful that's great but don't submit
code that is commented out.
> +if (!pixmapBits
> +&& !pixmapMask)
> {
> XFreePixmap( display, pixmapAll );
> XFreeGC( display, gc );
This isn't strictly correct, as only the last could have failed.
Something like
if (!pixmapBits || !pixmapMask)
{
if (pixmapBits) XFreePixmap( display, pixmapAll );
etc ...
}
would be better.
> @@ -556,6 +592,15 @@ static Cursor create_cursor( Display *di
> /* Put the image */
> XCopyArea( display, pixmapBits, pixmapAll, gc,
> 0, 0, xmax, ymax, 0, ptr->nHeight );
> +
> +if (ptr->bBitsPerPixel == 32) +{ +
> // Keep original transperancy if not rgba cursor +
> XCopyArea( display, pixmapMask, pixmapAll, gc, +
> 0, 0, xmax, ymax, 0, 0); +}
> +
The comment here is a bit backwards, it implies it's on a
non-alpha codepath when the reverse is true. It'd be better
as
/* Apply the alpha channel */
or something like that.
Final note - you are using a separate mask when we already have one
in this code. Why not merge your new mask with the existing one?
thanks -mike
Re: An RPM of wine with safedisc support
On Sat, 24 Jun 2006 15:22:42 +0100, ivanleo wrote: > Safedisc 2 and above are not supported. Is the reason why not on the Wiki? Would be cool to get it there if not. > To run a safedisc protected game, you must run winecfg and > set the drive type of your cdrom drive to "cdrom" in the drives tab. > Yes, this sounds dumb, but it has to be done. It sounds dumb because it is dumb, it implies a big failure in our auto detection code. I think the drive autodetect code I wrote was never enabled was it, as we now use HAL anyway, but it seems we really need to fix this bug ... thanks -mike
Re: Ole-BSTR-Concat broken?
On Sat, 24 Jun 2006 11:47:51 +0200, Olaf Schmidt wrote: > Do you handle the OLE-BSTR-stuff directly in wine, or do you > give that jobs to other Libs in the system (the 0.9.12er winelib- > update has also changed some dependencies (Gtk, libc* and > others)? BSTR (Basic String) is a Microsoft specific construct, it has no equivalent on other platforms, so it's handled internally. thanks -mike
Re: indented relay traces
On Sat, 24 Jun 2006 02:15:09 -0700, James Hawkins wrote: > Ah, didn't know about that tool. You learn something new every day. Perhaps it should be mentioned in the developer quickstart. thanks -mike
Re: Autocad 2004 STATUS_INVALID_LDT_OFFSET
On Fri, 23 Jun 2006 14:13:18 +0200, Jaap Stolk wrote: > 200145:Backtrace: Hmm seems like you are seeing a mixed debugger/app trace there ... gotta be careful of that!
Re: Move all common Dll[un]RegisterServer stuff to advapi
On Thu, 22 Jun 2006 15:58:58 -0700, James Hawkins wrote: > The imports for current dlls concerning advapi32 are fine; no need to > change to delay import. I understand where you're going with moving > factoring out registration, it's just that advapi32 is not the place. > I'm not sure where else you could put this. I would ask Alexandre > whether he wants it done at all, and if so, where the new code should > be located. I believe this was discussed when the registration code was first added, and Alexandre preferred this approach to having some utility DLL. I guess it's a matter of taste. I would have preferred a wineutils.dll or somesuch but he is the boss :) thanks -mike
Re: Wine developers?
Hiya Jonathon, I wouldn't worry too much about the negative reactions there, which is a shame. As Molle has pointed out he is not really a Wine developer. I am and I'd say that it's totally fine to post such a job advert here, I'm sure there are people here who would like to find a good job with their skills. I hope you fill the position soon! Good luck! thanks -mike On Tue, 20 Jun 2006 13:59:59 -0700, Jonathan Clark wrote: > My name is Jonathan Clark, and I work with a team on a project that has > some similarities with Wine. The project is called Thinstall > (http://thinstall.com), and on first glance similarities may not be > apparent.
Re: Wine developers?
On Tue, 20 Jun 2006 19:32:11 -0600, Vitaliy Margolen wrote: > Basically you are _stealing_ developers from the project. Because with your > closed source project such developer will be prohibited from participating in > the Wine project. A very specific legal interpretation that would require the company behind Thinstall to want to hurt the Wine project be careful, none of us are lawyers here.
Re: LoadResource with module=0x00400000 followed by stack overflow
On Tue, 20 Jun 2006 12:49:25 +0200, Jan-Espen Pettersen wrote: > Can a win32 program expect that it has write access to the memory > pointed to by the return value of LoadResource with module 0x0040? > Should LoadResource in some cases copy the memory and return a writeable > copy of the resource? The SEH handling code should catch this case and un-protect the resource section. At least it does for InstallShield ... I'm not sure why it's not working here. thanks -mike
Re: gdiplus.dll
On Fri, 16 Jun 2006 11:52:37 -0400, Steven Edwards wrote: > Like the parent said, some installers don't ship with it, they expect > the OS to have it. Office 2007 only runs on XP and higher and it > expects the dll to already be there. So we find some free application that contains it and install that first :) thanks -mike
Re: Add support for full screen window state using the NETWM protocol
On Fri, 16 Jun 2006 18:24:34 +0900, Dmitry Timoshkov wrote: > Hello, > > this patch works for me with Internet Explorer and Diablo II demo. I think for full IE support we need more; if you start IE, set it to fullscreen then quit and restart it the window will now be created unmanaged. Or at least this is how it used to work. Still this is fine for the usual case of having it temporarily full screen. It is most instructive to compare this with my own patch. I can see how you have simplified some of the logic there. So, thankyou for that. thanks -mike
Re: gdiplus.dll
On Fri, 16 Jun 2006 03:56:04 -0400, Steven Edwards wrote: > What do you mean? I looked at this before and even if we are to use > libgdiplus we need some way to wrap it in a way the Windows app > expects. Why? GDI+ is distributed with applications, so we can put off implementing it for some time yet. Using Monos GDI+ means using the Windows build of Cairo too; definitely a good idea IMHO as GDI+ is somewhat nontrivial and the code has already been written. thanks -mike
Re: Shell integration
On Fri, 16 Jun 2006 08:54:04 -0400, Ulrich Czekalla wrote: > That's why I like the idea of using COM. All the infrastructure is already > there. For now we can implement the trash shell object inside shell32 and > if someone wants to write a OS/X version all they need to do is override a > registry key. Other shell integration objects can even be implemented > out-of-proc in the explorer process all this can be cleanly hidden from the > shell32 code that uses it. Out of process COM is never cleanly hidden; if nothing else it can cause unexpected threads to be created and unexpected re-entrancy via the implicit message loops. Given that we already have platform specific handling infrastructure in the form of the configure script, it could be as simple as having a conditional Makefile that compiles functions with magic names. thanks -mike
Re: PATCH: sane.ds / DECLSPEC hidden
On 6/16/06, Robert Shearman <[EMAIL PROTECTED]> wrote: It's a little harder than that. I experimented with doing this before and it is necessary to apply that same attribute to all of the functions exported from libwine and libunicode. We're already forcing all exported symbols in those libraries to be visible using the linker script though so I don't see why it'd matter for them? thanks -mike
Re: PATCH: sane.ds / DECLSPEC hidden
On 6/15/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: No, we only want the internal functions to be hidden. Right, so we set default visibility to hidden then change WINAPI and WINAPIV to include __attribute__((visibility(default))). That way only WINAPI declarations are exported. thanks -mike
Re: PATCH: sane.ds / DECLSPEC hidden
On Thu, 15 Jun 2006 17:28:12 +0200, Alexandre Julliard wrote: > No, that's only hiding them. It's not a bad thing to do in a second > step for functions that really need to be global Can't this be done automatically by winegcc passing -ffunction-visibility=hidden or somesuch? thanks -mike
Re: msi: Cast the total memory to an unsigned int to avoid overflow in machines with more than 2Gb of RAM [resend]
On Thu, 15 Jun 2006 11:04:41 +0200, Alexandre Julliard wrote: > The existing code should work fine, and yours will return 0 for a 4Gb > box... It sounds like the problem is in GlobalMemoryStatusEx. IIRC this API has a quirk w.r.t large memory handling. I remember doing something to this code a few years ago for this reason. The Ex version simply fixes this bug, iirc, and adds no new features over the non-extended version. thanks -mike
Re: Gecko installer
Yes this problem with the lack of child windows is most troublesome. I wonder if there is another way to solve this though. By using COMPOSITE to redirect the window heirarcy of the embedded window to a pixmap we can proxy events and copy the pixmap to simulate window embedding, without actually doing so. However it is probably best to ignore this for now, there is nothing wrong with using a Windows gecko. Especially if it is included in packages. On 6/15/06, Jacek Caban <[EMAIL PROTECTED]> wrote: I think Alexandre can give you the best answer. Yes, the problem is mostly because of lack of child X windows. The main thing we'd have to add to XEmbed spec is clipping but probably there will be more problems. And I have no idea if freedesktop guys will accept what we need as clipping in XEmbed spec is useless for most apps (probably everyone except Wine).
Re: Gecko installer
On 6/14/06, Jacek Caban <[EMAIL PROTECTED]> wrote: See http://www.winehq.org/?issue=285#MSHTML%20Update. I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?). That's why MSHTML uses Windows Gecko. OK. What exactly *do* we need from XEmbed? Is this because we can no longer use child X windows? thanks -mike
Re: Gecko installer
On 6/14/06, Jacek Caban <[EMAIL PROTECTED]> wrote: Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko. Directly how? I am still confused, sorry. By "Gecko" do you mean: - A win32 copy of Gecko/GRE/XRE installed in ~/.wine/drive_c? - A native Linux copy of Gecko installed as part of, say, the distributions Firefox? - Something else? thanks -mike
Re: wine XShm problem on remote display
On Tue, 13 Jun 2006 16:22:17 +0200, Alexandre Julliard wrote: > Wine will handle that error properly, but here it sounds like fst (or > more likely Gtk) has replaced the Wine error handler with its own, so > Wine doesn't get a chance to handle it. Yes, that's the GTK+ error handler. Benjamin, this is a bug in FreeST and you should report it to the developers there. Fixing this is not very difficult, hopefully it can be resolved soon. thanks -mike
Re: Broken FC5 packages - stay clear.
On Wed, 14 Jun 2006 12:37:21 +0200, Andreas Bierfert wrote: > What I can offer would be this: add a meta package wine-suite which will > install all wine > packages and change the summary of wine so it: > a) points to the wine-* subpackages so everyone knows they exist > b) tell them that there is the wine-suite meta package Well, that would be an improvement but people tend to just guess at what they need to type for programs like yum/apt. It's one of the problems they have. Does "yum install epiphany" install a web browser or a card game? You don't know unless you check beforehand (or try it). I think a meta package called "wine" that installed everything would be much better because that would do what end users would intuitively expect. And Wine isn't really a suite. It's a large, monolithic program. If it was a suite we'd realease separate tarballs upstream. > and of course as discussed before add a Require for wine-tools to wine. Yes that would fix this problem for now. > I do listen to your requests and if you > take a look around there are not many packagers who actually do this... I know, and apologise for my harsh tone earlier. I think it's great you are here on wine-devel and working through the problems with us. Hopefully you also understand the source of our frustration - I have wasted *many* hours debugging problems that turned out to be caused by bad packaging. This problem occurs all the time and when we eventually get one problem fixed, some other distro somewhere else gets it wrong again and we are back to square one. It feels like we never move forward on this issue. Also I'm afraid the answer of "report bugs to bugzilla.redhat.com" is not OK because it is not under our control. I'd say the vast majority of end users don't use distributor bug systems and never have, not even for Debian which has always had this policy. They post to wine-users, or IRC, or our bugzilla, or random web forums. And then we get to pick up the pieces. Maybe this summer I can work on what I always said I would and do a Wine autopackage ... thanks -mike
Re: Broken FC5 packages - stay clear.
There seems to be another issue here ... you removed the rpath code with a link to two bugs that don't seem to indicate that was causing the problem. Now I appreciate that given RPMs are not relocatable it makes no difference to your users but I am concerned that a problem apparently unconnected to it caused this change. Vendor patches are bad, for Wine they usually either mask upstream bugs or cause them. Specifically the libGL problem is a bug in that users setup (maybe in Fedora), and I don't think it's in Wine. I don't see where the /usr/lib/nvidia search path is coming from - if it's LD_LIBRARY_PATH then we should be using DT_RUNPATH in Wine and not DT_RPATH so we should fix it. If it's in the linker config then you are relying on a very particular combination of factors which may be true for some binaries shipped with Fedora but are not guaranteed by the ELF or Linux ABIs - you can't have a /usr/lib/libGL.so.1 and always expect it to lose to /usr/lib/nvidia/libGL.so.1! thanks -mike
Re: Broken FC5 packages - stay clear.
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: > Well from a wine perspective I see that this makes sense, but if you take a > look > at all the dependencies it is another story... This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are missing the features will be disabled at runtime usually with a message on stderr. The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about wine-tools and does not install it? They will be missing: * winecmd * notepad * winedbg * winepath * winhelp * _EXPLORER_ These may appear to to be optional but they are not. Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure. Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously. Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it? -m
Re: Gnome and KDE wine configuration tools
Hmm, Wine Doors looks pretty cool. At least, it seems to have a nice UI. Though I question how much preset "profiles" can achieve these days ... we're getting closer to not needing them all the time. Maybe if the profiles can do things like install native MSI/DCOM/MDAC/InternetExplorer etc it might prove handy for end users.
Re: WM_GETICON patch
On Sun, 11 Jun 2006 20:26:11 -0700, Chris wrote: > Aren't icons already created on the global heap? They're created with > GlobalAlloc16, and (optionally) added to a link list of shared icons. No, this is a confusing Win32ism. The "global heap" is not actually global, it's process-local. There *is* a shared heap in Windows 9x but not in NT. GDI objects are stored in the kernel in Windows, and so are "shared" via that mechanism. We do the same thing by moving things into the wineserver and transporting them via RPC. Actually images are stored as pixmaps in the X server, so it'd be awfully convenient if we could leverage that but I suspect the need to support non-X display systems means we have to do it the hard way, by shovelling image bits across the socket. thanks -mike
Re: WM_GETICON patch
On Sat, 10 Jun 2006 16:35:45 -0700, Chris wrote: > Originally GeoShell would show no icon on the taskbar and print > a lot of fixme messages about it being unsupported. With this patch it now > (always) shows the Wine glass icon for programs, with no such fixme messages. Well I guess this is a slight improvement but obviously WM_GETICON requires inter-process bitmaps to be supported in some fashion, which is a fair bit of work. Maybe for efficiency reasons even requiring the dreaded remote thread creation/service thread :) thanks -mike
Re: Icmp* functions in iphlpapi.dll
On Sat, 10 Jun 2006 21:37:01 -0500, Carl Fongheiser wrote: > Bad, bad idea. In Windows programming, you *never* call LoadLibrary from > DllMain. Inside of DllMain, you can't call anything which uses the loader > lock, because the loader lock is already taken out. As best as I read the > Wine code, it has the same limitation. Loader lock is a recursive critical section so it's OK to do that from the same thread and actually, the Wine loader code is written to allow that to work. That said it's quite dangerous to do much of anything inside a DllMain because so much stuff in Win32 relies on multiple threads or inter-thread messaging behind your back. thanks -mike
Re: Broken FC5 packages - stay clear.
On Sun, 11 Jun 2006 11:09:10 +0200, Andreas Bierfert wrote: > Yes it is (ok more like 11 but ok). For me it works for the programs it should > work on... We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things. Out of interest what are the 11 packages? thanks -mike
Re: My new hero...
On Tue, 06 Jun 2006 22:43:27 -0700, Dan Kegel wrote: > Mike, what was that you were saying about > there not being any wine hackers who fixed > problems all around the wine tree anymore? I consider myself joyfully corrected! :) Go Qingdao!
Re: wined3d: Another GLSL shader status update
On Tue, 06 Jun 2006 13:55:15 -0400, Jason Green wrote: > FYI - I just added a bunch to this page to get us started: > > http://wiki.winehq.org/DirectX-Shaders That's awesome, exactly the sort of thing I was looking for. This sort of high level overview is very useful for new hackers! :) thanks -mike
Re: msi: Fix some copy/paste bugs in the implementationof condition operators.
On 6/6/06, EA Durbin <[EMAIL PROTECTED]> wrote: I've decided to concentrate my efforts in another area, so I won't be looking at msi any longer. I admit I 'm no C expert, I'm a web developer by trade. Though I started to look at the C code to get away from php/perl/ruby and get aquainted with the language in my leisure time, I need no assitance with web development. As I would still like to contribute to the wine project I will be focusing my efforts on Appdb and Bugzilla. Well, that's great too but I don't want to see you give up! :) I know this particular adventure hasn't gone quite right but there's plenty of areas you can contribute. When I started I was no C expert either but it's a simple language and can be quickly learned. Often this happens, you debug something to find that it's in an area not many people can work on. If you want my advice, it'd be to just try your hand at debugging random apps. Find one that doesn't work, poke it a bit to find out why not, if you aren't getting anywhere throw it away and move onto the next. This lets you see a lot of the code quickly, and you'll probably find that some bugs are much easier to fix than the one you found. thanks -mike
Re: acad 2004 license file bug
On Tue, 06 Jun 2006 12:36:07 +0100, Mike Hearn wrote: > Right now we don't set the registry key saying we have IE installed, even > though many of the DLLs the app probably needs are there and functioning > correctly. I think the plan is to add this reg key after the last of > Jaceks IE work is merged but only the big J himself could comment on that. Specifically I can't figure out if we're supposed to install a Windows gecko based product or if it can use my native Linux Firefox ...
Re: Re: Linux noob
On Tue, 06 Jun 2006 03:27:52 +, NikNot wrote: > Indeed! This is something that I found infuriating since I first > used wine. What possible reason would there be to make this > a "hidden" directory? From whom exactly should it be hidden > and why? Historical reasons. I'm switching this thread to wine-devel as TransGaming do in fact make the virtual C drive visible by default and it's maybe something we should do too. On the other hand, it might just be wallpapering over other usability problems (lack of menu integration, most obviously). How often does average jack need to go poking around C:\Program Files in real Windows? thanks -mike
Re: acad 2004 license file bug
On Mon, 05 Jun 2006 10:23:45 +0200, Jaap Stolk wrote: > Thanks. but it doesn't seem to fool autocad. I tried: > WINEDEBUG=+server wine setup.exe > ~/mywinelog.txt > but it still logs to stout and my system can't keep up with the scrolling. > Is there a way to watch just the registry read/write ? You want WINEDEBUG=+reg wine setup.exe 2>/tmp/log Note that you redirect stderr not stdout. thanks -mike
Re: msi: Fix some copy/paste bugs in the implementation of condition operators.
On Mon, 05 Jun 2006 10:14:50 -0600, Vitaliy Margolen wrote: > So until you show us some code that verifies what you are talking about, > please stay away from the e-mail clinet. He has done exactly that though not in a form we can put in the test suite, and he is not "flaming" anybody. I think you need to calm down a bit. thanks -mike
Re: acad 2004 license file bug
On Sun, 04 Jun 2006 20:43:17 +0200, Jaap Stolk wrote: > The autocad installer indicated that I needed internet explorer 6.0, > so I installed that using winetools. (can wine fake internet explorer, > so i don't need to install the real thing?) Mostly yes, but that area of code is still being worked on quite heavily. We're supposed to be able to use Mozilla but last time I tried running "wine iexplore" it told me it couldn't load Gecko so I'm not sure what's going on there Right now we don't set the registry key saying we have IE installed, even though many of the DLLs the app probably needs are there and functioning correctly. I think the plan is to add this reg key after the last of Jaceks IE work is merged but only the big J himself could comment on that. > anyway, the autocad installer now complains that the licence file > could not be found, but this bug report indicates that this problem is > supposed to be fixed: Mike doesn't have AutoCad so it may not be fixed. The problem must lie elsewhere. Native MSI can be installed if you use Win98 mode, or you could try debugging Wines own MSI implementation. > Should I try the suggested "fix": copy the bin/acadfeui/eula directory > from the cd-rom to the c:\ root ? Sure, why not, it may work. thanks -mike
Re: DirectX blitter bug
On Sun, 04 Jun 2006 02:51:31 +0200, Alexander Nicolaysen Sørnes wrote: > This is fixed in Stefan's ddraw patchset. Awesome :) I look forward to it being merged. thanks -mike
Re: wined3d: Another GLSL shader status update
On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: > > This is an elaborate scheme with linked lists in each shader - is that > > really necessary? > > I'm very confused after reading the code (but maybe that's just me :) > > If we link the programs together every time the Set__Shader() is called, > it brings performance to a halt (that what my glsl_hack4.diff did). Re: the recent discussion on code commenting and documentation, it'd be nice if the patch explained this somewhere. It'd be even nicer still if at some point one of you guys could take a break from the codeface and write a chapter for the Wine Developer Guide on shaders and how all this works ... it seems incredibly opaque and the last thing we want is a re-run of the DCOM situation where the only people who understood it left or hacked on other things for a while and we lost the knowledge of how it worked. thanks -mike
Re: Wine VM86 exception handling bug?
On 6/5/06, Robert Shearman <[EMAIL PROTECTED]> wrote: It depends whether it's in a convenient form. For a 100-byte COM file, it is probably already in its most convenient form. If, like Rob, you are an i386 ninja master who wields a disassembler as most of us wield a knife and fork then yes maybe :) For the rest of us source code can be occasionally convenient thanks -mike
Re: Wine VM86 exception handling bug?
On 6/5/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > I'd rather we got out of the habit of doing this seeing as I think git can > deal with binaries better than cvs can. There is no point in storing the binaries in the *source* tree, besides tiny .com file which shows the bug shouldn't take more than 100 bytes of an array in the .c file. Sure it might be small, but it's still a binary no matter how we store it. It's not more useful as an array than as a true binary file on disk. Why obfuscate and expand it by embedding it into a text file? thanks -mike
DirectX blitter bug
Lords of Magic works perfectly EXCEPT that rendering is corrupted when it is using DirectX "fast blitting"; they provide a software emulated workaround for some truly ancient cards (Matrox Mystique anyone?) and the game works well in this mode. But it should work properly in DirectX accelerated mode too. The kind of corruption varies but it appears as, for instance, mouse trails which to me suggests some kind of co-ordinate system problem. The demo is here: ftp://ftp.sierra.com/pub/sierra/lordsofmagic/demos/si_lordsofmagic_demo.exe and it installs cleanly on the master branch. If any DirectDraw gurus want to take a look, please do! I bet this problem affects other games too thanks -mike
Re: Shell integration idea
On 6/3/06, Mikołaj Zalewski <[EMAIL PROTECTED]> wrote: OK, I won't insist on aggregation :). As for apartments I've thought that something like that: HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED); /* working with objects with ThreadingModel Both */ if (SUCCEEDED(res)) CoUninitialize(); won't have any side effects. Well, you'd be possibly changing the apartment of the current thread, which is not allowed IIRC. But if the number of developers that knows about COM is low then maybe that it's better to use simple ops structs instead. I'd say so... thanks -mike
Re: Wine VM86 exception handling bug?
On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote: > You can embed a trivial DOS executable as data in the .c file I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. thanks -mike
Re: Prospects of an OpenAL audio driver...
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote: > Are there any problems with using OpenAL for such a purpose? Probably not, it depends on the exact level of abstraction OpenAL gives. But it begs the question - why? thanks -mike
Re: ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
On Sat, 03 Jun 2006 09:43:04 +0200, Alexandre Julliard wrote: > If it's a solution that can be expanded later on to cover the other > cases, yes, but not if it's a dead-end. When this was discussed before the idea of bringing back the service thread was raised. I still think we should do this, assuming details like suppressing attach notifications are done properly ... thanks -mike
Re: MSI query tests
On Thu, 01 Jun 2006 21:51:20 -0500, EA Durbin wrote: > I don't know how I would run this on windows. You don't have to, you just need to run it against a native MSI. As to how to convert your findings into a test case, I guess that may be trickier. There is some fundamental behavior here that is wrong, so creating a database that shows the problem then testing queries on it might work? thanks -mike
Re: Shell integration idea
On Fri, 02 Jun 2006 20:16:25 +0200, Mikolaj Zalewski wrote: > Of course when we use COM aggregation instead of a factory pattern we > will have all the interfaces visible under one CLSID so we will be able > to construct a IWineTrash directly with the main object hidden behind > the scene. Argh, this is exactly what Alexandre meant! :) The number of developers that understand COM aggregation and all the baroque rules that make it up is very, very low. A simple ops struct of function pointers as used in the wineserver or kernel would be fine here ... COM adds an awful lot of complexity that really isn't needed at all (eg you must call CoInitialize, which means caring about apartments, which means possibly instantiating a STA when windows wouldn't, which means pain). thanks -mike
Re: How are we doing?
On Sat, 03 Jun 2006 12:03:21 +1000, Jeff Latimer wrote: > We seem to have a policy of not accepting comments in exisiting code. We do? I seem to recall having comment patches accepted before. Albiet a long time ago. > If I add comments to existing code that clear up a mystery I have found > they are nicely deleted. A pity as the comments would help me next time > I am in the area if no one else. Hmm, well that should be changed if so! I can agree that some parts of Wine are painfully obscure. I've learned most of what I know about how Wine works by asking questions here and on IRC. Hopefully the developer guide expansion I worked on a while ago covers a lot of the more exotic topics. thanks -mike
Re: How are we doing?
On Fri, 02 Jun 2006 08:03:46 -0500, Jeremy White wrote: > And I think I would agree that the Wine server is commented > about right; it is, imho, a beautiful piece of code. +1 to that. I reckon I didn't really grok in that deep-down-in-your-soul way what "good coding style" is until I took time to study the wineserver. That said, some parts of it could use a tad more explanation. The reader will know that files are opened for clients by the wineserver due to POSIX locking semantics . but not any more detail than that. How on earth does the blocking/sync/wait infrastructure in the server work? What is an "in flight" fd? When I started it was black magic. It also has a bunch of comments like this: /* initialize the structure for a newly allocated thread */ inline static void init_thread_structure( struct thread *thread ) ;) That said, I could not have written the wineserver, so my comments should be taken for what they're worth (not much)! thanks -mike
Re: How are we doing?
On Fri, 02 Jun 2006 12:33:03 +0100, Robert Shearman wrote: > The lack of comments in your email is more horrifying. Haha :) Maybe we should have a new janitorial task "comment code", or maybe Alexandre should reject patches that don't have enough comments? The problem I think is that because MSDN basically describes what the code is meant to do, developers familiar with that area end up perceiving it all as "obvious". I know this was an issue with the old DCOM code, and it took a long time before I really understood what it was doing. I think the new code is a lot better commented which is nice. Plus we have in depth explanations of DCOM in the developer guide now. The other issue is that Wine is an extremely opaque codebase *unless* you know operating system design inside out, in which case it's often self explanatory. Most people don't, and this surfaces as "I wish it had more comments". Well, yeah thanks -mike
Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom
On 6/1/06, Jesse Allen <[EMAIL PROTECTED]> wrote: What about the device node symlink? It's needed for the games alot and it's the number one thing I get asked for help for now. We don't have an easy way to detect it, although HAL should be able fix it. Right well that's us being borked somewhere ... Alexandre has said on IRC that we shouldn't actually need the x:: symlink anymore :)
Re: wine problems on a 64bit system
On 6/1/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: Yes, I'm afraid we'll have to do that by default, there are too many broken binaries out there. I think we've only seen a couple of such reports so far given that the exec bit was never enforced before now it wouldn't be surprising if there are lots of buggy apps out there but we don't seem to be seeing them yet. Perhaps for NX capable systems it could be an appdefault? The security enhancement it gives would be nice to have at least as an option for power users (yeah yeah I know, another pref ...) thanks -mike
Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom
The location CD drives are mounted changes between systems, this patch is essentially specific to yours. Wine already supports HAL, which should solve this in a more correct manner (though we have reports it doesn't work for some games!), so how comes that's not enough? thanks -mike
Re: wine problems on a 64bit system
On Wed, 31 May 2006 07:26:37 +0200, Pavel Troller wrote: > The machines are running very similar kernels. Both are hardened with > exec-shield, but even disabling it on a 64bit by > 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with > exec-shield enabled (and doesn't print the no-exec message). As a hack you can change the code so every range of memory that is mapped is mapped executable. thanks -mike
Re: How are we doing?
On 6/1/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > It's possible to see on wiki the "trust points" positions ? :) > And on each WWN, see the variations (seems the famous kde buzz) :) The commit logs contain the time of the change and the time of the commit, so you could use that to build a top-10 of the developers with the best patch-to-commit times ;-) Heh :) Bear in mind that it depends a lot on the patch and what kind of work you're doing. Getting some clearly correct typo fixes in for an obscure DLL is going to be a lot easier even for 'untrusted' developers than, say, implementing SetThreadPriority which touches the core of Wine in a sensitive area and is somewhat controversial. There's no special privilege for CW employees or SoC students, though we appreciate it may look that way at first glance. I'm a CW employee on and off (more off than on lately due to university) and I get patches rejected all the time :) thanks -mike
Re: How are we doing?
On Wed, 31 May 2006 14:57:06 +0200, Hans Leidekker wrote: > At the same time we should think of exciting new possibilities that an open > source implementation of the Windows API brings to the table. At past WineConfs the possibility of reaching out to Windows developers was raised, by making it easier for Windows guys to use our code. For instance if they have built their app on an API but need a bugfix or feature Wine is the obvious candidate but right now we make it hard for them to do that. We're very Linux/UNIX centric (eg build system ...) thanks
Re: World of Warcraft (WoW) patch/more address space layout stuff
WoW Has a all chain of checks that go up all the way to rootkit reveler to make sure the user is not aided by an automatic system, Given the player an advantage other players do not have. The Memory layout checks is for making sure the program is not loaded by a Debugger of sorts. Or that core Dll(s) where not replaced/hooked/emulated. Yes, it could be the Warden, but I doubt it. If the Warden is triggered you get banned from the game yet this bug surfaces not as spurious bannings but some kind of mouse control/targetting problem. To be honest I'm amazed we haven't seen any reports of Wine triggering anti-cheat systems like Blizzards before, and I'm sure we'd hear about it if it did It is possible that approaching Blizzard might be helpful. Is WoW supported by Cedega? Yes, using a slightly more generic version of the same memory layout hack. thanks -mike
Re: How are we doing?
On 5/30/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: I can't believe that writing a good test case showing the bug and adding it to the Wine test harness is such hard thing to do for a good Windows developer who already knows what he expects from a particular Win32 API. But most developers who come to Wine are not Windows developers, they are Linux developers who want to run an app or game. Often finding the bug is much harder than fixing it these days. It takes practice to learn how to read a relay trace or debug a mysterious crash. There is documentation showing how to do this with examples but I guess it could go further. Once the test is in the Wine tree that becomes *much* easier to pinpoint the bug and decide what is the real fix for it. Yes, sometimes. Some things are hard to show with unit tests. Consider the case of "I run my game and the audio glitches". It turned out that for some people that was due to scheduling problems and a fix is to use POSIX capabilities to add SetThreadPriority support to the wineserver. For somebody new to Wine that would be a very difficult problem to track down and fix, and hard to unit test. I agree that proving a problem using a test is a good way to start for many bugs however, especially message related ones. thanks -mike
Re: World of Warcraft (WoW) patch/more address space layout stuff
Interesting.. if MacOSX has a similar memory layout as linux, maybe we could get Blizzard to include a workaround that is only active when it sees that it's running under wine/cedega. Well if you can get the email address of a WoW developer then maybe we can track down where the problem in WoW is and work with them to fix it. I don't think Wine-specific workarounds make any sense: the address space layout when not requesting a specific address is not guaranteed. Vista already includes ASLR which is likely to break such software. It will need to be fixed sooner or later, might as well be sooner :) thanks -mike
Re: World of Warcraft (WoW) patch/more address space layout stuff
On Tue, 30 May 2006 16:08:42 +0200, Tomas Carnecky wrote: > Since WoW also runs on MacOSX, how does the memory layout on MacOSX > differ from NT and Linux? I have no idea, but the MacOS and Windows versions of WoW will be different; probably the bug is only in the Windows specific parts of the code. > Maybe that's the reason why they won't do a > Linux port: because they rely on a certain memory layout and the code > can't be changed that easily. I suspect the real reason is the usual one: concern over profitability. They'd need to have a full time Linux dev team as well, because the code constantly evolves. The problems Second Life is having shows what happens when you don't do that :/ thanks -mike
Re: Wine 1.0 Tasks
On Tue, 30 May 2006 07:14:07 -0700, Dan Kegel wrote: > Go ahead and retarget those to 1.0, then, please. OK. I need to talk to Tony, I seem to have lost my bugzilla privs at some point (probably changing email address). > I agree that Sun's Java runtime is probably something we should support for > 1.0. > But Java isn't "just fine" under Wine; I've run into installers that > fail because they crash inside Sun's JVM on Wine. That sucks :( A few years ago I was running pretty complex Swing apps on it. I wonder if it's regressed or if those are bugs I just never hit. > If someone wants to start putting effort into getting .NET, or for that > matter Mono, up and running, great. But personally, I'd be just fine > with making .NET support a 1.1 feature. - Dan Yes, OK. What's the use case for running VS on Linux; is the idea that as developers migrate they can continue working on their old software? Or that they can use these tools to write new software that targets Win32? thanks -mike
Re: Set up wine-macosx? (Re: How are we doing?)
On Mon, 29 May 2006 23:47:26 -0700, Jim White wrote: > But I do know I set up Darwine because of the antagonistic > and dismissive tone here when I tried to discuss Darwin & Mac OS X > development ideas. I have yet to see anybody give Emmanuel and the other Darwine developers anything but respect. The "dismissive tone" you received are because you are not a developer and like most open source projects, Wine has a simple currency -> those who do the work get the respect. Tell people they should work on a port to a platform they don't use and you'll be told to do the work yourself. Dismissive? Maybe. Unexpected? I'd hope not. > Darwine is a "private community"? "Second-class citizen in the Wine > world"? Uh, yeah. I'm really feeling the love here. You've misinterpreted a statement of fact as some kind of insult. Work that doesn't take place on wine-devel is invisible to most Wine developers, it's as simple as that. > Oh, wait. The award *did* get mentioned in Wine Weekly issue #311. > Hmmm, except that not only is Darwine not in the subject line, it isn't > mentioned at all. There is some whining that Wine didn't win though. > Thanks guys. Look, there are various reasons why some developers - and it seems maybe Marcus is in that group - are uncertain as to whether a Mac port is a good thing. This has been explained to you before. So why do you act shocked when an individual is "unsure whether to be happy or sad" over the news? > Lest you think I'm complaining here, I'm not. You clearly are complaining, there's no other way to describe it. -mike
Re: How are we doing?
Got a reply from somebody who would rather remain anonymous: - This may be just me, but the learning curve is probably much more steep for a "general purpose" hacker than for a particular dll. I have some apps I'd like to get working, but I find that the underlying problems tend to take a long time to find, and when I do find them they tend to fall into one of these categories: -relatively simple to hack around, but difficult to really fix -involves implementing or fixing something that's way beyond my skills -it's unclear how to properly fix the problem None of those result in a patch. Usually they only will only result in a bug report or (if it's something the developers are aware of) nothing at all. On the other hand, I'm not really interested in working on a particular dll; I just want my apps to run correctly on wine with as little kludging around things as possible. - ... which is certainly true, it has a steep learning curve. But I think we need more people doing such things :/ thanks -mike
Re: Wine 1.0 Tasks
On Mon, 29 May 2006 21:01:46 -0700, Dan Kegel wrote: > I suspect a few of these are stale, and a bunch others are missing, > but I like the idea of using bugzilla to track our progress to 1.0. Hmm, maybe. Bugzilla lists have a tendency to come and go though as people nominate their bugs and as they are fixed. I think it's not quite as satisfying as a mostly static list. I appreciate it's easier to set up though :) > What other bugs should be fixed before 1.0? IMHO we should really nail the window management problems. The WM rewrite was supposed to fix our woes with unmanaged windows and fullscreening for ever but it hasn't happened yet. > It's probably unreasonable to require 1.0 to support .NET Is it? We already run Java just fine and I am sure Mike M had command line .NET apps running a year or two ago. It might be plausible. thanks -mike
Re: World of Warcraft (WoW) patch/more address space layout stuff
On 5/30/06, n0dalus <[EMAIL PROTECTED]> wrote: It would be really great if someone could document the patch and explain what exactly is stopping WoW from working (as well as which changes would cause problems for other programs). It's a bug in WoW itself, it relies upon the exact way NT maps memory which is different to how Linux does it. I guess they are storing information in the high bits of a pointer somewhere or some similar trick. The patch is a hack that makes Wine follow the Windows method - unfortunately it will happily force an allocation to an area that is already allocated. Right now it relies on pure luck to avoid blasting a previous allocation. Expect random undebuggable failures with this technique. I think there would be more chance of getting developers working on the problem if the problems involved were clearer and easier to see/understand. The real issue is that it seems not many Wine developers play WoW themselves ;) Given the amount of users who use wine to run WoW, would it be possible to have the patch included with a compile-time option? Would it even be possible to make the patch a runtime feature? Doubtful. You'd have to ask Alexandre. He may know of a different solution also. Wine has a policy of not accepting application specific hacks though there are a few generic hacks in there. You'd be better off IMHO by preparing your own Wine binary install that is specific to WoW itself. thanks -mike
How are we doing?
As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project. Questions to consider: * Is Wine improving or is the regression rate matching the improvement rate? * Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone) * Are we turning away potential developers for any reason? Could we do more to attract new hackers? * Are the projects fundamental processes serving us well? * Any other thoughts for improvement? In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase. >From my own perspective I think Wine is doing better than ever before. What prompted this email is the realisation that in the past few days I've used Wine nearly every day to run a variety of apps - from games to utilities - and it's succeeded with every single one. Not always perfect but always good enough. I am no longer surprised when Wine runs an app correctly as I was when I first came to the project, these days I nearly take it for granted. Though this may be due to having developed a feel for what will work and what won't :) So clearly we're doing something right ... I also think we are doing OK with attracting and keeping new hackers. The influx of new Direct3D talent lately is fabulous for instance. The experiences of our SoC students will be useful in assessing how to improve the learning curve and we need to tap this resource better than we did last year. In other words, I think we're doing pretty well. I feel more positive about the project that I have done for a long time. It seems like as Win32 stagnated and slowed down over the past 6 years we've been able to turn the tide and add our own code faster than Microsoft can, which is the tipping point. So areas for improvement? * We seem to be doing very well in recruiting hackers who work on one particular DLL or area and solidly improve that, but a less well when it comes to 'general purpose' hackers who just take random apps and make them work. It might just be that I'm out of touch but I don't see as much patch traffic these days along the lines of "This patch set fixes XYZ app" followed by 6 patches to 6 different DLLs. Discussion on IRC/wine-devel is * No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :( * Integration with other projects is still a weak area. Desktop/kernel/X integration could all use some work. I know I know, I'm guilty in not doing my bit here too maybe I will find my hack-fu returning sometime soon and work on the fullscreen patch again :) * App specific patches. Well I don't expect policy here to change anytime soon but extreme cases like the WoW VMA layout problem which affects tons of users do highlight the issue. * A few random things I already got into arguments about (forums, libwine api etc) :) What do you guys think? thanks -mike
