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

Re: Better user feedback and better user experience (idea)

by Sander Devrieze

2008/12/18 Ben Klein <shacklein(a)gmail.com>: > 2008/12/18 Sander Devrieze <s.devrieze(a)linux.be>: >> 2008/12/17 Scott Ritchie <scott(a)open-vote.org>: >> <snip> >>> If it's that users blame the distro when it's a Wine problem, then we >>> can present them with some sort of information before installing (or >>> perhaps running) Wine. After that we should get out of the way and let >>> them use Wine as normal. > > Is it a goal for Wine to be included as standard in distros? I'd say > not. The correct solution is *nix-native applications. E.g., how many > people use utorrent in Wine when they could use Deluge or > Transmission? Sure, Wine's goal should include support for apps like > utorrent (in that Wine's goal is to run as many Windows apps as > possible), but they shouldn't be prefered over *nix-native apps. > >> Wine should go out of way when the Windows application is known to run >> very well under Wine or when the user submitted feedback for this >> application in the past. Also, the user easily can skip the dialog. > > Known by whom? Are you suggesting appdb scraping? No, I was thinking about including a list of hashes for the applications that are officially supported in the Wine distribution. >>> If the problem is that we're not getting enough feedback, then a default >>> feedback nag might not be the best answer either. >> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. > > Sounds elaborate to me :) Though the winewatson sounds like it could > handle this sort of thing. > >> I guess this kind of feedback can be very powerful to Wine coders to >> create statistics like these: >> * Most popular API calls >> * Least popular API calls >> * Most common API calls that make applications fail >> * Unimplemented features used by very uncommon software (e.g. >> custom-built applications within companies) >> * Predicting the likelihood that a specific API call will be used when >> another API call is used in an application >> >> Maybe this information can be useful to detect which applications are >> affected by a bug in Wine. When this is known, testers can verify in >> multiple applications if the bug really is fixed in all applications. > > From what I've seen, most bugs in Wine aren't detectable by software - > it THINKS it's working fine, but the user can tell it's not :) In any > case, this would require a potentially large database of known bugs > and their symptoms ... I meant that this database can be used to see if a *manually* reported bug may also affect other applications. So, developers and testers can get a list of software that can be used to see if the bug is fixed. >>> reports from stable or nonlatest versions would be largely ignored, and >>> users of the latest beta can be asked to contribute in other ways, such >>> as on the download page itself. >>> >>> Remember, it doesn't take much work for us to know that an application >>> doesn't work - a single bug report can do that. Once we have that, we >>> don't need to ask a million other users (literally) for confirmation. >> >> Only geeks file good bug reports. Normal people don't care and will >> not spend energy on this. > > There's been a lot of talk recently about targeting Wine towards > end-users, e.g. the redesign of the website. It sounds like a great > idea, but Wine is still very much a developer's tool. It's not > user-friendly, and it won't be for a very long time, if ever. Most end-users primarily don't report bugs because they don't want to spend time on this. > winewatson sounds like a developer's debugging tool, but it could > prove useful for improving bad bug reports. > > Note that Microsoft has a system where any old application crash can > send a bug report to Microsoft. It's basically spamming yourself :) -- Mvg, Sander Devrieze.

Dec. 18, 2008

RE: WineD3D: add some new GL extensions

by Stefan Dösinger

Did you send it to wine-devel intentionally? IMHO there's not much use for adding the extensions to the extension list without making use of them. I think this should be done in one patch. > -----Original Message----- > From: wine-devel-bounces(a)winehq.org [mailto:wine-devel- > bounces(a)winehq.org] On Behalf Of Roderick Colenbrander > Sent: Wednesday, December 17, 2008 11:22 PM > To: wine-devel(a)winehq.org > Subject: WineD3D: add some new GL extensions > > Hi, > > Add some new GL extensions which are needed for better d3d9 floating > point support for R32F/RG32F and friends. > > Roderick > -- > Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für > nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 18, 2008

Re: wininet: Relax a notification test.

by Paul Vriens

Hans Leidekker wrote: > diff --git a/dlls/wininet/tests/http.c b/dlls/wininet/tests/http.c > index 6554680..8b3a8f8 100644 > --- a/dlls/wininet/tests/http.c > +++ b/dlls/wininet/tests/http.c > @@ -325,8 +325,8 @@ static void InternetReadFile_test(int flags) > SET_EXPECT2(INTERNET_STATUS_REQUEST_SENT, 2); > SET_EXPECT2(INTERNET_STATUS_RECEIVING_RESPONSE, 2); > SET_EXPECT2(INTERNET_STATUS_RESPONSE_RECEIVED, 2); > - SET_EXPECT2(INTERNET_STATUS_CLOSING_CONNECTION, 2); > - SET_EXPECT2(INTERNET_STATUS_CONNECTION_CLOSED, 2); > + SET_OPTIONAL2(INTERNET_STATUS_CLOSING_CONNECTION, 2); > + SET_OPTIONAL2(INTERNET_STATUS_CONNECTION_CLOSED, 2); > SET_EXPECT(INTERNET_STATUS_REDIRECT); > SET_OPTIONAL(INTERNET_STATUS_CONNECTING_TO_SERVER); > SET_OPTIONAL(INTERNET_STATUS_CONNECTED_TO_SERVER); > > > Hi Hans, Apparently that's not enough to fix the tests. Although it's set to be optional we are still using CHECK_NOTIFIED2 that doesn't make use of the optional parameter. -- Cheers, Paul.

Dec. 18, 2008

Re: Better user feedback and better user experience (idea)

by Austin English

On Thu, Dec 18, 2008 at 8:07 AM, Steve Brown <sbrown7(a)umbc.edu> wrote: > On Wed, 17 Dec 2008, Austin English wrote: > >> In a few years when Wine is more developed and has most the API >> implemented, this may be useful, but there's still a lot to do, and we >> don't need more reports to tell us this. > > Keep in mind that the Windows API is a moving target. In a few years, the > API will be no more completely implemented than it is today -- it will just > be a different set of calls that aren't done than it is today. > > Steve Brown > sbrown7(a)umbc.edu > Of course, didn't meant to imply that it will be complete at that time, but will be moreso than it is now, especially in regards to older API functions. -- -Austin

Dec. 18, 2008

Re: Better user feedback and better user experience (idea)

by Steve Brown

On Wed, 17 Dec 2008, Austin English wrote: > In a few years when Wine is more developed and has most the API > implemented, this may be useful, but there's still a lot to do, and we > don't need more reports to tell us this. Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today. Steve Brown sbrown7(a)umbc.edu

Dec. 18, 2008

Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.

by Aric Stewart

Ahh ok, thanks. Will do. -aric Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> Since I value your input in imm32 and i do a lot of work there. If you >> would like to send me that high level overview then I can see if it >> works into wine. That way you can continue to contribute and we do not >> compromise the source code. > > No, please don't do that. We don't want to have people disassemble > Windows code at all, even to write high level descriptions. There's > simply no need for it, just write test cases. >

Dec. 18, 2008

re: winewtsn: add a new program that shows a dialog to inform about a crash

by Dan Kegel

Alexandre wrote: > I'd suggest to do that in winedbg, there's no need to add another > Wine-specific program for that. Windows uses three different automatically started debuggers: the visual C++ debugger for average programmers, windbg for superprogrammers, and Dr. Watson for users who just need a user-friendly crash handler. I think Mikolaj was simply trying to provide an implementation of the latter. Does it really make sense to make one program serve both roles, given that Microsoft doesn't do it that way? - Dan

Dec. 18, 2008

Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > Since I value your input in imm32 and i do a lot of work there. If you > would like to send me that high level overview then I can see if it > works into wine. That way you can continue to contribute and we do not > compromise the source code. No, please don't do that. We don't want to have people disassemble Windows code at all, even to write high level descriptions. There's simply no need for it, just write test cases. -- Alexandre Julliard julliard(a)winehq.org

Dec. 18, 2008

Re: mshtml: Add some interfaces in mshtml.idl (try 3) (resend)

by Alistair Leslie-Hughes

Hi Konstantin, "Konstantin Kondratyuk" <kondratyuk(a)etersoft.ru> wrote in message news:200812181251.50439.kondratyuk(a)etersoft.ru... > Add: > ILineInfo > IDisplayPointer > IDisplayPointer > IHTMLComputedStyle > IDisplayServices > IMarkupServices > > -- You have converted some OLECHAR* to "unsigned short* in functions InsertText, CreateElement to name a few. Best Regards Alistair Leslie-Hughes

Dec. 18, 2008

Re: Compiling dbghelp with MinGW

by Francois Gouget

On Sat, 13 Dec 2008, Eric Pouech wrote: [...] > > 1) #ifdef-out regexp support if regex.h is missing? Maybe with an > > autoconf check for regcomp()? > > 2) Add some reg*() stubs that do nothing if regex.h & co are missing? [...] > 1,2) most of the dbghelp code will be of no use if no regex support is present It still feels wrong for Wine to fail compiling just because a regular expression library is missing. If we can compile Wine without X we should be able to compile it without a regular expression library. [...] > *** new option *** 5) use a regex lib for mingw... that work(ed) just fine > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=73286… I will install it. It would be nice if they had a Debian package for it. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Dec. 18, 2008

Functions that should be static

by Francois Gouget

