wine-devel April 2012

wine-devel@winehq.org

76 participants
181 discussions

Re: winedump: Add basic support for dumping the property store in lnk files.
by Dmitry Timoshkov 06 Apr '12

06 Apr '12

Vincent Povirk <madewokherd(a)gmail.com> wrote: > +typedef struct tagLINK_PROPERTYSTORAGE_VALUE > +{ > + DWORD size; > + DWORD pid; > + BYTE unknown8; > + DWORD vt; > + DWORD unknown25; > +} LINK_PROPERTYSTORAGE_VALUE; You probably need an appropriate packing for this structure. -- Dmitry.

2 2

[GSoC] Control panel proposal
by Magdalena Nowak 05 Apr '12

05 Apr '12

Hi, my name is Magdalena Nowak and I'd like to apply for this year's Summer of Code with Wine. My proposal is to merge the two control panel suggestions (Tools - Merge winecfg and control panel and Tools - Implement new control panel applets) into one project. I would start off with splitting winecfg into several applets. Roughly, each tab would become a new applet. The Applications applet would only be used to register applications with the control panel to allow the user to specify custom settings for that application. I would like to merge the Graphics tab with the Appearance section of Desktop Integration (and this applet would be the place where the 3D settings would go later) and merge the Folders section with the Drives tab into one applet. Later on, I will start implementing new applets. For example, create a Networking applet for the network-related settings, maybe a simple diagnostics tool (a read-only applet with information regarding build options and system resources), Fonts (both list of fonts available to Wine as well as hinting and DPI settings), a System applet for settings like owner name, Windows version, libraries etc. There is a problem with per-application settings. I have three possible solutions to this problem. I have made pictures to illustrate what I mean. One would be to simply add a drop-down list to each applet that contains settings that can be per-application settings. The drop-down list would contain a "global" entry, as well as entries for each application registered through the Applications applet. Upon selecting an entry, the applet would load the settings for this program. The second solution would be to have a separate applet for per-application settings. The screens would be stored in a DLL, for example, as to avoid duplication. The third, and my favourite, solution, is to create a virtual control panel for each registered application. The user would be able to select the application or global settings from some kind of list, and the applets would be passed an argument to indicate the selected application. If a specific setting was global-only, it would be highlighted appropriately. Here are the promised images: http://imgur.com/T4pUV - Showing the drop-down menu at the top of the applet window. http://imgur.com/vA1Vq - Showing the per-application settings applet. http://imgur.com/is63I - Showing the control panel with an application selected, and a Graphics applet showing a global-only setting. Of course these are only examples, I welcome any comments. I will post a proposal on Melange soon. Yours, 'Lena.

2 2

[3/3] shell32: Add test for STARTF_TITLEISAPPID flag.
by Vincent Povirk 05 Apr '12

05 Apr '12

1 1

urlcache: what all are you working on?
by Juan Lang 05 Apr '12

05 Apr '12

Hi Morten and Piotr, I notice both of you are working on wininet's url cache. That's great: it's largely bitrot, and has been for years. My question is, what are you planning to fix? It seems like you're both running into some of the same issues right now, and it would be nice if you could coordinate a little. Ok, I lie: it'd be nice to get code from both of you ;) If I were to guess, it looks like you're both working on eliminating corruption and deadlocks, both of which can occur right now. Fantastic. Another thing that'd be nice to see is reducing the amount of disk space used. Morten, some of the patches you sent me do some of that, by removing files once they're no longer in use. (The patches I have do that too.) Piotr, were you planning to address this too? A question that I have to ask is, would be better to eliminate the url cache altogether? Right now its only utility is to pass test cases, and conveniently fill up your disk. No requests are ever fulfilled from the cache. Either of you have any plans to tackle that? Thanks, --Juan

3 2

qemu still can't run x86 wine
by Dan Kegel 05 Apr '12

05 Apr '12

