Alex wrote:
> This is a proposal for a Google Summer of Code Project.
>
> Improve Wine's DirectPlay implementation so that it can at least run a
> simple demo app, and ideally end up enabling network play for a free
> game demo.
> A list of such demos is available here
> http://wiki.winehq.org/DirectPlayGames
I think Alex is suggesting a possible project idea --
he's not proposing to do it himself.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
These lines could explain why Starcraft is unable to switch to fullscreen:
err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default
fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8
fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8
I seem to remember that BPP cannot be changed _at all_ with XRandR, is
this correct?
If it is, then the obvious thing to do is to leave BPP alone and just
change to the correct …
[View More]resolution.
What needs fixing here?
[View Less]
This one uses POSIX capabilities to drop all root privs except for
CAP_SYS_NICE, therefore, this is reasonably secure.
There is one catch. For some reason a suid root app cannot read
/proc/self/exe so relocatability isn't used, and anyway it'd be
insecure even if it could as you could hard link wineserver then trick
it into loading a malicious library relative to $ORIGIN.
I think I will investigate this a bit more, but perhaps later. For now
this is fine for RPMs and packages etc, which …
[View More]install to /usr, as they
can simply "chmod +s wineserver" and have apps with solid audio.
thanks -mike
[View Less]
Mike Hearn wrote:
>> I'm not convinced this is true. At least some (maybe most or all) of
>> the games showing this problem work just fine if true OSS (ie. not
>> ALSA-emulated OSS) is used as the sound driver. WoW and StarCraft
>> spring to mind immediately. Plus apparently they work in Cedega
>> without needing to be root, though I have no first-hand experience of
>> this.
>
> Maybe for you, but this problem seems to be related to all kinds of
…
[View More]> things ... system speed, kernel scheduler, driver combinations, what
> Wine is doing at the time etc. All I know is that this works great for
> me, and no, rebuilding my kernel and going back to OSS is not really an
> option :)
>
> Cedega, IIRC, either has some awful hacks or has the wineserver acquire
> the privs, I don't remember which .... it'd be nice to find out.
>
> IMHO the best way would be for wineserver to be suid root and then drop
> privs. It works everywhere and is simple.
I really ought to remember to use reply-all for wine-devel. I've quoted
my first post since I meant to send it to the list.
Anyway, surely the `best' way would be for the kernel to support
user-level `real-time' priorities like the ck kernels. Anybody know why
they don't like the idea of that kind of thing?
More on topic, does this simply change Wine's priority or does it act on
a per-thread level? Most of the issues I've seen have been caused by the
audio thread being starved by the others, and is often semi-solved by
running Wine at nice 19, which seems counter-intuitive but appears to
get around some sheduling problems (priority inversions spring to mind).
This has the side effect of course that you have to make sure no other
process is going to steal the cpu time from under you. Am I talking
about the same issue as everyone else or have I got the wrong end of the
stick?
[View Less]
Hello,
As suggested earlier on the list, I ran this game with valgrind (at last
I tried again with svn, which works better than trying to patch 3.1.1)
There are a few problems: valgrind comes with loads of errors, but only
indicates which file (*.so) the errors come from (so I need to compile
wine with gdb debugger support, without optimisations, I guess?)
More serious, it seems wine uses some feature currently not supported by
valgrind:
-----
x86toIR: unimplemented feature
vex: the `…
[View More]impossible' happened:
x86 segment override (SEG=CS) prefix
vex storage: T total 1908936388 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==14207== at 0xB00170DB: (within
/usr/local/lib/valgrind/x86-linux/memcheck)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==14207== at 0x480D03: ???
Thread 3: status = VgTs_WaitSys
==14207== at 0x200546A1: (within /lib/tls/libpthread-0.60.so)
==14207== by 0x202E81B7: (within /usr/local/lib/wine/ntdll.dll.so)
Thread 4: status = VgTs_WaitSys
==14207== at 0x20129523: poll (in /lib/tls/libc-2.3.2.so)
==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so)
Thread 5: status = VgTs_Runnable
==14207== at 0x2011D347: sched_yield (in /lib/tls/libc-2.3.2.so)
==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so)
Thread 6: status = VgTs_Runnable
==14207== at 0x219840BE: (within /usr/local/lib/wine/winex11.drv.so)
==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
-----
is there a patch for this one?
at least I will recompile wine with gdb debugger support and look at the
errors valgrind comes with
regards,
Joris
[View Less]
Am Freitag, den 14.04.2006, 12:46 -0500 schrieb Alexandre Julliard:
> Author: Dmitry Timoshkov <dmitry(a)codeweavers.com>
> Date: Fri Apr 14 22:34:57 2006 +0900
>
> winspool: Add a test for GetPrinterDriver, make it pass under Wine.
Thanks for working on winspool.drv, but i'm Sorry that I had not
enough Time to look at the Patch before the commit.
- Version 0x0400 was correct for win9x-Drivers (4.00).
Version 3 is for Usermode-Drivers on w2k and above.
(Version 2 is …
[View More]Kernelmode-Driver for NT4.0 and w2k)
(Version 1 is NT3.5x and Version 0 is NT 3.1)
Our Registry-Location is for win9x only (OpenDriverReg)
- One Terminating Zero is is not enough for REG_MULTI_SZ
http://bugs.winehq.org/show_bug.cgi?id=3589
- Why was (PDRIVER_INFO_3W) changed to (PDRIVER_INFO_2W)?
(PDRIVER_INFO_3W) is an extended Version of (PDRIVER_INFO_2W)
- Not all Levels are supported on all Windows-Versions
http://msdn.microsoft.com/library/en-us/gdi/prntspol_7xo2.asp
- The tests are not alphabetical sorted after this commit
- Why was SetLastError(0xdeadbeef) used, when there is
SetLastError(MAGIC_DEAD) in the other tests
- 11 Tests are now failing on win95, 11 Tests on win98,
9 Tests on winme and 8 Tests on NT3.51.
For NT4.0 (level 4, 5 and 6 as well as the Version-Test will fail)
and w2k (version will fail, when an NT4.0-Driver is used), i can not
test the exact number of failures atm.
What's the preferred way to fix this?
My Idea:
1. Move the Test without any Changes
2. Fix the Tests
3. Fix the Implementation
I know, that you want a fast fix for your commercial Application and
winspool.drv is very ugly. I'm on the way to fix winspool.drv, but my
Direction is going from the Bottom-Layer to the High-Level API.
"struct printerenv_t" was created (as requested by Alexandre) to handle
the the different Printing-Environments for win9x-Drivers (Windows 4.0)
and NT-Drivers (Windows NT x86).
My fix for OpenDriverReg already need an Extension here, but
DeleteMonitor comes first.
You can Read more Infos here: http://wiki.winehq.org/Printing
--
By By ...
... Detlef
[View Less]
Tommy Kho wrote:
>This patch changes the behavior of selecting greyed out menu items via
>accelerator key. Wine currently keeps the menu open; Windows closes the menu.
> ...
> else
>+ {
> pmt->hCurrentMenu = MENU_ShowSubPopup(pmt->hOwnerWnd, hMenu, TRUE, wFlags);
>+ return -1;
>+ }
>
>- return -1;
>+ return -2;
> }
Err, isn't the return -2 at the bottom dead code now?
That seems wrong...
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Hi everybody!
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 …
[View More]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?
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
[View Less]
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.)
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
This is a lil bit off topic, but I thought I would bring it up, since we
have users that are trying to run windows BOINC under wine.
The wine project has a SETI@Home team (has had for some time), so if you run
the windows or linux BOINC/SETI@Home client, you can join our team and apply
your credits towards the project's total. Just go to
http://setiathome.berkeley.edu/team_display.php?teamid=38091 and click the
Join link.
Tom