I have attached a script that identifies functions that should be made static (among other things). There are approximately 450 of them, there should be pretty efw false positives, and I will look into them eventually. But if someone beats me to it I sure won't complain <g>. So if you do try to tackle them you are likely to find that they fall into one of the following categories: 1) Unused debug functions. For instance for dumping the contents of a structure to stderr. Although these are unused we probably want to keep them. Let me know about these and I will put them in an exception list. 2) Functions that should be exported by a spec file It happens. Sometimes the developer implementing a function just forgets to add it to the spec file! 3) Generated functions This typically happens with widl: it generates a bunch of functions for the client / server and proxy cases, but these functions may be unused. I have special code to not warn about these, but there may be other cases. For instance in the list below you will find a number of yy*() functions generated by lex. Either we can tell lex to make them static or to not generate them, or I should make another special case. If you find some of these, let me know. 4) Assembly functions I believe there should not be any of these in the list below. So if you find one let me know. 5) Functions declared in a private header file but implemented and used from a single C file. I'm in favor of removing these functions from the private header and making them static. 6) All the others should be pretty clear-cut. dlls/advapi32/advapi32.dll.so: CRYPT_DESkey8to7 dlls/browseui/tests/browseui_test.exe.so: strdup_AtoW dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_Clone dlls/browseui/tests/browseui_test.exe.so: TestACL_Expand dlls/browseui/tests/browseui_test.exe.so: TestACL_Next dlls/browseui/tests/browseui_test.exe.so: TestACL_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_Reset dlls/browseui/tests/browseui_test.exe.so: TestACL_Skip dlls/cabinet/cabinet.dll.so: checksum dlls/cabinet/cabinet.dll.so: make_decode_table dlls/cabinet/cabinet.dll.so: QTMupdatemodel dlls/comctl32/tests/comctl32_test.exe.so: flush_sequence dlls/comdlg32/comdlg32.dll.so: CC_WMCommand dlls/crypt32/crypt32.dll.so: ContextList_Empty dlls/dbghelp/dbghelp.dll.so: hash_table_find dlls/dbghelp/dbghelp.dll.so: hash_table_hash dlls/dbghelp/dbghelp.dll.so: module_find_by_name dlls/dbghelp/dbghelp.dll.so: module_get_container dlls/dinput/dinput.dll.so: DIEnumDevicesCallbackAtoW dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicobjImpl dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicPatternTrackImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicBufferImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadedInstrumentImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadImpl dlls/dnsapi/dnsapi.dll.so: dns_ns_name_pton dlls/dplayx/dplayx.dll.so: cbDeleteGroupsElem dlls/dplayx/dplayx.dll.so: cbDeletePlayerElem dlls/dplayx/dplayx.dll.so: DPLAYX_DestroyLobbyApplication dlls/dplayx/dplayx.dll.so: DPLAYX_SetLocalSession dlls/dplayx/dplayx.dll.so: NS_GetOtherMagic dlls/dplayx/dplayx.dll.so: NS_SetRemoteComputerAsNameServer dlls/dsound/dsound.dll.so: DirectSoundCaptureDevice_AddRef dlls/fusion/fusion.dll.so: assembly_get_architecture dlls/fusion/fusion.dll.so: CompareAssemblyIdentity dlls/fusion/fusion.dll.so: GetAssemblyIdentityFromFile dlls/inetcomm/inetcomm.dll.so: InternetTransport_Read dlls/iphlpapi/iphlpapi.dll.so: getInterfaceEntryByIndex dlls/iphlpapi/iphlpapi.dll.so: getInterfacePhysicalByName dlls/itss/itss.dll.so: chm_enumerate dlls/jscript/jscript.dll.so: jsdisp_call dlls/jscript/jscript.dll.so: parser_parse dlls/mountmgr.sys/mountmgr.sys.so: DriverEntry dlls/msacm32/msacm32.dll.so: MSACM_UnregisterLocalDriver dlls/mshtml/mshtml.dll.so: HTMLElementCollection_Create dlls/msi/msi.dll.so: cond_parse dlls/msi/msi.dll.so: ControlEvent_UnSubscribeToEvent dlls/msi/msi.dll.so: db_get_raw_stream dlls/msi/msi.dll.so: encode_streamname dlls/msi/msi.dll.so: find_published_source dlls/msi/msi.dll.so: MSI_DatabaseExport dlls/msi/msi.dll.so: MSI_DatabaseImport dlls/msi/msi.dll.so: msi_dialog_register_class dlls/msi/msi.dll.so: MSI_EnableUIPreview dlls/msi/msi.dll.so: msi_id2stringA dlls/msi/msi.dll.so: msi_id2stringW dlls/msi/msi.dll.so: msi_load_media_info dlls/msi/msi.dll.so: MSI_PreviewDialogW dlls/msi/msi.dll.so: MSI_RecordDataSize dlls/msi/msi.dll.so: MSI_RecordSetStream dlls/msi/msi.dll.so: MSI_RecordSetStringA dlls/msi/msi.dll.so: MSIREG_OpenInstallerFeaturesKey dlls/msi/msi.dll.so: msi_strcmp dlls/msi/msi.dll.so: msi_string2idA dlls/msi/msi.dll.so: msi_ui_error dlls/msi/msi.dll.so: msi_version_dword_to_str dlls/msi/msi.dll.so: reduce_to_shortfilename dlls/msi/msi.dll.so: sql_parse dlls/msxml3/msxml3.dll.so: httprequest_Release dlls/msxml3/msxml3.dll.so: XMLElementCollection_create dlls/netapi32/netapi32.dll.so: NBNameCacheUpdateNBName dlls/ole32/ole32.dll.so: IMalloc16_Constructor dlls/qcap/qcap.dll.so: FreeMediaType dlls/qcap/qcap.dll.so: IPinImpl_QueryInternalConnections dlls/quartz/quartz.dll.so: MemInputPin_AddRef dlls/quartz/quartz.dll.so: MemInputPin_GetAllocator dlls/quartz/quartz.dll.so: MemInputPin_GetAllocatorRequirements dlls/quartz/quartz.dll.so: MemInputPin_NotifyAllocator dlls/quartz/quartz.dll.so: MemInputPin_QueryInterface dlls/quartz/quartz.dll.so: MemInputPin_Receive dlls/quartz/quartz.dll.so: MemInputPin_ReceiveCanBlock dlls/quartz/quartz.dll.so: MemInputPin_ReceiveMultiple dlls/quartz/quartz.dll.so: MemInputPin_Release dlls/quartz/quartz.dll.so: OutputPin_DeliverNewSegment dlls/riched20/riched20.dll.so: ME_ConcatString dlls/riched20/riched20.dll.so: ME_CopyToCF2W dlls/riched20/riched20.dll.so: ME_DestroyEditor dlls/riched20/riched20.dll.so: ME_DITypesEqual dlls/riched20/riched20.dll.so: ME_DrawParagraph dlls/riched20/riched20.dll.so: ME_FindItemFwdOrHere dlls/riched20/riched20.dll.so: ME_FindNextURLCandidate dlls/riched20/riched20.dll.so: ME_FindRowStart dlls/riched20/riched20.dll.so: ME_GetOptimalBuffer dlls/riched20/riched20.dll.so: ME_GetParaFormat dlls/riched20/riched20.dll.so: ME_GetYScrollVisible dlls/riched20/riched20.dll.so: ME_InvalidateFromOfs dlls/riched20/riched20.dll.so: ME_IsCandidateAnURL dlls/riched20/riched20.dll.so: ME_LinkNotify dlls/riched20/riched20.dll.so: ME_MakeEditor dlls/riched20/riched20.dll.so: ME_MakeStringB dlls/riched20/riched20.dll.so: ME_MarkForWrapping dlls/riched20/riched20.dll.so: ME_QueueInvalidateFromCursor dlls/riched20/riched20.dll.so: ME_Scroll dlls/riched20/riched20.dll.so: ME_SelectByType dlls/riched20/riched20.dll.so: ME_SetParaFormat dlls/riched20/riched20.dll.so: ME_ToCFAny dlls/riched20/riched20.dll.so: ME_UpdateLinkAttribute dlls/riched20/riched20.dll.so: ME_UpdateSelection dlls/riched20/riched20.dll.so: ME_UpdateSelectionLinkAttribute dlls/riched20/riched20.dll.so: REComboWndProc dlls/riched20/riched20.dll.so: REListWndProc dlls/riched20/riched20.dll.so: RTFExpandStyle dlls/riched20/riched20.dll.so: RTFGetClassCallback dlls/riched20/riched20.dll.so: RTFGetDestinationCallback dlls/riched20/riched20.dll.so: RTFGetInputName dlls/riched20/riched20.dll.so: RTFGetOutputName dlls/riched20/riched20.dll.so: RTFGetReadHook dlls/riched20/riched20.dll.so: RTFGetStyle dlls/riched20/riched20.dll.so: RTFHexToChar dlls/riched20/riched20.dll.so: RTFPeekToken dlls/riched20/riched20.dll.so: RTFSetClassCallback dlls/riched20/riched20.dll.so: RTFSetInputName dlls/riched20/riched20.dll.so: RTFSetOutputName dlls/riched20/riched20.dll.so: RTFSetToken dlls/riched20/riched20.dll.so: RTFUngetToken dlls/rpcrt4/rpcrt4.dll.so: NCA2RPC_STATUS dlls/rpcrt4/rpcrt4.dll.so: NdrByteCountPointerMemorySize dlls/rpcrt4/rpcrt4.dll.so: NdrRangeBufferSize dlls/rpcrt4/rpcrt4.dll.so: NdrRangeFree dlls/rpcrt4/rpcrt4.dll.so: NdrRangeMarshall dlls/rpcrt4/rpcrt4.dll.so: NdrRangeMemorySize dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_receive_fragment dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_SpawnConnection dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_ValidateCommonHeader dlls/rsaenh/rsaenh.dll.so: alloc_handle_table dlls/rsaenh/rsaenh.dll.so: mp_2expt dlls/rsaenh/rsaenh.dll.so: mp_abs dlls/rsaenh/rsaenh.dll.so: mp_add_d dlls/rsaenh/rsaenh.dll.so: mp_clamp dlls/rsaenh/rsaenh.dll.so: mp_clear dlls/rsaenh/rsaenh.dll.so: mp_cmp_mag dlls/rsaenh/rsaenh.dll.so: mp_cnt_lsb dlls/rsaenh/rsaenh.dll.so: mp_div dlls/rsaenh/rsaenh.dll.so: mp_div_2 dlls/rsaenh/rsaenh.dll.so: mp_div_2d dlls/rsaenh/rsaenh.dll.so: mp_div_d dlls/rsaenh/rsaenh.dll.so: mp_dr_reduce dlls/rsaenh/rsaenh.dll.so: mp_dr_setup dlls/rsaenh/rsaenh.dll.so: mp_exch dlls/rsaenh/rsaenh.dll.so: mp_grow dlls/rsaenh/rsaenh.dll.so: mp_init dlls/rsaenh/rsaenh.dll.so: mp_init_size dlls/rsaenh/rsaenh.dll.so: mp_lshd dlls/rsaenh/rsaenh.dll.so: mp_mod_2d dlls/rsaenh/rsaenh.dll.so: mp_mod_d dlls/rsaenh/rsaenh.dll.so: mp_montgomery_calc_normalization dlls/rsaenh/rsaenh.dll.so: mp_montgomery_reduce dlls/rsaenh/rsaenh.dll.so: mp_montgomery_setup dlls/rsaenh/rsaenh.dll.so: mp_mul_2 dlls/rsaenh/rsaenh.dll.so: mp_mul_2d dlls/rsaenh/rsaenh.dll.so: mp_mul_d dlls/rsaenh/rsaenh.dll.so: mp_prime_is_divisible dlls/rsaenh/rsaenh.dll.so: mp_prime_is_prime dlls/rsaenh/rsaenh.dll.so: mp_prime_miller_rabin dlls/rsaenh/rsaenh.dll.so: mp_reduce dlls/rsaenh/rsaenh.dll.so: mp_reduce_2k dlls/rsaenh/rsaenh.dll.so: mp_reduce_2k_setup dlls/rsaenh/rsaenh.dll.so: mp_reduce_setup dlls/rsaenh/rsaenh.dll.so: mp_rshd dlls/rsaenh/rsaenh.dll.so: mp_set dlls/rsaenh/rsaenh.dll.so: mp_signed_bin_size dlls/rsaenh/rsaenh.dll.so: mp_sqr dlls/rsaenh/rsaenh.dll.so: mp_sqrmod dlls/rsaenh/rsaenh.dll.so: mp_zero dlls/rsaenh/rsaenh.dll.so: release_handle_table dlls/sane.ds/sane.ds.so: SANE_AutomaticCaptureDirectory dlls/sane.ds/sane.ds.so: SANE_FileSystemCopy dlls/sane.ds/sane.ds.so: SANE_PendingXfersStopFeeder dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Get dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2GetDefault dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Reset dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Set dlls/secur32/secur32.dll.so: SECUR32_initNegotiateSP dlls/secur32/secur32.dll.so: SECUR32_strdupW dlls/setupapi/setupapi.dll.so: PARSER_string_substW dlls/setupapi/setupapi.dll.so: VcpEnumFiles dlls/setupapi/setupapi.dll.so: VcpFlush16 dlls/setupapi/setupapi.dll.so: vsmStringCompare16 dlls/setupapi/setupapi.dll.so: vsmStringFind16 dlls/shell32/shell32.dll.so: HCR_GetDefaultIconFromGUIDW dlls/shell32/shell32.dll.so: ILGetDisplayNameExA dlls/shell32/shell32.dll.so: _ILGetSTextPointer dlls/shell32/shell32.dll.so: _ILGetTextPointerW dlls/shell32/shell32.dll.so: RenderFILECONTENTS dlls/shell32/shell32.dll.so: RenderFILEDESCRIPTOR dlls/shell32/shell32.dll.so: RenderPREFEREDDROPEFFECT dlls/shell32/shell32.dll.so: RenderSHELLIDLISTOFFSET dlls/shell32/shell32.dll.so: SHILCreateFromPathA dlls/shell32/shell32.dll.so: TRASH_DisposeElement dlls/shell32/shell32.dll.so: XDG_GetPath dlls/user32/user32.dll.so: EditWndProcW dlls/user32/user32.dll.so: LookupIconIdFromDirectory16 dlls/uxtheme/uxtheme.dll.so: UXINI_ResetINI dlls/w32skrnl/w32skrnl.dll.so: _GetThunkBuff dlls/winealsa.drv/winealsa.drv.so: ALSA_PeekRingMessage dlls/winealsa.drv/winealsa.drv.so: wodSetVolume dlls/winedos/winedos.dll.so: DOSDEV_Console dlls/winedos/winedos.dll.so: DOSDEV_FindCharDevice dlls/winedos/winedos.dll.so: DOSDEV_IoctlRead dlls/winedos/winedos.dll.so: DOSDEV_IoctlWrite dlls/winedos/winedos.dll.so: DOSDEV_Peek dlls/winedos/winedos.dll.so: DOSDEV_Read dlls/winedos/winedos.dll.so: DOSDEV_Write dlls/winedos/winedos.dll.so: DOSVM_AllocCodeUMB dlls/winedos/winedos.dll.so: DOSVM_AllocUMB dlls/winedos/winedos.dll.so: DPMI_FreeInternalRMCB dlls/winedos/winedos.dll.so: VGA_SetQuadPalette dlls/winedos/winedos.dll.so: VGA_SetTextAttribute dlls/wineps.drv/wineps.drv.so: PSDRV_CmpColor dlls/wineps.drv/wineps.drv.so: PSDRV_WriteArrayGet dlls/wineps.drv/wineps.drv.so: PSDRV_WriteInitClip dlls/wineps.drv/wineps.drv.so: PSDRV_WriteRRectangle dlls/winex11.drv/winex11.drv.so: X11DRV_get_client_window dlls/winex11.drv/winex11.drv.so: X11DRV_SetupGCForPen dlls/winex11.drv/winex11.drv.so: X11DRV_window_to_X_rect dlls/winex11.drv/winex11.drv.so: X11DRV_XF86VM_SetExclusiveMode dlls/winex11.drv/winex11.drv.so: X11DRV_XRandR_Cleanup dlls/winhttp/winhttp.dll.so: netconn_set_timeout dlls/wininet/wininet.dll.so: HTTP_FinishedReading dlls/wininet/wininet.dll.so: HTTP_GetHeader dlls/wininet/wininet.dll.so: HTTP_HttpOpenRequestW dlls/wininet/wininet.dll.so: HTTP_HttpSendRequestW dlls/winmm/winmm.dll.so: MCI_DefYieldProc dlls/winmm/winmm.dll.so: MCI_GetDriverFromString dlls/winmm/winmm.dll.so: MCI_SendCommandFrom16 dlls/winmm/winmm.dll.so: MCI_SendCommandFrom32 dlls/winmm/winmm.dll.so: MCI_WriteString dlls/wintrust/wintrust.dll.so: CRYPT_AsnEncodeInt dlls/wintrust/wintrust.dll.so: WINTRUST_ReAlloc dlls/wnaspi32/wnaspi32.dll.so: ASPI_SendASPICommand dlls/wnaspi32/wnaspi32.dll.so: SCSI_GetDeviceName dlls/wuapi/wuapi.dll.so: AutomaticUpdates_create programs/cmd/cmd.exe.so: handleExpansion programs/cmd/cmd.exe.so: WCMD_addCommand programs/cmd/cmd.exe.so: WCMD_ask_confirm programs/cmd/cmd.exe.so: WCMD_dir_sort programs/cmd/cmd.exe.so: WCMD_filesize64 programs/cmd/cmd.exe.so: WCMD_opt_s_strip_quotes programs/cmd/cmd.exe.so: WCMD_parse programs/cmd/cmd.exe.so: WCMD_show_prompt programs/cmd/cmd.exe.so: WCMD_strrev programs/cmd/cmd.exe.so: WCMD_strtrim_trailing_spaces programs/oleview/oleview.exe.so: AddToStrW programs/oleview/oleview.exe.so: AddToTLDataStrW programs/oleview/oleview.exe.so: AddToTLDataStrWithTabsW programs/oleview/oleview.exe.so: CreateInstOnProc programs/oleview/oleview.exe.so: DetailsProc programs/oleview/oleview.exe.so: InterfaceViewerProc programs/oleview/oleview.exe.so: PaneProc programs/oleview/oleview.exe.so: SysConfProc programs/oleview/oleview.exe.so: TreeProc programs/oleview/oleview.exe.so: TypeLibProc programs/oleview/oleview.exe.so: WndProc programs/progman/progman.exe.so: DIALOG_Symbol programs/regedit/regedit.exe.so: GetMultiByteStringN programs/regedit/regedit.exe.so: GetRootKeyName programs/regedit/regedit.exe.so: GetWideStringN programs/regedit/regedit.exe.so: HexEdit_Unregister programs/regedit/regedit.exe.so: processRegLinesA programs/regedit/regedit.exe.so: processRegLinesW programs/taskmgr/taskmgr.exe.so: Draw3dRect programs/taskmgr/taskmgr.exe.so: Draw3dRect2 programs/taskmgr/taskmgr.exe.so: FillSolidRect2 programs/taskmgr/taskmgr.exe.so: GraphCtrl_DrawPoint programs/taskmgr/taskmgr.exe.so: GraphCtrl_InvalidateCtrl programs/taskmgr/taskmgr.exe.so: GraphCtrl_Paint programs/taskmgr/taskmgr.exe.so: GraphCtrl_Resize programs/taskmgr/taskmgr.exe.so: TrayIcon_GetProcessorUsageIcon programs/taskmgr/taskmgr.exe.so: UpdateApplicationListControlViewSetting programs/view/view.exe.so: FileIsPlaceable programs/view/view.exe.so: GetPlaceableMetaFile programs/winecfg/winecfg.exe.so: enumerate_valuesW programs/wineconsole/wineconsole.exe.so: WCUSER_AreFontsEqual programs/wineconsole/wineconsole.exe.so: WINECON_FetchCells programs/wineconsole/wineconsole.exe.so: WINECON_GetHistoryMode programs/wineconsole/wineconsole.exe.so: WINECON_SetHistoryMode programs/wineconsole/wineconsole.exe.so: WINECON_SetHistorySize programs/winedbg/winedbg.exe.so: be_cpu_build_addr programs/winedbg/winedbg.exe.so: be_cpu_linearize programs/winedbg/winedbg.exe.so: dbg_alloc programs/winedbg/winedbg.exe.so: dbg__create_buffer programs/winedbg/winedbg.exe.so: dbg__delete_buffer programs/winedbg/winedbg.exe.so: dbg__flush_buffer programs/winedbg/winedbg.exe.so: dbg_free programs/winedbg/winedbg.exe.so: dbg_get_debug programs/winedbg/winedbg.exe.so: dbg_get_in programs/winedbg/winedbg.exe.so: dbg_get_leng programs/winedbg/winedbg.exe.so: dbg_get_lineno programs/winedbg/winedbg.exe.so: dbg_get_out programs/winedbg/winedbg.exe.so: dbg_get_text programs/winedbg/winedbg.exe.so: dbg_lex_destroy programs/winedbg/winedbg.exe.so: dbg_outputA programs/winedbg/winedbg.exe.so: dbg_parse programs/winedbg/winedbg.exe.so: dbg_pop_buffer_state programs/winedbg/winedbg.exe.so: dbg_push_buffer_state programs/winedbg/winedbg.exe.so: dbg_realloc programs/winedbg/winedbg.exe.so: dbg_restart programs/winedbg/winedbg.exe.so: dbg__scan_buffer programs/winedbg/winedbg.exe.so: dbg__scan_bytes programs/winedbg/winedbg.exe.so: dbg__scan_string programs/winedbg/winedbg.exe.so: dbg_set_debug programs/winedbg/winedbg.exe.so: dbg_set_in programs/winedbg/winedbg.exe.so: dbg_set_lineno programs/winedbg/winedbg.exe.so: dbg_set_out programs/winedbg/winedbg.exe.so: dbg__switch_to_buffer programs/winedbg/winedbg.exe.so: dbg_wrap programs/winedbg/winedbg.exe.so: expr_alloc_uconstant programs/winedbg/winedbg.exe.so: lexeme_alloc programs/winedbg/winedbg.exe.so: parser programs/winedbg/winedbg.exe.so: validate_file programs/winemine/winemine.exe.so: AboutDlgProc programs/winemine/winemine.exe.so: AddFlag programs/winemine/winemine.exe.so: CompleteBox programs/winemine/winemine.exe.so: CompleteBoxes programs/winemine/winemine.exe.so: CreateBoard programs/winemine/winemine.exe.so: DestroyBoard programs/winemine/winemine.exe.so: DrawBoard programs/winemine/winemine.exe.so: DrawFace programs/winemine/winemine.exe.so: DrawLeds programs/winemine/winemine.exe.so: DrawMine programs/winemine/winemine.exe.so: DrawMines programs/winemine/winemine.exe.so: InitBoard programs/winemine/winemine.exe.so: LoadBoard programs/winemine/winemine.exe.so: MainProc programs/winemine/winemine.exe.so: PlaceMines programs/winemine/winemine.exe.so: PressBox programs/winemine/winemine.exe.so: PressBoxes programs/winemine/winemine.exe.so: SaveBoard programs/winemine/winemine.exe.so: SetDifficulty programs/winemine/winemine.exe.so: TestBoard programs/winemine/winemine.exe.so: TestFace programs/winemine/winemine.exe.so: TestMines programs/winemine/winemine.exe.so: UnpressBox programs/winemine/winemine.exe.so: UnpressBoxes programs/winhlp32/winhlp32.exe.so: HLPFILE_BPTreeSearch programs/winhlp32/winhlp32.exe.so: HLPFILE_Contents programs/winhlp32/winhlp32.exe.so: HLPFILE_HalfPointsToTwips programs/winhlp32/winhlp32.exe.so: MACRO_AddAccelerator programs/winhlp32/winhlp32.exe.so: MACRO_ALink programs/winhlp32/winhlp32.exe.so: MACRO_AppendItem programs/winhlp32/winhlp32.exe.so: MACRO_Back programs/winhlp32/winhlp32.exe.so: MACRO_BackFlush programs/winhlp32/winhlp32.exe.so: MACRO_BookmarkMore programs/winhlp32/winhlp32.exe.so: MACRO_BrowseButtons programs/winhlp32/winhlp32.exe.so: MACRO_ChangeButtonBinding programs/winhlp32/winhlp32.exe.so: MACRO_ChangeEnable programs/winhlp32/winhlp32.exe.so: MACRO_ChangeItemBinding programs/winhlp32/winhlp32.exe.so: MACRO_CheckItem programs/winhlp32/winhlp32.exe.so: MACRO_CloseSecondarys programs/winhlp32/winhlp32.exe.so: MACRO_CloseWindow programs/winhlp32/winhlp32.exe.so: MACRO_Compare programs/winhlp32/winhlp32.exe.so: MACRO_Contents programs/winhlp32/winhlp32.exe.so: MACRO_ControlPanel programs/winhlp32/winhlp32.exe.so: MACRO_CopyTopic programs/winhlp32/winhlp32.exe.so: MACRO_DeleteItem programs/winhlp32/winhlp32.exe.so: MACRO_DeleteMark programs/winhlp32/winhlp32.exe.so: MACRO_DestroyButton programs/winhlp32/winhlp32.exe.so: MACRO_DisableItem programs/winhlp32/winhlp32.exe.so: MACRO_EnableButton programs/winhlp32/winhlp32.exe.so: MACRO_EnableItem programs/winhlp32/winhlp32.exe.so: MACRO_EndMPrint programs/winhlp32/winhlp32.exe.so: MACRO_ExecFile programs/winhlp32/winhlp32.exe.so: MACRO_ExecProgram programs/winhlp32/winhlp32.exe.so: MACRO_ExtAbleItem programs/winhlp32/winhlp32.exe.so: MACRO_ExtInsertItem programs/winhlp32/winhlp32.exe.so: MACRO_ExtInsertMenu programs/winhlp32/winhlp32.exe.so: MACRO_FileExist programs/winhlp32/winhlp32.exe.so: MACRO_Find programs/winhlp32/winhlp32.exe.so: MACRO_Finder programs/winhlp32/winhlp32.exe.so: MACRO_FloatingMenu programs/winhlp32/winhlp32.exe.so: MACRO_Flush programs/winhlp32/winhlp32.exe.so: MACRO_FocusWindow programs/winhlp32/winhlp32.exe.so: MACRO_Generate programs/winhlp32/winhlp32.exe.so: MACRO_GotoMark programs/winhlp32/winhlp32.exe.so: MACRO_IfThen programs/winhlp32/winhlp32.exe.so: MACRO_IfThenElse programs/winhlp32/winhlp32.exe.so: MACRO_InitMPrint programs/winhlp32/winhlp32.exe.so: MACRO_InsertItem programs/winhlp32/winhlp32.exe.so: MACRO_InsertMenu programs/winhlp32/winhlp32.exe.so: MACRO_IsBook programs/winhlp32/winhlp32.exe.so: MACRO_IsMark programs/winhlp32/winhlp32.exe.so: MACRO_IsNotMark programs/winhlp32/winhlp32.exe.so: MACRO_JumpHelpOn programs/winhlp32/winhlp32.exe.so: MACRO_JumpID programs/winhlp32/winhlp32.exe.so: MACRO_JumpKeyword programs/winhlp32/winhlp32.exe.so: MACRO_KLink programs/winhlp32/winhlp32.exe.so: MACRO_Menu programs/winhlp32/winhlp32.exe.so: MACRO_MPrintHash programs/winhlp32/winhlp32.exe.so: MACRO_MPrintID programs/winhlp32/winhlp32.exe.so: MACRO_Next programs/winhlp32/winhlp32.exe.so: MACRO_NoShow programs/winhlp32/winhlp32.exe.so: MACRO_PopupHash programs/winhlp32/winhlp32.exe.so: MACRO_PopupId programs/winhlp32/winhlp32.exe.so: MACRO_PositionWindow programs/winhlp32/winhlp32.exe.so: MACRO_Prev programs/winhlp32/winhlp32.exe.so: MACRO_RegisterRoutine programs/winhlp32/winhlp32.exe.so: MACRO_RemoveAccelerator programs/winhlp32/winhlp32.exe.so: MACRO_ResetMenu programs/winhlp32/winhlp32.exe.so: MACRO_SaveMark programs/winhlp32/winhlp32.exe.so: MACRO_Search programs/winhlp32/winhlp32.exe.so: MACRO_SetHelpOnFile programs/winhlp32/winhlp32.exe.so: MACRO_SetPopupColor programs/winhlp32/winhlp32.exe.so: MACRO_ShellExecute programs/winhlp32/winhlp32.exe.so: MACRO_ShortCut programs/winhlp32/winhlp32.exe.so: MACRO_TCard programs/winhlp32/winhlp32.exe.so: MACRO_Test programs/winhlp32/winhlp32.exe.so: MACRO_TestALink programs/winhlp32/winhlp32.exe.so: MACRO_TestKLink programs/winhlp32/winhlp32.exe.so: MACRO_UncheckItem programs/winhlp32/winhlp32.exe.so: MACRO_UpdateWindow programs/winhlp32/winhlp32.exe.so: WINHELP_IndexDlgProc programs/winhlp32/winhlp32.exe.so: WINHELP_MessageBoxIDS_s programs/winhlp32/winhlp32.exe.so: WINHELP_SearchDlgProc programs/winhlp32/winhlp32.exe.so: yyalloc programs/winhlp32/winhlp32.exe.so: yy_create_buffer programs/winhlp32/winhlp32.exe.so: yy_delete_buffer programs/winhlp32/winhlp32.exe.so: yy_flush_buffer programs/winhlp32/winhlp32.exe.so: yyfree programs/winhlp32/winhlp32.exe.so: yyget_debug programs/winhlp32/winhlp32.exe.so: yyget_in programs/winhlp32/winhlp32.exe.so: yyget_leng programs/winhlp32/winhlp32.exe.so: yyget_lineno programs/winhlp32/winhlp32.exe.so: yyget_out programs/winhlp32/winhlp32.exe.so: yyget_text programs/winhlp32/winhlp32.exe.so: yylex programs/winhlp32/winhlp32.exe.so: yylex_destroy programs/winhlp32/winhlp32.exe.so: yypop_buffer_state programs/winhlp32/winhlp32.exe.so: yypush_buffer_state programs/winhlp32/winhlp32.exe.so: yyrealloc programs/winhlp32/winhlp32.exe.so: yyrestart programs/winhlp32/winhlp32.exe.so: yy_scan_buffer programs/winhlp32/winhlp32.exe.so: yy_scan_bytes programs/winhlp32/winhlp32.exe.so: yy_scan_string programs/winhlp32/winhlp32.exe.so: yyset_debug programs/winhlp32/winhlp32.exe.so: yyset_in programs/winhlp32/winhlp32.exe.so: yyset_lineno programs/winhlp32/winhlp32.exe.so: yyset_out programs/winhlp32/winhlp32.exe.so: yy_switch_to_buffer programs/winhlp32/winhlp32.exe.so: yywrap -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Dec. 18, 2008

