wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

How to create an ODBC DSN
by Martin HEIN 21 Jan '05

21 Jan '05

Hi folks, How can I use my working unixODBC DSN under wine, or how can I create a working Windows-based ODBC DSN using an underlying unixODBC DSN? Cheers, Martin -------------------------------------------------- T-Mobile Austria GmbH Ing.Martin HEIN Information Technologies / Services Knowledge Management & Process Automation / Senior Manager Rennweg 97-99 A-1030 Vienna Fon: +43-1-79585-6337 Fax: +43-1-79585-6584 Mobile: +43-676-82006337 E-Mail: Martin.HEIN(a)T-Mobile.at Web: http://www.T-Mobile.at -------------------------------------------------- NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. --------------------------------------------------

2 1

Re: Problems starting regedit without a .wine directory
by Michael Jung 21 Jan '05

21 Jan '05

On Friday 21 January 2005 18:32, you wrote: > We don't call any activation context functions in Wine, which suggests > that you are using some native dlls. Could you run with +loaddll? ... trace:loaddll:load_dll Loaded module L"Z:\\home\\mjung\\comctl32.dll" : native ... I had a comctl32.dll laying around in my home directory, which wine happily picked up. I wrongly assumed that there would be no possibility for wine to pick up a native dll if there is no .wine directory. Thanks for your tip! Ciao, Michael

1 0

we just hit the 1 MB mark!!
by Tom 21 Jan '05

21 Jan '05

Hello, Looks as if we just hit the 1 MB mark in wine-cvs commits for the first time. :-) Tom

2 1

Problems starting regedit without a .wine directory
by Michael Jung 21 Jan '05

21 Jan '05

Hi, if I start regedit on the current cvs version of wine without having a .wine directory in the users home directory I get the following console output: mjung@denkbrett:~$ rm -rf .wine mjung@denkbrett:~$ regedit wine: creating configuration directory '/home/mjung/.wine'... fixme:advapi:CheckTokenMembership (0x58 0x77c81810 0x77a3d474) stub! fixme:actctx:QueryActCtxW stub! disabling TCL support disabling TCL support fixme:advapi:CheckTokenMembership (0x54 0x77c8e1c0 0x77a3d3ec) stub! fixme:actctx:QueryActCtxW stub! wine: '/home/mjung/.wine' created successfully. fixme:advapi:CheckTokenMembership (0x54 0x77c4c148 0x77a1f8e4) stub! fixme:actctx:QueryActCtxW stub! err:win:CreateWindowExA bad class name "SysTreeView32" err:win:CreateWindowExA bad class name "SysListView32" err:win:CreateWindowExA bad class name "msctls_statusbar32" The regedit window is displayed, but the treeview- and listview-panes as well as the statusbar are not displayed (which seems reasonable given the last three log message). Did anybody else make these observations? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Help debugging Fotowire
by Antti Mäkelä 21 Jan '05

21 Jan '05

Hi, I'm trying to get a (Win or Mac) software from my local photo printing shop to work. The software is in Finnish, and downloadable from http://www.ifi.fi/programs/IFI_OnlineFoto.exe. From what I gather, the software is just licensed and translated version of Fotowire, found at http://www.fotowire.com/home/html/download.htm Anyway, I cannot get it to work. With 20041201 it crashed at the end of install process (still found it's way to the virtual drive though). This was fixed in 20050111. The problem with actual functionality, however, was not. The program starts with a wizard. The first dialog box says that the software wants to connect to Internet. When I click next, there is an quick "connecting to server - respond received" dialog box and then an error box with a message that says "erroneous response received - check your connection" and the program returns to the first screen. With 20041201 I got some errors about CalendarA's as quarter-stub, but these have disappeared with 20051101. How do I go on with debugging this problem? I tried setting WINEDEBUG=+all wine fwprint.exe, but no debug messages appear..I'm using Gentoo, kernel 2.6.10, gcc 3.4. Thanks for any and all assistance. Hopefully we can get this to work. I do have access to native DLLs from Win'98 or 2k if any of those can help. -- - Antti Mäkelä - http://www.cs.tut.fi/~zarhan - zarhan(a)cs.tut.fi - There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here,it will instantly disappear and be replaced by something even more bizarre and inexplicable.

6 15

Re: WINEDBG: add support to interrogate gdi objects
by Pouech Eric DMI AEI CAEN 21 Jan '05

21 Jan '05

