April 2008 - Wine-Devel - list.winehq.org

Re: Proposal: versioning .wine directory

by Steven Edwards

On Mon, Mar 31, 2008 at 11:40 PM, TheBlunderbuss <tehblunderbuss(a)gmail.com> wrote: > I like it, since I already do something like this! > How about a more surreptitious way of marking versions? Maybe a reg key > or other file. > This way, users might not be tempted to rename their ~/.wine and also > keep the 1.0 transition smoother for scripts, say. Embedding the full version number maybe including the git ID of the source used as a string value in the Wine key should be enough. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

April 1, 2008

Re: Proposal: versioning .wine directory

by TheBlunderbuss

Dan Kegel wrote: > On the wine-users list, we're getting a lot of users who > have old or even ancient .wine directories, and > whose problems go away with a fresh .wine directory > > Perhaps we should have wineprefixcreate stamp the version > of wine the .wine directory was created with, > make wine-1.0 refuse to run with pre-1.0 .wine > directories, and require that future versions > of wine run properly with .wine directories created > by any earlier stable release of wine. > > It wouldn't be hard, at least at first, and it might save a lot of > support inquiries. What say? I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say.

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by Juan Lang

> But is the API in question useful for the Wine project as far as > fixing apps? I don't think we should devote SOC resources to a > project that doesn't progress Wine beyond just implementing more APIs. That's a good point. Alex, you'd probably want to specify which APIs in particular you're thinking of testing and implementing, and why they'd be useful for the Wine project. An app that uses them would be the easiest way to address their usefulness. And notice that in both my emails I said testing. Good test cases, in the form of regression tests added to Wine's test suite, are probably more important than the implementation would be. This is especially true of undocumented or poorly documented functions. Good luck, --Juan

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by James Hawkins

On Mon, Mar 31, 2008 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > Find a suite of third party applications and drivers that depend on > > the undocumented APIs otherwise your not going to get very far with > > getting your code in. > > Why is that? There are varying amounts of "undocumented." Not > documented on MSDN doesn't mean that no documentation exists. For > instance, there's Gary Nebbett's "Windows NT/2000 Native API > Reference." Personally, I've thought that playing around with the > native LPC API might be interesting. I'm sure there are other areas > of the native API that are sparsely documented, and for which some > test cases might prove useful. > But is the API in question useful for the Wine project as far as fixing apps? I don't think we should devote SOC resources to a project that doesn't progress Wine beyond just implementing more APIs. -- James Hawkins

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by Juan Lang

> Find a suite of third party applications and drivers that depend on > the undocumented APIs otherwise your not going to get very far with > getting your code in. Why is that? There are varying amounts of "undocumented." Not documented on MSDN doesn't mean that no documentation exists. For instance, there's Gary Nebbett's "Windows NT/2000 Native API Reference." Personally, I've thought that playing around with the native LPC API might be interesting. I'm sure there are other areas of the native API that are sparsely documented, and for which some test cases might prove useful. --Juan

April 1, 2008

Valgrind errors up the yin-yang in CloseServiceHandle

by Dan Kegel

I don't have the full results yet, but here's a clue as to today's warn+heap regression referred to in http://bugs.winehq.org/show_bug.cgi?id=12246 that affects every program: ==12026== Invalid read of size 4 ==12026== at 0x4BDAECD: RPCRT4_CloseBinding (rpc_binding.c:301) ==12026== by 0x4BE0DB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12026== by 0x4BC0BB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12026== by 0x49375E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12026== by 0x492F024: CloseServiceHandle (service.c:1008) ... ==12026== Address 0x7f000ec0 is not stack'd, malloc'd or (recently) free'd ==12019== Invalid read of size 4 ==12019== at 0x46E7F47: RtlEnterCriticalSection (critsection.c:482) ==12019== by 0x4986763: RpcAssoc_ReleaseIdleConnection (rpc_assoc.c:408) ==12019== by 0x4987F32: RPCRT4_CloseBinding (rpc_binding.c:308) ==12019== by 0x498DDB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12019== by 0x496DBB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12019== by 0x493E5E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12019== by 0x4936024: CloseServiceHandle (service.c:1008) ==12019== by 0x48F4206: main (wineboot.c:586) ==12019== Address 0x7f000da4 is not stack'd, malloc'd or (recently) free'd ==12019== Invalid read of size 4 ==12019== at 0x4986764: RpcAssoc_ReleaseIdleConnection (rpc_assoc.c:409) ==12019== by 0x4987F32: RPCRT4_CloseBinding (rpc_binding.c:308) ==12019== by 0x498DDB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12019== by 0x496DBB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12019== by 0x493E5E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12019== by 0x4936024: CloseServiceHandle (service.c:1008) ==12019== by 0x48F4206: main (wineboot.c:586) ==12019== Address 0x7f000d8c is not stack'd, malloc'd or (recently) free'd

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by Steven Edwards

On Mon, Mar 31, 2008 at 7:30 PM, a a <cholinesterase(a)gmail.com> wrote: > I made a proposal on GSoC to improve support for the Native API, an > undocumented API in Windows. I'd really like to code for the Wine Project, > since I like Windows, I like Linux, and I especially like low-level > scrounging. I'm usually available by MSN, and generally fairly friendly. > Send me an IM, or reply here to critique my proposal. It's entitled " > Proposal to improve Wine's support of the Native API". I'm registered as > cholinesterase(a)gmail.com. Find a suite of third party applications and drivers that depend on the undocumented APIs otherwise your not going to get very far with getting your code in. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

April 1, 2008