Re: Another machine passing tests

by Alasdair Sinclair

Michael Stefaniuc wrote: > Hi Alasdair, > > Alasdair Sinclair wrote: > >>> Would you mind sharing what hardware that's on? You're using Fedora 10, right? >>> >>> >>> >> Sure, Its a Dell XPS1530 laptop (core 2 duo T8100), 4GB Ram, GeForce >> 8600M GT. >> Running fedora 10 x86-64 (recently upgraded from 9) all latest patches >> applied, desktop is Gnome. >> > do you have SELinux enabled? I figure no as the default F10 SELinux > "breaks" Wine. Hmm ... you might have inherited the sane boolean setting > from F9 and thus aren't affected. > > Yes SELinux is enabled. I eventually managed to get it configured to allow wine to run. I think with something like the following. $ setsebool -P allow_execmod 1 $ chcon -t execmem_exec_t /home/ams/wine/bin/wine-preloader Which is a bit hackish, but seems to work, and it's possible there's settings I've forgotten about when I installed F9. >> bye >> michael >> Alasdair

Dec. 18, 2008

Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.

by Aric Stewart

Since I value your input in imm32 and i do a lot of work there. If you would like to send me that high level overview then I can see if it works into wine. That way you can continue to contribute and we do not compromise the source code. I have not looked at these patches yet so just send me an e-mail describing what they do. -aric James Hawkins wrote: > On Wed, Dec 17, 2008 at 2:51 PM, ByeongSik Jeon <bsjeon(a)hanmail.net> wrote: >> By an analysis of the ImmIsUIMessageA/W disassemble code, >> 1. checked msg : >> WM_IME_STARTCOMPOSITION <= msg <= WM_IME_KEYLAST, >> WM_IME_SETCONTEXT, WM_IME_NOTIFY, >> WM_IME_COMPOSITIONFULL, WM_IME_SELECT. >> 2. SendMessageA/W is used. >> > > Writing code for Wine based directly off of disassembled code is not > allowed. The only way disassembly can be used is clean-room reverse > engineering where person A disassembles the code and writes up a very > high-level spec file for person B to implement. Unfortunately, this > patch cannot be committed and you won't be able to submit patches for > the imm32 module anymore. >

