February 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] ntoskrnl.exe: Track drivers created with IoCreateDriver

by Sebastian Lackner

On 26.02.2016 21:22, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 64 +++++++++++++++++++++++++++++++++----------- > 1 file changed, 48 insertions(+), 16 deletions(-) > > > > 0002-ntoskrnl.exe-Track-drivers-created-with-IoCreateDriver.txt > > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 3bee2bf..49c8cab 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -72,6 +72,16 @@ static DWORD request_thread; > static DWORD client_tid; > static DWORD client_pid; > > +typedef struct _created_driver { > + struct list entry; > + > + UNICODE_STRING driver_name; > + DRIVER_OBJECT *driver_obj; > + DRIVER_EXTENSION *driver_extension; Isn't it possible to add the DRIVER_OBJECT and DRIVER_EXTENSION struct directly (without pointer), to avoid multiple memory allocations? I would also suggest to use a more meaningful name than "created_driver", and you also don't really need the typedef. Something like "struct wine_driver" would make more sense for example, but probably you have a better idea. ;) > +} created_driver; > + > +struct list created_drivers = LIST_INIT(created_drivers); > + > #ifdef __i386__ > #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ > __ASM_STDCALL_FUNC( name, 4, \ > @@ -818,36 +828,47 @@ PIRP WINAPI IoBuildSynchronousFsdRequest(ULONG majorfunc, PDEVICE_OBJECT device, > */ > NTSTATUS WINAPI IoCreateDriver( UNICODE_STRING *name, PDRIVER_INITIALIZE init ) > { > - DRIVER_OBJECT *driver; > - DRIVER_EXTENSION *extension; > + created_driver *driver; > NTSTATUS status; > > TRACE("(%s, %p)\n", debugstr_us(name), init); > > if (!(driver = RtlAllocateHeap( GetProcessHeap(), HEAP_ZERO_MEMORY, > - sizeof(*driver) + sizeof(*extension) ))) > + sizeof(*driver) ))) > + return STATUS_NO_MEMORY; > + > + if (!(driver->driver_obj = RtlAllocateHeap( GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*driver->driver_obj) + sizeof(*driver->driver_extension) ))) > + { > + RtlFreeHeap( GetProcessHeap(), 0, driver ); > return STATUS_NO_MEMORY; > + } > > - if ((status = RtlDuplicateUnicodeString( 1, name, &driver->DriverName ))) > + if ((status = RtlDuplicateUnicodeString( 1, name, &driver->driver_name ))) > { > + RtlFreeHeap( GetProcessHeap(), 0, driver->driver_obj ); > RtlFreeHeap( GetProcessHeap(), 0, driver ); > return status; > } > > - extension = (DRIVER_EXTENSION *)(driver + 1); > - driver->Size = sizeof(*driver); > - driver->DriverInit = init; > - driver->DriverExtension = extension; > - extension->DriverObject = driver; > - extension->ServiceKeyName = driver->DriverName; > + driver->driver_extension = (DRIVER_EXTENSION *)((BYTE*)driver->driver_obj + sizeof(*driver->driver_obj)); > + driver->driver_obj->DriverName = driver->driver_name; > + driver->driver_obj->Size = sizeof(*driver->driver_obj); > + driver->driver_obj->DriverInit = init; > + driver->driver_obj->DriverExtension = driver->driver_extension; > + driver->driver_extension->DriverObject = driver->driver_obj; > + driver->driver_extension->ServiceKeyName = driver->driver_name; > > - status = driver->DriverInit( driver, name ); > + status = driver->driver_obj->DriverInit( driver->driver_obj, name ); > > if (status) > { > - RtlFreeUnicodeString( &driver->DriverName ); > + RtlFreeUnicodeString( &driver->driver_name ); > + RtlFreeHeap( GetProcessHeap(), 0, driver->driver_obj ); > RtlFreeHeap( GetProcessHeap(), 0, driver ); > } > + > + list_add_tail( &created_drivers, &driver->entry ); Such a global list will need locking. > return status; > } > > @@ -855,12 +876,23 @@ NTSTATUS WINAPI IoCreateDriver( UNICODE_STRING *name, PDRIVER_INITIALIZE init ) > /*********************************************************************** > * IoDeleteDriver (NTOSKRNL.EXE.@) > */ > -void WINAPI IoDeleteDriver( DRIVER_OBJECT *driver ) > +void WINAPI IoDeleteDriver( DRIVER_OBJECT *driver_object ) > { > - TRACE("(%p)\n", driver); > + created_driver *driver, *next; > + > + TRACE("(%p)\n", driver_object); > + By putting the driver_object in the same struct, you could use CONTAINING_RECORD here. Also, a lock will be required while unlinking the driver from the list. > + LIST_FOR_EACH_ENTRY_SAFE(driver, next, &created_drivers, created_driver, entry) > + { > + if (driver->driver_obj == driver_object) > + { > + list_remove( &driver->entry ); > + RtlFreeUnicodeString( &driver->driver_name); > + break; > + } > + } > > - RtlFreeUnicodeString( &driver->DriverName ); > - RtlFreeHeap( GetProcessHeap(), 0, driver ); > + RtlFreeHeap( GetProcessHeap(), 0, driver_object ); > } > > > > >