> Message du 21/01/05 04:10 > > ChangeLog: > Ulrich Czekalla > * add support to interrogate gdi objects several comments: * the changes in db_disasm.c are not declared in the changelog. Morever, I don't see the need of passing an extra parameter in db_task_printsym as you don't need it (maybe you forgot that part from the patch ?) * for the pure gdi info. - always use (when looking for a symbol) the name of the DLL you're looking the symbol from. this has several good side effects: first, it shortens the scope for searching (as dbghelp treats all global symbol - static or public - in the same name space), this reduces the likely hood of name conflicts. Secondly, the search will be much faster (as dbghelp won't be searched for all loaded DLLs), and won't force loading of symbols in DLLs for which we haven't looked up symbols yet (deferred symbol loading). For example, you should use gdi32!GDI_HeapSel for the symbol out of gdi32. * why are you using the ldt_copy at all ? there's support in winedbg for linearizing 16bit addresses, so making a 16 bit addr out of gdi-sel and handle and linearizing it should work. * you should add the same functionality to the gdbproxy (or at least add a TODO in winedbg.c to remain that it has to be done) * you should document the feature (info.c and documentation/debugger.sgml) A+

2 1

Re: fix the DEVELOPER-HINTS file to reflect how things are really done
by Dimitrie O. Paun 21 Jan '05

21 Jan '05

On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote: > - FIXME("(%x,%p,%d): stub\n", hdc, p, count); ... > + FIXME("%p %p %ld\n", hdc, p, count); Well, I must agree with Andy: there's no reason to remove the 'stub' part, most of the code uses it, automated tools look for it, and it saves nothing. -- Dimi.

2 1

NTLMSSP authentication added to FreeDCE (requires Samba TNG, uses winbindd)
by Luke Kenneth Casson Leighton 21 Jan '05

21 Jan '05