Dec. 17, 2008

Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.

by James Hawkins

On Wed, Dec 17, 2008 at 2:51 PM, ByeongSik Jeon <bsjeon(a)hanmail.net> wrote: > By an analysis of the ImmIsUIMessageA/W disassemble code, > 1. checked msg : > WM_IME_STARTCOMPOSITION <= msg <= WM_IME_KEYLAST, > WM_IME_SETCONTEXT, WM_IME_NOTIFY, > WM_IME_COMPOSITIONFULL, WM_IME_SELECT. > 2. SendMessageA/W is used. > Writing code for Wine based directly off of disassembled code is not allowed. The only way disassembly can be used is clean-room reverse engineering where person A disassembles the code and writes up a very high-level spec file for person B to implement. Unfortunately, this patch cannot be committed and you won't be able to submit patches for the imm32 module anymore. -- James Hawkins

Dec. 17, 2008

Re: Wine t-shirts?

by Ismael Barros²

On Wed, Dec 17, 2008 at 4:49 PM, Andrew Fenn <andrewfenn(a)gmail.com> wrote: > Thinking about me walking down the street again I have to say I prefer > Remco's suggestion the best because it describes best what wine does. > I like the idea of a witty shirt however the lines suggested requires > that you already understand what wine and open source is about to get > the joke. Well, I personally tend to prefer T-shirts that not everybody understands, but that cause some good laughs on the chosen ones that do :P We'll select one kind of T-shirt depending on the poll, but if the store works find we should be able to offer alternative kinds of design soon. > Perhaps it would be best to have a combination of a funny picture, the > project name, Remco's suggestion for the text and possibly the wine > logo? Just my opinion, perhaps if you're doing voting you could make > up some witty and non-witty shirts and see which people like the most. I updated the poll ( http://spreadsheets.google.com/viewform?key=pFqhThgtfGxo3OxU8pe8ZDg ) with slogan options. I hope it still works for the ones who had already voted (which should answer only the last question, not all three)

Dec. 17, 2008

WineD3D: add some new GL extensions

by Roderick Colenbrander

Hi, Add some new GL extensions which are needed for better d3d9 floating point support for R32F/RG32F and friends. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Reece Dunn

2008/12/17 Austin English <austinenglish(a)gmail.com>: > On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze <s.devrieze(a)linux.be> wrote: >> 2008/12/17 Scott Ritchie <scott(a)open-vote.org>: >> <snip> >>> If it's that users blame the distro when it's a Wine problem, then we >>> can present them with some sort of information before installing (or >>> perhaps running) Wine. After that we should get out of the way and let >>> them use Wine as normal. >> >> Wine should go out of way when the Windows application is known to run >> very well under Wine or when the user submitted feedback for this >> application in the past. Also, the user easily can skip the dialog. >> >>> If the problem is that we're not getting enough feedback, then a default >>> feedback nag might not be the best answer either. >> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. > > It would take developer time and effort to analyze all these logs, and > that time is better spent actually implementing those features and > fixing bugs. Any logs like this would only be useful if they were automatically processed. For example, a list of top crashers could be produced, or something like the Kernel Oops report statistics. > In a few years when Wine is more developed and has most the API > implemented, this may be useful, but there's still a lot to do, and we > don't need more reports to tell us this. The use in statistics here would be to know what crashes are most frequent (via automated tools). If these could be given an id (e.g. a sha1 hash) they could be associated with a bug report to show which crashes (that have a bug report) are more active. This could help with retesting a bug and testing if a bug is still active in the latest version of wine. Taking a step back... there was a patch a few days ago to add a winewatson application similar to the drwatson program in Windows. This is a better way to go (at least initially) as it serves several purposes: 1. it shows people running wine applications directly instead of going via a command shell that something went wrong; 2. it allows wine to gather information such as terminal output and stack trace that the user can copy and paste in a bug report; 3. it allows the user to be pointed at the wine bugzilla page to report a bug if one does not already exist (including the terminal outbut and stack trace captured by winewatson), or confirm that the bug is still valid. I think that this is all that is necessary and should satisfy the needs outlined here without being a burden to developers and fitting into the current way that bugs are triaged and processed. It should also help the more novice users create better bug reports. - Reece

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Sander Devrieze

2008/12/17 Austin English <austinenglish(a)gmail.com>: <snip> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. >> >> I guess this kind of feedback can be very powerful to Wine coders to >> create statistics like these: >> * Most popular API calls >> * Least popular API calls >> * Most common API calls that make applications fail >> * Unimplemented features used by very uncommon software (e.g. >> custom-built applications within companies) >> * Predicting the likelihood that a specific API call will be used when >> another API call is used in an application >> >> Maybe this information can be useful to detect which applications are >> affected by a bug in Wine. When this is known, testers can verify in >> multiple applications if the bug really is fixed in all applications. > > It would take developer time and effort to analyze all these logs, and > that time is better spent actually implementing those features and > fixing bugs. Everything takes time and time also can be invested to save time in the long run. > In a few years when Wine is more developed and has most the API > implemented, this may be useful, It's better to already start gathering this information even if you don't want to look at it as it is like website statistics: it becomes more valuable when you have more data. > but there's still a lot to do, and we > don't need more reports to tell us this. A database is no report. It is something you can consult at any time, for example when you want to see if the bug that just has been reported also can be tested in other applications. I guess this can become very interesting when the bug reported found problem in a very expensive proprietary application and the database indicates the same bug may also cause a similar problem in another freely available application. This would make it easier for a developer without the very expensive application of the bug reporter to fix the bug. -- Mvg, Sander Devrieze.

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Austin English

On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze <s.devrieze(a)linux.be> wrote: > 2008/12/17 Scott Ritchie <scott(a)open-vote.org>: > <snip> >> If it's that users blame the distro when it's a Wine problem, then we >> can present them with some sort of information before installing (or >> perhaps running) Wine. After that we should get out of the way and let >> them use Wine as normal. > > Wine should go out of way when the Windows application is known to run > very well under Wine or when the user submitted feedback for this > application in the past. Also, the user easily can skip the dialog. > >> If the problem is that we're not getting enough feedback, then a default >> feedback nag might not be the best answer either. > >> Writing an elaborate >> system to tell us about known problems isn't particularly helpful; > > It shouldn't be an elaborate system: it can be as easy as asking the > user to click on a button to send a list of API calls, used DLLs, a > hash of the .exe binary, some critical information of his system, > amongst others to the Wine project. User based input in the feedback > form may or may not be a good thing; I just gave this as an example; > it is no necessary element in what I am proposing. > > I guess this kind of feedback can be very powerful to Wine coders to > create statistics like these: > * Most popular API calls > * Least popular API calls > * Most common API calls that make applications fail > * Unimplemented features used by very uncommon software (e.g. > custom-built applications within companies) > * Predicting the likelihood that a specific API call will be used when > another API call is used in an application > > Maybe this information can be useful to detect which applications are > affected by a bug in Wine. When this is known, testers can verify in > multiple applications if the bug really is fixed in all applications. It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs. In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this. -- -Austin

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Sander Devrieze

2008/12/17 Scott Ritchie <scott(a)open-vote.org>: <snip> > If it's that users blame the distro when it's a Wine problem, then we > can present them with some sort of information before installing (or > perhaps running) Wine. After that we should get out of the way and let > them use Wine as normal. Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog. > If the problem is that we're not getting enough feedback, then a default > feedback nag might not be the best answer either. > Writing an elaborate > system to tell us about known problems isn't particularly helpful; It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing. I guess this kind of feedback can be very powerful to Wine coders to create statistics like these: * Most popular API calls * Least popular API calls * Most common API calls that make applications fail * Unimplemented features used by very uncommon software (e.g. custom-built applications within companies) * Predicting the likelihood that a specific API call will be used when another API call is used in an application Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications. > reports from stable or nonlatest versions would be largely ignored, and > users of the latest beta can be asked to contribute in other ways, such > as on the download page itself. > > Remember, it doesn't take much work for us to know that an application > doesn't work - a single bug report can do that. Once we have that, we > don't need to ask a million other users (literally) for confirmation. Only geeks file good bug reports. Normal people don't care and will not spend energy on this. -- Mvg, Sander Devrieze.

Dec. 17, 2008

Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb

by Aneurin Price

On Wed, Dec 17, 2008 at 2:48 PM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Wed, 17 Dec 2008 14:13:31 +0100 > Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > >> On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: >> > Since the change to the new design, AppDB entries have been displaying >> > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) >> > in place of a variety of special characters, including anything with an >> > umlaut (bug 16514). I've played around with it a bit, and the entries can >> > be fixed by manually editing them, but before I undertake the task, I >> > figured I'd better ask if this is something that could be fixed more easily >> > (e.g., changing a setting on the server). >> >> Could you provide a link to a page where this problem is shown? >> > > http://appdb.winehq.org/objectManager.php?sClass=application&iId=5651 > http://appdb.winehq.org/objectManager.php?sClass=application&iId=6764 > > It would appear that the new template says: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, but those pages actually contain text encoded in ISO-8859-1. Possibly some kind of bulk conversion would be in order? -Nye