http://wiki.winehq.org/ARM says commands like $ qemu-i386 /usr/local/qemu-i386/wine/bin/wine /usr/local/qemu-i386/wine/c/Program\ Files/putty.exe used to work, but doesn't anymore. I gave it a shot anyway, just trying to run x86 apps inside wine inside qemu: wget http://wiki.qemu.org/download/qemu-1.0.1.tar.gz tar -xzvf qemu-1.0.1.tar.gz cd qemu-1.0.1 ./configure --prefix=/usr/local/qemu --target-list=i386-linux-user make # Compilation fails; to work around, edit linux-user/syscall.c and # replace soundcard.h with soundcard.h.oss3 make sudo make install # Verify that qemu can run a trivial binary /usr/local/qemu/bin/qemu-i386 /bin/uname -a # Verify you can run wine a little /usr/local/qemu/bin/qemu-i386 /usr/bin/wine --version # Now run a real app /usr/local/qemu/bin/qemu-i386 /usr/bin/wine cmd /c echo hi qemu: Unsupported syscall: 240 # Huh. That didn't work. OK, try sh: /usr/local/qemu/bin/qemu-i386 /bin/sh $ ls /bin/sh: 1: Cannot fork The syscall error seems to be https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/758424 "We only implement the futex syscalls if CONFIG_USE_NPTL. This isn't defined for the i386 target (the necessary support in target-i386 for pushing atomic insns up to the linux-user top level loop isn't implemented). The upshot is that running multithreaded programs in linux-user i386-target isn't supported and this is just one of the symptoms." Dunno about the fork error. So it looks like anyone hoping to run x86 wine in qemu would need to fix qemu first and/or go back to an old wine that doesn't use nptl?

1 0

Google Summer of Code Project: Implement missing D3DX libraries
by Alexander Mezin 05 Apr '12

05 Apr '12

Hello. I want to participate in GSoC and work on project "Direct3D: Implement missing D3DX libraries", listed at http://wiki.winehq.org/SummerOfCode. I have experience of developing for Windows using Direct3D 9 and D3DX, so I think I'm the one who you need for this project. About two years ago I reimplemented some D3DX functionality using Direct3D for a casual game, because these D3DX_XX libraries caused problems with distribution. Sadly, all this code is lost, but there was nothing hard to implement, or, at least no such things was used in the game. Usually only D3DXSprite, D3DXFont and, maybe, effect framework are used. And also nothing really changes between D3DX versions, usually only some methods are renamed or their parameters are reordered. I want to contact possible mentor to discuss what parts of the libraries must be implemented, but I can't find his e-mail, wiki says that his page isn't created.

2 1

My GSoC proposition: Raw Input
by Eryk Wieliczko 05 Apr '12

05 Apr '12

I've been thinking about joining GSoC as a student this year. As an idea I propose Raw Input, and I seek your advise. Is this topic good, what are possible catches, etc. I think that it might be possible to finally do a decent implementation, that would (besides mouse and keyboard) also support joysticks and possibly some other input devices - tablets and multiple mice and keyboards. What do you think about this topic? Links: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).a… http://appdb.winehq.org/viewbugs.php?bug_id=20395 http://bugs.winehq.org/show_bug.cgi?id=20395

3 3

Re: [PATCH 1/1] ntdll: Fix section header heap deadlock (try 2).
by Alexandre Julliard 05 Apr '12

05 Apr '12

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Description: > Free the section header memory outside of the uninterrupted > section lock. Changing the order here stops the process heap from > potentially deadlocking (Bug #30356). The allocation will still be an issue. I think a better approach would be to avoid any memory allocation in there. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/5] wined3d: Enable "AlwaysOffscreen" by default.
by Alexandre Julliard 05 Apr '12

05 Apr '12

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/wined3d/wined3d_main.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) It doesn't work here (GeForce 8500, driver 295.20): ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so visual.c && touch visual.ok visual.c:1385: Tests skipped: D3DFMT_P8 textures not supported visual.c:2011: Test failed: Expected color 0x000000ff at 80,60, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x000000ff at 240,60, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x0000ff00 at 400,60, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x000000ff at 80,180, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x000000ff at 240,180, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x0000ff00 at 400,180, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x0000ff00 at 80,300, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x0000ff00 at 240,300, got 0x00ff0000. visual.c:2011: Test failed: Expected color 0x0000ff00 at 400,300, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 80,60, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 240,60, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 400,60, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 560,60, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 80,180, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 240,180, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 400,180, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 560,180, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 80,300, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 240,300, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 400,300, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 560,300, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 80,420, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 240,420, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 400,420, got 0x00ff0000. visual.c:2111: Test failed: Expected color 0x0000ff00 560,420, got 0x00ff0000. visual.c:2824: Tests skipped: No RESZ support, skipping RESZ test. make: *** [visual.ok] Error 25 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: (try 2)quartz: add control.idl as a typelib resource
by Huw Davies 05 Apr '12

05 Apr '12

On Thu, Apr 05, 2012 at 07:51:13AM -0500, Aric Stewart wrote: > > revised based on comments from Jacek Caban > --- > dlls/quartz/Makefile.in | 1 + > dlls/quartz/control_v2.idl | 17 +++++++++++++++++ > 2 files changed, 18 insertions(+), 0 deletions(-) > create mode 100644 dlls/quartz/control_v2.idl Calling this control_v2.idl seems a little odd. control_tlb.idl may be better. Huw.

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2012