i _would_ announce this on the samba mailing lists but the samba team have placed some rather fascist censorship in place, and consider any posting that i make to any samba.org addresses to be "net abuse". i've just modified winbindd (written in 2000 by tim and andrew) to be able to use it to do NTLM "challenge response" authentication. i also wrote a small library, containing two functions, which could be used by absolutely any project: they take a user+pass+domain, or a user+domain+challenge+responses. the functions don't care where your PDC is: it could be on the local machine, under which circumstances the back-end (winbindd) will adjust accordingly and save you some network traffic. both functions return a "blob" which is a NET_USER_INFO_3 structure, which contains valuable information - in particular, it contains the session key, but also it contains the equivalent of uid+gid+secondary groups: namely, the primary user rid, primary group rid, and secondary group SIDs etc. that the user is in. [for the benefit of the wine people: this information is essential for doing things like "ImpersonateNamedPipeClient" and "RpcImpersonateClient" in Wine / ReactOS, if the authentication being performed is to have any "meaning", as it's what gets passed to SeAccessCheck(). you can always of course return stub data and you can always have an implementation of SeAccessCheck return "ok"...] samba tng cvs can be obtained via www.samba-tng.org/cvs.html and freedce cvs from http://sf.net/projects/freedce. you can test the new interface by compiling and running bin/winbindauthtest - you must have a user of "test" with a password of "test". i may have one more thing to do - add "NamedPipe" security context "inheritance" to the client-side libraries in FreeDCE, but to be honest i don't think it's all that essential / there going to be a whopping big demand for it. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

load_VDMX - is the check for bCharSet == -1 necessary?
by Troy Rollo 21 Jan '05

21 Jan '05

In dlls/gdi/freetype.c, load_VDMX refuses to process ratio records in which bCharSet is 0. Looking at the meaning of bCharSet and the layout of the VDMX table <http://www.microsoft.com/OpenType/OTSpec/vdmx.htm>, I can see no rational reason for this, and no reason appears in the code. Since 13th December this has been generating a FIXME message for some fonts. Does anybody know of a reason why this check is necessary? Commenting it hasn't hurt anything obvious.

2 1

Re: fix the DEVELOPER-HINTS file to reflect how things are really done
by Andreas Mohr 21 Jan '05

21 Jan '05

Hi, On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote: > ChangeLog: > * fix the DEVELOPER-HINTS file to reflect how things are really done Did I miss something? > - FIXME("(%x,%p,%d): stub\n", hdc, p, count); > + BOOL WINAPI PolyBezierTo(HDC hdc, const POINT *p, DWORD count) > + { > + /* tell the user they've got a substandard implementation */ > + FIXME("%p %p %ld\n", hdc, p, count); This is a step backwards IMHO. It doesn't tell squat: the user doesn't know that this is a stub ("FIXME" what??), and he doesn't know that these are supposed to be the function parameters either (it could be any other variable debug printout, too - it's indistinguishable). To developers, such a printout might make sense if it's known to be the standard format (and I'd say it isn't!), but to people that aren't fiddling with Wine on a daily basis it will mean less than the previous form. OTOH, since "stub" is a somewhat nebulous word, too (to non-developers), it probably makes sense to leave it out (a FIXME does indicate a shortcoming after all, so such a non-specific output string makes it very likely that it's the whole function that is broken), but at least keep the braces that indicate function parameters. But OTOH, since "... stub" has been in use for ages, its meaning is probably common knowledge amoung many older Wine users, and it's only an extra 6 or 7 characters anyway, so I'd still leave it in. Greetings, Andreas Mohr

4 3

Re: [OLE #48] Restructure Unmarshaling Code
by Alexandre Julliard 21 Jan '05

21 Jan '05

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Add a new flag SORFP_NOLIFETIMEMGMT to tell the proxy manager not to > pass an outer unknown to IRpcProxyBuffer_CreateProxy. > - Move the low-level unmarshaling code into a new function, > unmarshal_object, so that it can be easily reused for unmarshaling > IRemUnknown. This causes the test to crash: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so marshal.c && touch marshal.ok marshal.c:329: Test failed: Number of locks should be 0, but actually is 2 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000002 in 32-bit code (0x00000002). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0000 EIP:00000002 ESP:4067fdcc EBP:4067fdd8 EFLAGS:00010216( - 00 -RIAP1) EAX:00000002 EBX:40776bf0 ECX:40031000 EDX:40340074 ESI:403c924c EDI:403c92a0 Stack dump: 0x4067fdcc: 407479d2 403c92e4 40776bf0 4067fdf4 0x4067fddc: 40747ff6 403c92a0 40776bf0 403c9230 0x4067fdec: 40378828 403c9258 4067fe0c 407481ba 0x4067fdfc: 403c9228 40776bf0 403787e0 403787c0 0x4067fe0c: 4067fe2c 40738c0c 403787e0 40776bf0 0x4067fe1c: 40776acf 403787c0 40573c81 00000000 0200: sel=1007 base=40031000 limit=00001f97 32-bit rw- Backtrace: =>1 0x00000002 (0x4067fdd8) 2 0x40747ff6 proxy_manager_disconnect+0x9e(This=0x403c9228) [/home/julliard/wine/wine/dlls/ole32/marshal.c:455] in ole32 (0x4067fdf4) 3 0x407481ba MARSHAL_Disconnect_Proxies+0x36(apt=0x403787e0) [/home/julliard/wine/wine/dlls/ole32/marshal.c:536] in ole32 (0x4067fe0c) 4 0x40738c0c COM_ApartmentRelease+0xe0(apt=0x403787e0) [/home/julliard/wine/wine/dlls/ole32/compobj.c:310] in ole32 (0x4067fe2c) 5 0x407392b5 CoUninitialize+0xad [/home/julliard/wine/wine/dlls/ole32/compobj.c:639] in ole32 (0x4067fe44) 6 0x4056ff2e test_marshal_proxy_apartment_shutdown+0x15e [/home/julliard/wine/wine/dlls/ole32/tests/marshal.c:393] in ole32_test (0x4067fe70) 7 0x40571979 func_marshal+0x59 [/home/julliard/wine/wine/dlls/ole32/tests/marshal.c:1063] in ole32_test (0x4067fe80) 8 0x40573ee5 run_test+0x81(name=0x40340a76) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:287] in ole32_test (0x4067fe94) 9 0x405740da main+0xf2(argc=0x2, argv=0x40340a58) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:327] in ole32_test (0x4067feac) 10 0x4056f190 __wine_exe_main+0x190 in ole32_test (0x4067ff2c) 11 0x405088a2 start_process+0x8a(arg=0x0) [/home/julliard/wine/wine/dlls/kernel/process.c:1046] in kernel32 (0x4067fff4) 12 0x4001ccd5 wine_pthread_abort_thread+0x29(status=0x0) [/home/julliard/wine/wine/libs/wine/port.c:85] in libwine.so.1 (0x00000000) -- Alexandre Julliard julliard(a)winehq.org

1 0

Regression : tools/wineinstall fails with an X Error
by Paul Vriens 21 Jan '05

21 Jan '05

Hi, doing a tools/wineinstall on a clean system yields in an X-Error. Doing: winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf gives: .. Wine-dbg>bt Backtrace: =>1 0x00abec49 (0x00a6d7f4) 2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d818) 3 0x00767b5a WIN_DestroyWindow+0xf2(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:655] in user32 (0x00a6d830) 4 0x007699be DestroyWindow+0x116(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:1517] in user32 (0x00a6d854) 5 0x00ff6862 COM_ApartmentRelease+0x146(apt=0x77e60090) [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:338] in ole32 (0x00a6d870) 6 0x00ff6f54 CoUninitialize+0x100 [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:641] in ole32 (0x00a6d888) 7 0x00934c2f register_filters+0x28f(list=0x946700) [regsvr.c:644] in quartz (0x00a6d8e0) 8 0x009350cb QUARTZ_DllRegisterServer+0x6b [regsvr.c:1078] in quartz (0x00a6d8f0) 9 0x00843686 do_register_dll+0xca(info=0xa6fb80, path=0x77e51400, flags=0x1, timeout=0x3c, args=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:491] in setupapi (0x00a6d924) 10 0x00843a2a register_dlls_callback+0x1a6(hinf=0x77e15ce0, field=0xa6f9b4, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:574] in setupapi (0x00a6f970) 11 0x00843f48 iterate_section_fields+0xe0(hinf=0x77e15ce0, section=0xa6fbe4, key=0x852420, callback=0x843884, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:696] in setupapi (0x00a6fb50) 12 0x0084421c SetupInstallFromInfSectionW+0x8c(owner=0x10024, hinf=0x77e15ce0, section=0xa6fbe4, flags=0x3ff, key_root=0x0, src_root=0x0, copy_flags=0x4, callback=0x84a894, context=0x77e8bda8, devinfo=0x0, devinfo_data=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:851] in setupapi (0x00a6fbac) 13 0x00844625 InstallHinfSectionW+0x101(hwnd=0x10024, handle=0xc30000, cmdline=0x77bd05a8, show=0x1) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:934] in setupapi (0x00a6fe00) 14 0x00c327da main+0x1aa(argc=0x5, argv=0x77de0420) [/data/install/linux/wine-src/wine/programs/rundll32/rundll32.c:291] in rundll32 (0x00a6fe9c) 15 0x00c32163 __wine_exe_main+0x163 in rundll32 (0x00a6ff2c) 16 0x0029d2d7 start_process+0xc3(arg=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/process.c:1046] in kernel32 (0x00a6fff4) 17 0x004ec6a5 __GI_____strtof_l_internal+0x155 in libc.so.6 (0x00000000) I didn't do a regression test yet, to find the cause, but the error seems to be in COM_ApartmentRelease during the DestroyWindow(apt->win) I've applied OLE # 45 already. Will do some more testing tonight. Cheers, Paul.