Dec. 17, 2008

Re: winewtsn: add a new program that shows a dialog to inform about a crash

by Alexandre Julliard

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > Currently, when a program is started from the KDE or Gnome menu and > it crashes, it simply disappears from the screen without any > explanation what happened - the information that goes to the console > is not visible. This program uses a similar technique as Windows' dr > Watson to register itself as a debugger and show a dialog about a > crash. It then calls winedbg, so, if the program is run from a > terminal, the dump will be still visible. As a bonus feature, one can > Shift+right click on the dialog to start an interactive session of > winedbg. The patch has an effect only on new wineprefixes, as the > debugger setting is not overwritten after a Wine upgrade. I'd suggest to do that in winedbg, there's no need to add another Wine-specific program for that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 17, 2008

Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl

by Maarten Lankhorst

Hi Dmitry, Dmitry Timoshkov schreef: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > >> Needed to get +relay working in wine64 > > You should have used CDECL instead of __cdecl, have a look how it's > done in msvcrt.dll. In msvcrt both were used, so that doesn't really help. I guess that confused me a little. sed to the rescue!! ;) Cheers, Maarten.

Dec. 17, 2008

Re: Wine t-shirts?

by Andrew Fenn

On Wed, Dec 17, 2008 at 3:17 PM, Ismael Barros² <razielmine(a)gmail.com> wrote: >> "Windows translation layer" >> "Run Windows applications on Linux, BSD and Mac OS X." > > It doesn't really sound very T-shirt-y to me. I think I'd rather wear > a T-shirt with a short, witty slogan than being a walking banner :) > > Something like "Releasing your computer of Windows since 1993" or > "Closing your Windows since 1993" or "Putting the Win in Windows(TM) > since 1993" (okay that last one was more stupid than it should be) > would do the work, enough to avoid alcoholic confussions yet not that > boring. If someone is that interested in what are the windows you're > so interested in closing, they may ask. > Thinking about me walking down the street again I have to say I prefer Remco's suggestion the best because it describes best what wine does. I like the idea of a witty shirt however the lines suggested requires that you already understand what wine and open source is about to get the joke. Perhaps it would be best to have a combination of a funny picture, the project name, Remco's suggestion for the text and possibly the wine logo? Just my opinion, perhaps if you're doing voting you could make up some witty and non-witty shirts and see which people like the most. Regards, Andrew