Feb. 29, 2016

Re: [PATCH 1/3] winemac.drv: Fix our handling of bitmaps on the clipboard.

by Ken Thomases

On Feb 26, 2016, at 3:55 AM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > dlls/winemac.drv/clipboard.c | 87 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 76 insertions(+), 11 deletions(-) Mostly looks good. One request, though: please move create_bitmap_from_dib() to above import_clipboard_data(), just to keep all of the import_* functions together. Also, do you happen to have or know of a convenient program to test this with? Thanks, Ken

Feb. 29, 2016

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.

by Ken Thomases

On Feb 26, 2016, at 5:29 PM, Miklós Máté <mtmkls(a)gmail.com> wrote: > @@ -2320,6 +2322,7 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) > TRACE("(%p)\n", object); > > pglXDestroyPbuffer(gdi_display, object->drawable); > + pglXDestroyContext(gdi_display, object->tmp_context); I think you need to check if object->tmp_context is non-zero before calling glXDestroyContext() to avoid a GLXBadContext error. > + if (!object->tmp_context) { > + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + object->prev_context = prev_context; > + } else if (object->prev_context != prev_context) { > + pglXDestroyContext(gdi_display, object->tmp_context); > + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + object->prev_context = prev_context; > + } Those two branches are mostly the same. This could be reduced to: if (!object->tmp_context || object->prev_context != prev_context) { if (object->tmp_context) pglXDestroyContext(gdi_display, object->tmp_context); object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); object->prev_context = prev_context; } Is it necessary, when a context is destroyed, to go through all wgl_pbuffer structs looking for any whose prev_context matches the one being destroyed and clear it? Otherwise, you risk having a stale reference that could be reused for a different context and not realize you need to recreate tmp_context. Of course, enumerating all of them in a thread-safe manner is going to require a lot of added infrastructure and complexity. -Ken

Feb. 29, 2016

Re: Attachments missing in new wiki

by Kyle Auble

On 02/28/2016 08:31 AM, Rosanne DiMesio wrote: > On Sun, 28 Feb 2016 22:12:06 +0800 > Qian Hong <fracting(a)gmail.com> wrote: > >> Hi folks, >> >> Thanks for migrating the wiki to new site. >> [...] > The new wiki only allows uploading of files with png, gif, jpg, or jpeg extensions. There's also a 2MB limit on file size. > [...] One other possibility we discussed on a talk page was giving files like conference pictures a permanent home on the FTP server, then linking the wiki to them there. We can eventually base a decision on what Jeremy thinks is best, but I'm with Rosanne that we should at least lift the restriction on PDF files. At the risk of hijacking this thread, I did come up with a few questions while trying to update the SourceCode page. If I could get them cleared up, I can make the necessary changes to the wiki. Essentially, I'm not sure whether the new wiki has any custom code that will wind up in git, if there are any plans for the stagnant files on Sourceforge, and if/how we should document Dan Kegel's winezeug repo. I won't clutter up this email with the details, but I wrote them up here: https://wiki.winehq.org/Talk:Source_Code Kyle

Feb. 29, 2016

Re: GSoC Idea: Tools - Winetest Scripting Interface

by Henri Verbeet

On 28 February 2016 at 18:00, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > The interesting thing is splitting up the output of the big d3d tests > in e.g. dlls/d3d9/tests/visual.c into reasonable chunks, preferably > matching the functions the tests are in. So that you go from > "d3d9/visual is failing" to "d3d9/visual/depth_bounds_test failed, > d3d9/visual/test_vshader_input successful". > > Ideally this should be stable with regard to changes to the tests. > E.g. if 10 lines of code are added at the top of the file it shouldn't > break your output processing because the failing ok() lines are in > different lines of the file now. > It shouldn't be terribly hard to add a "function" argument to winetest_set_location(), although there may also be something to be said for introducing e.g. a winetest_begin_subtest() function instead.

Feb. 28, 2016