6 17

Re: dlls/comctl32/status.c
by Alexandre Julliard 21 Jan '05

21 Jan '05

Ge van Geldorp <gvg(a)reactos.com> writes: > Changelog: > Gunnar Dalsnes <hardon(a)online.no> > STATUSBAR_SetTextT: > - ntext wasn't freed on return if text was unicode > - part->text was allways freed, but if the previous style was SBT_OWNERDRAW, > part->text would contain 32bit data (not a buffer ptr.) Conversely, if the previous style was not SBT_OWNERDRAW but the new one is you should free the text pointer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/comctl32/status.c
by Mike McCormack 21 Jan '05

21 Jan '05

Ge van Geldorp wrote: > diff -u -r1.69 status.c > --- dlls/comctl32/status.c 9 Jan 2005 16:42:54 -0000 1.69 > +++ dlls/comctl32/status.c 13 Jan 2005 09:05:24 -0000 > @@ -650,6 +650,7 @@ > { > STATUSWINDOWPART *part=NULL; > BOOL changed = FALSE; > + WORD oldStyle; That should be a DWORD, shouldn't it? Mike

1 0

Re: RtlQueryRegistryValues and RtlCheckRegistryKey
by Robert Shearman 21 Jan '05

21 Jan '05

Ivan Leo Puoti wrote: > Implement RtlQueryRegistryValues, RtlCheckRegistryKey is implemented in > this patch as a free bonus. Thanks to the guys on IRC for their help. > > BTW when RtlCheckRegistryKey is called with the RTL_REGISTRY_HANDLE flag, > it always returns STATUS_SUCCESS, even if called with NULL, an invalid > HKEY, > a string containing rude words, a random number, and anything else I > could think of, > so that's why STATUS_SUCCESS is always returned when > RTL_REGISTRY_HANDLE is set. >+NTSTATUS WINAPI RtlCheckRegistryKey(IN ULONG RelativeTo, IN PWSTR Path) >+{ >+ HKEY handle; >+ NTSTATUS status = STATUS_SUCCESS; >+ if((!RelativeTo) && Path == NULL) >+ return STATUS_OBJECT_PATH_SYNTAX_BAD; >+ if(RelativeTo & RTL_REGISTRY_HANDLE) >+ return status; >+ if ((RelativeTo & 0xff) <= 5) >+ { >+ if(RelativeTo & RTL_REGISTRY_HANDLE) >+ handle = (HANDLE)Path; > > This test is redundant due to the test outside of this block. >+ else >+ status = RTL_GetKeyHandle(RelativeTo, Path, &handle); >+ if(status==STATUS_INVALID_HANDLE) >+ return STATUS_OBJECT_NAME_NOT_FOUND; >+ if(status==STATUS_ACCESS_DENIED) >+ return STATUS_ACCESS_DENIED; >+ if(status!=STATUS_SUCCESS) >+ return status; >+ } >+ else >+ return STATUS_INVALID_PARAMETER; >+ return status; >+} > > Rob

1 0

Re: wined3d updates
by Ann and Jason Edmeades 20 Jan '05

20 Jan '05

Hi Oliver, D3DRESOURCETYPE WINAPI IWineD3DCubeTextureImpl_GetType(IWineD3DCubeTexture *iface) { - return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface); + return IWineD3DResource_GetType((IWineD3DResource *)iface); } This is wrong (and others) - you'll end up in an infinite loop. You must calls the impl type if you are effectively casting the interface into one of the types it inherits from I haven't got chance to review the rest yet - I'm heading away for the weekend. I'll look at the rest on Mon if you want any comments. Jason