Dec. 17, 2008

Re: Wine t-shirts?

by Ismael Barros²

> "Windows translation layer" > "Run Windows applications on Linux, BSD and Mac OS X." It doesn't really sound very T-shirt-y to me. I think I'd rather wear a T-shirt with a short, witty slogan than being a walking banner :) Something like "Releasing your computer of Windows since 1993" or "Closing your Windows since 1993" or "Putting the Win in Windows(TM) since 1993" (okay that last one was more stupid than it should be) would do the work, enough to avoid alcoholic confussions yet not that boring. If someone is that interested in what are the windows you're so interested in closing, they may ask.

Dec. 17, 2008

Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -33,9 +33,9 @@ > WINE_DEFAULT_DEBUG_CHANNEL(bitmap); > > > -static HGDIOBJ BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > -static INT BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > -static BOOL BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); > +static HGDIOBJ __cdecl BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > +static INT __cdecl BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > +static BOOL __cdecl BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); You shouldn't need to change these. -- Alexandre Julliard julliard(a)winehq.org

Dec. 17, 2008

Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb

by Rosanne DiMesio

On Wed, 17 Dec 2008 14:13:31 +0100 Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: > > Since the change to the new design, AppDB entries have been displaying > > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) > > in place of a variety of special characters, including anything with an > > umlaut (bug 16514). I've played around with it a bit, and the entries can > > be fixed by manually editing them, but before I undertake the task, I > > figured I'd better ask if this is something that could be fixed more easily > > (e.g., changing a setting on the server). > > Could you provide a link to a page where this problem is shown? > http://appdb.winehq.org/objectManager.php?sClass=application&iId=5651 http://appdb.winehq.org/objectManager.php?sClass=application&iId=6764 -- Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 17, 2008

Re: Wine t-shirts?

by Remco

On Wed, Dec 17, 2008 at 12:41 PM, Andrew Fenn <andrewfenn(a)gmail.com> wrote: > > Perhaps some smaller text underneath where it says wine, "The windows > translation layer" or something similar to this? Just to define what I > might be for someone who has no idea. > Probably better to use the WineHQ tag line. A normal person would think that "Windows translation layer" had something to do with internationalization. The WineHQ tag line explains it better: "Run Windows applications on Linux, BSD and Mac OS X." Remco

Dec. 17, 2008

Making the shell32/appbar tests pass on Vista

by Paul Vriens

Hi Vincent, I was trying to have the appbar tests succeed on Vista. One way I could make it work is with the attached patch. Does this make sense? Or should we have another possible outcome of the test? (or even a broken()?). The change to do_events_until was only for my troubleshooting purposes. (Vista times out without the patch). -- Cheers, Paul. diff --git a/dlls/shell32/tests/appbar.c b/dlls/shell32/tests/appbar.c index d11a999..8dff9a8 100644 --- a/dlls/shell32/tests/appbar.c +++ b/dlls/shell32/tests/appbar.c @@ -128,8 +128,13 @@ static void do_events_until(boolean_function test) TranslateMessage(&msg); DispatchMessageA(&msg); } - if (timedout || test()) + if (test()) break; + else if (timedout) + { + trace("Timed out waiting for condition to become true\n"); + break; + } WaitMessage(); } @@ -333,6 +338,8 @@ static void test_setpos(void) windows[0].registered = FALSE; DestroyWindow(windows[0].hwnd); + testwindow_setpos(windows[1].hwnd); + do_events_until(got_expected_bottom); ok(windows[1].allocated_rect.bottom == expected_bottom, "windows[1]'s bottom is %i, expected %i\n", windows[1].allocated_rect.bottom, expected_bottom);

Dec. 17, 2008

Re: server: implement move/rename change notifications and support for multiple change notification in one reply

by Dan Kegel

On Wed, Dec 17, 2008 at 1:21 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > The attachment is here: > http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html > The archive seems to create separate mails for attached mails. D'oh! Geez, we've got to fix that... - Dan

Dec. 17, 2008

Re: Another machine passing tests

by Michael Stefaniuc

Hi Alasdair, Alasdair Sinclair wrote: >> Would you mind sharing what hardware that's on? You're using Fedora 10, right? >> >> > Sure, Its a Dell XPS1530 laptop (core 2 duo T8100), 4GB Ram, GeForce > 8600M GT. > Running fedora 10 x86-64 (recently upgraded from 9) all latest patches > applied, desktop is Gnome. do you have SELinux enabled? I figure no as the default F10 SELinux "breaks" Wine. Hmm ... you might have inherited the sane boolean setting from F9 and thus aren't affected. > It's also running the proprietary Nvidia drivers packaged by rpmfusion. bye michael

Dec. 17, 2008

Re: wined3d: Implement check for shader creation if hardware supports requested version.

by Henri Verbeet

2008/12/17 Paul Vriens <paul.vriens.wine(a)gmail.com>: > So that leaves the C++ comments? > No, the code you quoted was in d3d9/tests/shader.c, so I think your comment was right, even though it's a pretty minor issue.

Dec. 17, 2008

Re: wined3d: Implement check for shader creation if hardware supports requested version.