Re: GSoC Idea: Tools - Winetest Scripting Interface

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-02-28 um 13:32 schrieb Zhenbo Li: > IMHO, this project should provide a convenient interface for both > piglit and human developers. Do you have any ideas that which > function this script should provide? The interesting thing is splitting up the output of the big d3d tests in e.g. dlls/d3d9/tests/visual.c into reasonable chunks, preferably matching the functions the tests are in. So that you go from "d3d9/visual is failing" to "d3d9/visual/depth_bounds_test failed, d3d9/visual/test_vshader_input successful". Ideally this should be stable with regard to changes to the tests. E.g. if 10 lines of code are added at the top of the file it shouldn't break your output processing because the failing ok() lines are in different lines of the file now. The testbot is mostly able to do those things. I don't think it is able to match line number to function name though. Most of the tests in wine are not interesting to mesa. I expect them to care about d3d and GL related stuff, maybe gdi, but something like riched20 or wininet isn't really related to the GL library. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW0yerAAoJEN0/YqbEcdMw1V0P/2oJhxOHOiHmzKfOOjD7Mz9B EOrx40NdLzFsFOrMjTXp6iJCB/0WFxtUAqtK8KTM29sGT+FJoF+0roj59wIEfcm8 0x7esnhyOnFs6uj50DSHlByjF2BeqAxkfh/sYhgedS1XJJr2oW5UiHMiTRBW0ePb jF/2frdOnnpQH2IY/ruf/PW/bwX+kzzCAuHWm3cxB2pYMjfk9NoNp+gDyGrnJyAK u4zNXqvb/qMIcJjSwcnHlyr08rH6dcIYa7JcPNazzE5UGbHDX0z/Zl4XM2aayTOA lhBLQEYZiVebpcdJLXjVLdgc7jFSxY+nKgpUK3WYZ5SOSMMN7p/6sVWt6/3AxUQU BXs96luZ/g1myPJPSKGczfiWUz4Ij+1qd6SY+zlhjlkC0uNKqUb05zt1EPf5vVci QWfbfikwqQdEimkYFduE6Mdfta/tL3lqibeLomdBSk/Mx9ku28pKEnLGYZfh8BAM ZUtQJDfiAGTkaQEV8DCoAKqsIV6e1Ao49Ma8+o4upaktPj6NSUejy6Inkz9D5zWR nqyrJvme+z63BHeOJxyL9+XGu4WjPwPsTbbfXuUNtWhW16mRi3R6dmBaVZm+ecgM KXNctlVQdbgKkpQCE8e5qE4wKTpLjPL9aVmLzH3bxbVNIw6lRUJ0pqjATca82MZL 3HGnwp9DWSzEYoJvbp0r =JQlp -----END PGP SIGNATURE-----

Feb. 28, 2016

Re: Attachments missing in new wiki

by Rosanne DiMesio

On Sun, 28 Feb 2016 22:12:06 +0800 Qian Hong <fracting(a)gmail.com> wrote: > Hi folks, > > Thanks for migrating the wiki to new site. Recently two different > people ask me about attachments on > https://wiki.winehq.org/WineConf2015, and I found they are missing, > anyone knows what happen during the migration? Should we manually > upload again? Is there backup for the attachments from old side? > The new wiki only allows uploading of files with png, gif, jpg, or jpeg extensions. There's also a 2MB limit on file size. That's not something that can be changed in the admin interface; Jeremy Newman would have to do that. IMO, since editing is now locked down to "Trustworthy" users, it should be safe to allow other types of files (at least PDF) to be uploaded. For now you can link to the files on the old wiki, but since the old wiki might go away at some point, that's not a long term solution. -- Rosanne DiMesio dimesio(a)earthlink.net

Feb. 28, 2016

Re: Attachments missing in new wiki

by Jactry Zeng

2016-02-28 22:12 GMT+08:00 Qian Hong <fracting(a)gmail.com>: > > Is there backup for the attachments from old side? The old wiki is here: http://oldwiki.winehq.org/WineConf2015 It seems there are some pages need to be copied to the new one. -- Regards, Jactry Zeng

Feb. 28, 2016

Re: Attachments missing in new wiki

by Aaryaman Vasishta

I'm wondering the same. The high resolution group picture is not there anymore? Cheers, Aaryaman On Sun, Feb 28, 2016 at 7:42 PM, Qian Hong <fracting(a)gmail.com> wrote: > Hi folks, > > Thanks for migrating the wiki to new site. Recently two different > people ask me about attachments on > https://wiki.winehq.org/WineConf2015, and I found they are missing, > anyone knows what happen during the migration? Should we manually > upload again? Is there backup for the attachments from old side? > > Thanks! > > -- > Regards, > Qian Hong > > - > http://www.winehq.org > > >

Feb. 28, 2016

Attachments missing in new wiki

by Qian Hong

Hi folks, Thanks for migrating the wiki to new site. Recently two different people ask me about attachments on https://wiki.winehq.org/WineConf2015, and I found they are missing, anyone knows what happen during the migration? Should we manually upload again? Is there backup for the attachments from old side? Thanks! -- Regards, Qian Hong - http://www.winehq.org

Feb. 28, 2016