1 0

Font selection logic defective?
by Bill Medland 20 Jan '05

20 Jan '05

(Huw?) Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available? Note that my font knowledge is quite minimal Context When I installed our product on a clean Red Hat Enterprise Linux 3 test machine it looked relatively acceptable. However on my own development machine (again RHEL3) for several texts the font was too large and overflowed the area that had been allocated for it. Then when I installed on Mandrake 10.0 I noticed the same large fonts. So I dug. On my machine (and probably on the Mandrake too; I don't know since I've trashed it) OpenOffice.org is installed. It installs /usr/share/fonts/openoffice, containing Vera*.ttf. As an example the Splash screen asks for an Arial font. My development machine runs through the fonts it knows about and selects the Bitstream Vera Sans, which is not a good match. The test machine has no ttf files to work from and so it reverses the Helvetica-Arial substitution (Hm!!! poor registry setup, I reckon) and performs a match for a Helvetica font and finds a much more acceptable font. So it seems to me that merely because OpenOffice.org has installed a couple of ttf fonts my development machine will select from a small list of ttf fonts and ignore a large list of x11 fonts. Am I correct? What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 6

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros
by Juan Lang 20 Jan '05

20 Jan '05

Hi Luke, I don't know is this is useful, but the TRY/CATCH stuff in particular is declared here: http://source.winehq.org/source/include/wine/exception.h and the Wine exception handling code is implemented here: http://source.winehq.org/source/dlls/ntdll/exception.c As Mike said, the Wine threading stuff is pretty complicated. Native applications unfortunately rely on things being exactly in the right place in the TEB, and DCE threads are unlikely to give us this. Peruse if you like http://source.winehq.org/source/include/thread.h and http://source.winehq.org/source/dlls/ntdll/thread.c --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: RpcImpersonateClient (and ImpersonateNamedPipeClient)
by Juan Lang 20 Jan '05

20 Jan '05