by Paul Vriens

Henri Verbeet wrote: > 2008/12/17 Stefan Dösinger <stefan(a)codeweavers.com>: >>> if () >>> { >>> } >>> else >>> { >>> } >>> >>> block to stick with the style. >> Actually most of WineD3D's code uses the style the patch uses, but its not >> 100% consistent :-/ >> > Most of the tests don't. So that leaves the C++ comments? -- Cheers, Paul.

Dec. 17, 2008

Re: wined3d: Implement check for shader creation if hardware supports requested version.

by Henri Verbeet

2008/12/17 Stefan Dösinger <stefan(a)codeweavers.com>: >> if () >> { >> } >> else >> { >> } >> >> block to stick with the style. > Actually most of WineD3D's code uses the style the patch uses, but its not > 100% consistent :-/ > Most of the tests don't.

Dec. 17, 2008

Re: fixing all the not-properly-displaying characters that have suddenly appeared in the appdb

by Alexander Nicolaysen Sørnes

On Tuesday 16 December 2008 20:52:04 Rosanne DiMesio wrote: > Since the change to the new design, AppDB entries have been displaying > either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) > in place of a variety of special characters, including anything with an > umlaut (bug 16514). I've played around with it a bit, and the entries can > be fixed by manually editing them, but before I undertake the task, I > figured I'd better ask if this is something that could be fixed more easily > (e.g., changing a setting on the server). Could you provide a link to a page where this problem is shown? Alexander N. Sørnes

Dec. 17, 2008

RE: wined3d: Implement check for shader creation if hardware supports requested version.

by Stefan Dösinger

> if () > { > } > else > { > } > > block to stick with the style. Actually most of WineD3D's code uses the style the patch uses, but its not 100% consistent :-/

Dec. 17, 2008

Re: wined3d: Reduce and improve error message spam when shader creation fails.

by Henri Verbeet

These should probably all be WARNs as well.

Dec. 17, 2008

Re: wined3d: Implement check for shader creation if hardware supports requested version.

by Henri Verbeet

2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ Please don't do that, use the reg_maps.shader_version instead. > + ERR("First instruction in shader isn't correct shader version for pixel shader. (0x%x)\n", shader_version); ERR is for internal errors, this should be a WARN. You probably don't need to print anything at all here though, doing it from the caller makes more sense (and you've got a message there already anyway). > + ERR("No hardware support for pixel shader version (0x%x).\n",*pFunction); Like above, this should be a WARN. That also means you can get rid of the code to only print the message once.

Dec. 17, 2008

Re: d3d9/tests: Add missing new lines to ok() and split long lines

by Paul Vriens

Pauli Nieminen wrote: > --- > dlls/d3d9/tests/shader.c | 16 ++++++++++++---- > 1 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3d9/tests/shader.c b/dlls/d3d9/tests/shader.c > index 55b414a..caae395 100644 > --- a/dlls/d3d9/tests/shader.c > +++ b/dlls/d3d9/tests/shader.c > @@ -85,10 +85,14 @@ static inline void test_create_vshader_version_check(IDirect3DDevice9 *device_pt > > if( version <= caps->VertexShaderVersion ) > { > - ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + ok(hret == D3D_OK && vshader_ptr != NULL, > + "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p\n", > + version, hret, vshader_ptr); > IDirect3DVertexShader9_Release(vshader_ptr); > } else { > - ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL, > + "Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p\n", > + version, hret, vshader_ptr); > } > > } > @@ -104,10 +108,14 @@ static inline void test_create_pshader_version_check(IDirect3DDevice9 *device_pt > > if( version <= caps->PixelShaderVersion ) > { > - ok(hret == D3D_OK && pshader_ptr != NULL, "Pixel shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, pshader_ptr = %p", version, hret, pshader_ptr); > + ok(hret == D3D_OK && pshader_ptr != NULL, > + "Pixel shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, pshader_ptr = %p\n", > + version, hret, pshader_ptr); > IDirect3DPixelShader9_Release(pshader_ptr); > } else { > - ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL,"Pixel shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, pshader_ptr = %p", version, hret, pshader_ptr); > + ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL, > + "Pixel shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, pshader_ptr = %p\n", > + version, hret, pshader_ptr); > } > > } Hi, These fixes are on top of your previous patch which is not committed). If it's a series of patches you should mark them appropriate ([1/2] and [2/2] for example). In this case it's probably better to incorporate this into the previous patch and resend that one. -- Cheers, Paul.

Dec. 17, 2008

Re: wined3d: Implement check for shader creation if hardware supports requested version.

by Paul Vriens

Pauli Nieminen wrote: > + > + if( version <= caps->VertexShaderVersion ) > + { > + ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + IDirect3DVertexShader9_Release(vshader_ptr); > + } else { > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } Hi, Just some style issues I've seen. You should be using a: if () { } else { } block to stick with the style. > > +/** > + * checks if shader version supported that is required by new > + * shader. > + */ > +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ > + const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info; > + > + deviceImpl->shader_backend->shader_get_caps(deviceImpl->devType ,gl_info, &shader_caps); > + // Check which shader this is Please use C-style comments, not C++. > + if(shader_is_pshader_version(shader_version)) > + { > + // Check if high enough shader version is supported And there are a few others of those. -- Cheers, Paul.

Dec. 17, 2008

Re: Wine t-shirts?

by Andrew Fenn

On Wed, Dec 17, 2008 at 12:14 AM, Ismael Barros² <razielmine(a)gmail.com> wrote: > > Well, what do you expect from a program called wine? :P > All the wine logos I know are wine-related. Maybe we can use them but > with some kind of C source code background, but even then most people > would think you are some kind of alcoholic geek. > Perhaps some smaller text underneath where it says wine, "The windows translation layer" or something similar to this? Just to define what I might be for someone who has no idea.

Dec. 17, 2008

Re: [try2] ntoskrnl.exe: Implement Io{Allocate, Get}DriverObjectExtension.

by Michael Stefaniuc

Alexander Morozov wrote: > Please, use this patch instead of previous "ntoskrnl.exe: Implement > Io{Allocate,Get}DriverObjectExtension." Shouldn't this have gone to wine-patches instead of wine-devel? bye michael

Dec. 17, 2008

[try2] ntoskrnl.exe: Implement Io{Allocate, Get}DriverObjectExtension.

by Alexander Morozov

Please, use this patch instead of previous "ntoskrnl.exe: Implement Io{Allocate,Get}DriverObjectExtension." >From b5441d22fe51640849436b563ca3ab6c9a80c1a5 Mon Sep 17 00:00:00 2001 From: Alexander Morozov <amorozov(a)etersoft.ru> Date: Wed, 17 Dec 2008 12:44:46 +0300 Subject: [PATCH] ntoskrnl.exe: Implement Io{Allocate,Get}DriverObjectExtension. --- dlls/ntoskrnl.exe/ntoskrnl.c | 53 +++++++++++++++++++++++++++++++++++++++-- 1 files changed, 50 insertions(+), 3 deletions(-) diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c index a669d3b..73054e3 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.c +++ b/dlls/ntoskrnl.exe/ntoskrnl.c @@ -63,6 +63,16 @@ struct IrpInstance IRP *irp; }; +static struct list DriverObjExtensions = LIST_INIT(DriverObjExtensions); + +struct DriverObjExtension +{ + struct list entry; + void *ptr; + DRIVER_OBJECT *driver; + void *id_addr; +}; + #ifdef __i386__ #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ __ASM_GLOBAL_FUNC( name, \ @@ -267,9 +277,28 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension( PDRIVER_OBJECT DriverObject, ULONG DriverObjectExtensionSize, PVOID *DriverObjectExtension ) { - FIXME( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress, + struct DriverObjExtension *ext; + + TRACE( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress, DriverObjectExtensionSize, DriverObjectExtension ); - return STATUS_NOT_IMPLEMENTED; + + *DriverObjectExtension = NULL; + if (IoGetDriverObjectExtension( DriverObject, ClientIdentificationAddress )) + return STATUS_OBJECT_NAME_COLLISION; + ext = ExAllocatePool( NonPagedPool, sizeof(*ext) ); + if (ext == NULL) + return STATUS_INSUFFICIENT_RESOURCES; + ext->ptr = ExAllocatePool( NonPagedPool, DriverObjectExtensionSize ); + if (ext->ptr == NULL) + { + ExFreePool( ext ); + return STATUS_INSUFFICIENT_RESOURCES; + } + ext->driver = DriverObject; + ext->id_addr = ClientIdentificationAddress; + list_add_tail( &DriverObjExtensions, &ext->entry ); + *DriverObjectExtension = ext->ptr; + return STATUS_SUCCESS; } @@ -279,7 +308,16 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension( PDRIVER_OBJECT DriverObject, PVOID WINAPI IoGetDriverObjectExtension( PDRIVER_OBJECT DriverObject, PVOID ClientIdentificationAddress ) { - FIXME( "%p, %p\n", DriverObject, ClientIdentificationAddress ); + struct DriverObjExtension *ext; + + TRACE( "%p, %p\n", DriverObject, ClientIdentificationAddress ); + + LIST_FOR_EACH_ENTRY( ext, &DriverObjExtensions, struct DriverObjExtension, entry ) + { + if (DriverObject == ext->driver && + ClientIdentificationAddress == ext->id_addr) + return ext->ptr; + } return NULL; } @@ -1138,6 +1176,7 @@ PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING SystemRoutineName) BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) { LARGE_INTEGER count; + struct DriverObjExtension *ext, *ext2; switch(reason) { @@ -1146,6 +1185,14 @@ BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) RtlAddVectoredExceptionHandler( TRUE, vectored_handler ); KeQueryTickCount( &count ); /* initialize the global KeTickCount */ break; + case DLL_PROCESS_DETACH: + LIST_FOR_EACH_ENTRY_SAFE( ext, ext2, &DriverObjExtensions, + struct DriverObjExtension, entry ) + { + list_remove( &ext->entry ); + ExFreePool( ext->ptr ); + ExFreePool( ext ); + } } return TRUE; } -- 1.6.0.2.GIT

Dec. 17, 2008

Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.

by Henri Verbeet

2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> If creation succeeds, you need to Release the shader again. Same goes >> for the pixel shader version of this function. > > I tried to search for example of releasing shaders from the test file but > when I couldn't find any. Should others test in that file also include > shader release? > They should, although you're right that they don't. It's not as much of an issue in these test since we don't do any fullscreen tests here, but if the device still has references to it at the end of the test it won't be released properly and won't restore the display mode.

Dec. 17, 2008

Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.

by Pauli Nieminen

On Wed, Dec 17, 2008 at 10:51 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > > +static inline void test_create_vshader_version_check(IDirect3DDevice9 > *device_ptr, const D3DCAPS9 *caps, > > + const DWORD version, const DWORD *shader_code) > > +{ > > + IDirect3DVertexShader9 *vshader_ptr = 0; > > + HRESULT hret = 0; > > + > > + hret = IDirect3DDevice9_CreateVertexShader(device_ptr, shader_code, > &vshader_ptr); > > + > > + > > + if( version <= caps->VertexShaderVersion ) > > + { > > + ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) > creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = > %p", version, hret, vshader_ptr); > > + } else { > > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex > shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = > 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > > + } > > + > > +} > If creation succeeds, you need to Release the shader again. Same goes > for the pixel shader version of this function. > I tried to search for example of releasing shaders from the test file but when I couldn't find any. Should others test in that file also include shader release? Thanks for comments.

Dec. 17, 2008

Re: server: implement move/rename change notifications and support for multiple change notification in one reply

by Henri Verbeet

2008/12/17 Dan Kegel <dank(a)kegel.com>: > On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos > <pujos.michael(a)laposte.net> wrote: >>> I don't see an attachment to >>> http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html >>> or rather, there's only a zero-length one. >> >> I just attached (In thunderbird) the file outputted by "git format-patch >> --keep-subject origin" >> Curiously the link above point to a zero length file but I received it >> correctly in my e-mail client from the mailing-list... > > That archive is a bit finicky. > I see the attachment in another archive: > http://marc.info/?l=wine-patches&m=122947592925831&w=2 > Suggestion: next time use a shorter filename, maybe that's > what screwed up the archive. > The attachment is here: http://www.winehq.org/pipermail/wine-patches/2008-December/066225.html The archive seems to create separate mails for attached mails.

Dec. 17, 2008

Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.

by Henri Verbeet

2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > +static inline void test_create_vshader_version_check(IDirect3DDevice9 *device_ptr, const D3DCAPS9 *caps, > + const DWORD version, const DWORD *shader_code) > +{ > + IDirect3DVertexShader9 *vshader_ptr = 0; > + HRESULT hret = 0; > + > + hret = IDirect3DDevice9_CreateVertexShader(device_ptr, shader_code, &vshader_ptr); > + > + > + if( version <= caps->VertexShaderVersion ) > + { > + ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } else { > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } > + > +} If creation succeeds, you need to Release the shader again. Same goes for the pixel shader version of this function. > - ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr == shader_ptr, > + ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr == shader_ptr, > I don't particularly like the trailing space either, but you shouldn't make unrelated whitespace changes in your patch. > +static inline BOOL is_shader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > +// IWineD3DPixelShaderImpl *This = (IWineD3DPixelShaderImpl *)shader; > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ > + const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info; Please don't use tabs or C++ style comments. > /* Note that this does not count the loop register > * as an address register. */ > @@ -216,7 +244,27 @@ HRESULT shader_get_registers_used(IWineD3DBaseShader *iface, struct shader_reg_m > memset(reg_maps->bumpmat, 0, sizeof(reg_maps->bumpmat)); > memset(reg_maps->luminanceparams, 0, sizeof(reg_maps->luminanceparams)); > > - /* get_registers_used is called on every compile on some 1.x shaders, which can result > + /* If no hardware support this function should fail */ > + if (!is_shader_version_supported((IWineD3DDeviceImpl*)This->baseShader.device, pToken)) > + { > + static BOOL warned = FALSE; > + if (!warned) > + { > + warned = TRUE; > + ERR("No hardware support for shader version.\n"); > + } > + return WINED3DERR_INVALIDCALL; > + } > + > + > + if (!pToken) > + { > + WARN("Got a NULL pFunction, returning.\n"); > + This->baseShader.functionLength = 0; > + return WINED3D_OK; > + } > + > + /* get_registers_used is called on every compile on some 1.x shaders, which can result > I don't think shader_get_registers_used is the right place for this. The version check should be in IWineD3DVertexShaderImpl_SetFunction() and IWineD3DPixelShaderImpl_SetFunction(), after the call to shader_get_registers_used(). Putting it there means you can use the shader version in reg_maps.shader_version, and you can also check if the shader is actually a vertexshader or pixelshader. Ie, passing a pixel shader to CreateVertexShader() should most likely fail.

Dec. 17, 2008

Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl

by Dmitry Timoshkov

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Needed to get +relay working in wine64 You should have used CDECL instead of __cdecl, have a look how it's done in msvcrt.dll. -- Dmitry.

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Scott Ritchie

Sander Devrieze wrote: > Hi, > > One of the reasons why Linux distributions do not want to include Wine > by default is because compatibility issues may result a bad impression > of the quality of the OS. Users think Linux sucks because their > Windows application does not run (as good) under Wine as it does under > Windows. > > Problem: Windows applications ran by Wine do not always run without > issues and the user does not know why. Hence, (s)he will think this is > because Linux is less stable than Windows. > > What do Wine coders think about solving the issue by adding a user > feedback interface to Wine? It may for instance work like this: > > * By default open a user feedback dialog after the application is > closed (or crashes). In this dialog, the user will be explained why > this dialog is shown, and why he might have experienced bugs or > crashes in the Windows application. The user also can provide text > feedback and other types of feedback (e.g. a checkbox saying "The > application crashed"). > * The user has the option to send this information to the Wine project > by hitting a button. Gathered information will be integrated in the > Wine application database and can be helpful for Wine coders and > users. > > Advantages: > * Users will better understand why their application did not run as > well on Linux as on Windows. > * Wine will become more interesting to be actively supported by Linux > distributors. > * Users will feel they easily can contribute to the Wine project. > * The Wine project will receive more feedback. > > > Other subidea: > Create a database with hashes of .exe files. Wine can consult this > database *before* it executes a Windows binary and provide the user > with feedback like this: "Remark that 60% of users were not satisfied > when running this application in this Wine version. Do you want to > proceed?" Or like this: "This application has these issues: ... Do you > want to proceed?" > Let's be careful about what problem we're trying to solve. If it's that users blame the distro when it's a Wine problem, then we can present them with some sort of information before installing (or perhaps running) Wine. After that we should get out of the way and let them use Wine as normal. If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either. Writing an elaborate system to tell us about known problems isn't particularly helpful; reports from stable or nonlatest versions would be largely ignored, and users of the latest beta can be asked to contribute in other ways, such as on the download page itself. Remember, it doesn't take much work for us to know that an application doesn't work - a single bug report can do that. Once we have that, we don't need to ask a million other users (literally) for confirmation. Thanks, Scott Ritchie

Dec. 17, 2008

Re: Better user feedback and better user experience (idea)

by Zachary Goldberg

2008/12/16 Sander Devrieze <s.devrieze(a)linux.be>: > Hi, > > One of the reasons why Linux distributions do not want to include Wine > by default is because compatibility issues may result a bad impression > of the quality of the OS. Users think Linux sucks because their > Windows application does not run (as good) under Wine as it does under > Windows. > > Problem: Windows applications ran by Wine do not always run without > issues and the user does not know why. Hence, (s)he will think this is > because Linux is less stable than Windows. > > What do Wine coders think about solving the issue by adding a user > feedback interface to Wine? It may for instance work like this: > > * By default open a user feedback dialog after the application is > closed (or crashes). In this dialog, the user will be explained why > this dialog is shown, and why he might have experienced bugs or > crashes in the Windows application. The user also can provide text > feedback and other types of feedback (e.g. a checkbox saying "The > application crashed"). > * The user has the option to send this information to the Wine project > by hitting a button. Gathered information will be integrated in the > Wine application database and can be helpful for Wine coders and > users. > > Advantages: > * Users will better understand why their application did not run as > well on Linux as on Windows. > * Wine will become more interesting to be actively supported by Linux > distributors. > * Users will feel they easily can contribute to the Wine project. > * The Wine project will receive more feedback. > > > Other subidea: > Create a database with hashes of .exe files. Wine can consult this > database *before* it executes a Windows binary and provide the user > with feedback like this: "Remark that 60% of users were not satisfied > when running this application in this Wine version. Do you want to > proceed?" Or like this: "This application has these issues: ... Do you > want to proceed?" > > -- > Kind Regards, > Sander Devrieze. > > > Sander, This conversation has been had many times before. Some of the issues mentioned previously for why this hasn't been done are as follows: 1) User generated crash reports are not always high enough quality to be usable 2) Users capable of putting in the effort to help fix issues generally already use the AppDB and are indeed helpful. 3) No development area has claimed a need to simply have a ton of crash dumps or user information in order to help make progress. The problem is that Wine is developed by first understanding the problem of a specific function via blackboxing windows with a test and then making wine conform to that blackbox behavior. Often which function to chose is either motivated by a specific application malfunction that a developer is already working on or just to in general improve a specific library. In other words most devs have lots of itches to scratch already and are working on those. Simply throwing more input of the form 'this doesn't work' sadly doesn't help this form of project most of the time. To allow users to "Send Error Report" (in the microsoft sense) would be a sham I think. Regression tests are very helpful to fix specific problems users face however most users are not willing to provide that due to skill/time/lazyness/etc. --Zach

Dec. 17, 2008