Hi Luke, you said: > that's where you'd need the cooperation of samba / samba tng: > it's got "SIDs" behind it, and "SIDs" means a SAMR server > and a NETLOGON server and an LSARPC server (and in the > case of windows 2000 interoperability, access to an Active > Directory Server). Another possibility is that we implement our own version of a SAM. Right now we just return a fake Administrator SID every time we're asked for one. But if we absolutely needed to, we could implement a local version and it needn't even be a separate process. The NT SAM registry is pretty well reverse engineered here: http://neworder.box.sk/files/nullak_ntsecurity/index.php > you can always still implement RpcImpersonateClient as a stub. Yah. I think that's more likely than that we go whole-hog on it. From experience, it's often more important to get things like parameters and error codes just the way Windows programs expect than it is to make a function "really work." By implementing a stubbed or local-only version, we can figure out all this stuff, and maybe make a full-blown version later. and later, > it _does_ mean careful design because i doubt very much whether people > will be happy to have samba tng as a dependency on Wine. Agreed. The focus for the Wine folks is generally, does this get my app to work? Unless it's fixing an app, not too many folks are likely to get real excited by anything. Feel free to point out what we've been missing. Patches speak louder than anything here :) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

Re: Running dxdiag
by Juan Lang 20 Jan '05

20 Jan '05

Hi Mike, > Dumping the headers is necessary for stupid installers that map DLL files > manually and rummage around in the headers to figure out versions and > stuff ... simply having an empty file isn't enough for all of them I'm > afraid :( This isn't enough for new installers, either :( I have an MSI-based InstallShield installer that's looking for shdocvw.dll to see if IE6 is installed. (It isn't, but that's how it's looking for it.) Trouble is, how would this work with the native/builtin thing? Right now all our builtins don't live in the system directory, so we can always override whatever native dll happens to get dropped there. If we put a little stub PE header in there, what's to stop an installer from overwriting it? Or, would this cause a problem? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

3 2

Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros
by Luke Kenneth Casson Leighton 20 Jan '05

20 Jan '05

hi, as you may be aware, dce threads is posix draft 4 threads and FreeDCE has an emulation library kindly made up-to-date to successfully run even on NPTL on x86 and AMD64, courtesy of loic. http://cvs.sourceforge.net/viewcvs.py/freedce/dcethreads/ it is my understanding / guess that microsoft, in their adoption of DCE 1.0 some fifteen years ago for NT 3.1, ported DCE threads to Win32 [hence, you have all those lovely TRY CATCH RAISE macros in all the lovely MSVC++ programs, whoopeee] so i was wondering if someone could point me in the direction of some Wine source code - testing, implementation, macros etc. that would allow me to vaguely confirm whether my suspicions are correct. the first hypothesis i want to test is this: namely, that Wine applications would run _better_ [read, "more correctly"] by using dcethreads than by using its present implementation of Win32 threads. the _other_ hypothesis i want to test is this: namely, that FreeDCE applications would be more "palatable" in today's modern environment if compiled with Wine's threading code! according to loic, who is an expert on the different thread models, the thing is that certain syscalls are not interruptable / cancellable in Posix Draft 4 threads and in NPTL they are. this CHANGES the behaviour of any programs using the wrong threading library in subtle ways. thus, certain applications suddenly become unreliable where they were previously fine. etc. l. p.s. i don't claim to know all the answers, nor all the questions. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Re: Fwd: Re: Wine builtin mscms.dll
by Hans Leidekker 20 Jan '05

20 Jan '05

On Thursday 20 January 2005 08:04, you wrote: > I got your name from Mike. I was wondering if you could give me a pointer or a > hint on how to use wine's builtin mscms.dll. A simple DLL override in > .wine/config does not seem to do the job (using wine-20041210). Well, you have to realize that development on mscms in Wine has only been started a couple of months ago. My estimate is that it's now about 20% done and still missing basic functionality. And I have only weekends to spend time on it ;( So your best bet at this time is a native mscms. > (It works with a native mscms.dll file copied to the windows/system directory, > but with a specific application, makes it 5 times slower). The 5 times slow down you're seeing is not normal. Maybe you can investigate the problem a little more and report to the Wine development list at wine-devel(a)winehq.org? -Hans

1 0

Re: [LOSTWAGES] update the non-standard include files task (RESEND)
by Rémi Assailly 20 Jan '05

20 Jan '05

Selon "Dimitrie O. Paun" <dpaun(a)rogers.com>: > On Thu, Jan 20, 2005 at 02:58:22PM +0900, Mike McCormack wrote: > > > > So did you ;) Here's a merge of both. > > I don't do this on purpose, but you missed win.h again :) > Again, with feeling... > > -- > Dimi. > win.h still exists...

2 1

RpcImpersonateClient (and ImpersonateNamedPipeClient)
by Luke Kenneth Casson Leighton 20 Jan '05

20 Jan '05

1 0

Native comctl32.dll and native commctrl.dll
by Dripple 20 Jan '05

20 Jan '05

Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple

2 3

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2005