January 2004 - Wine-Devel - list.winehq.org

Re: Unicode and CP_SYMBOL question. [?? Probable Spam]

by Rein Klazes

On Thu, 15 Jan 2004 16:20:28 +0800, you wrote: [?? Probable Spam] Your spam filter needs to be educated about wine-devel ;-) > > > > Is there any reason why in this case MultiByteToWideChar should not do > > w = c + 0xf000 ? > > Wine is using the following source for its Symbol to unicode map: > ftp.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt Yes, I've seen that, it is pity that Windows seems not to use it. > > Apparently Windows uses something different. Probably we have to change > our internal map for Symbol encoding I will try a few other Windows versions first. It looks to me that Symbol encoding is not a real encoding at all apart from the 0xf000 offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably for that reason.. > since we are doing already something > similar to your findings in dlls/gdi/freetype.c,FT_UInt get_glyph_index(). Yup, that is, I think, because it needs to work for non Unicode characters as well. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 15, 2004

Re: Unicode and CP_SYMBOL question. [?? Probable Spam]

by Dmitry Timoshkov

"Rein Klazes" <rklazes(a)xs4all.nl> wrote: > Wine's implementation of MultiByteToWideChar() does something quite > complicated based on standard unicode tables and returns Unicode > characters in all kind of ranges. > > The loop above is basically what Win2K's charmap.exe does. Of course it > does not properly display symbol fonts like "Symbol". > > Is there any reason why in this case MultiByteToWideChar should not do > w = c + 0xf000 ? Wine is using the following source for its Symbol to unicode map: ftp.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt Apparently Windows uses something different. Probably we have to change our internal map for Symbol encoding since we are doing already something similar to your findings in dlls/gdi/freetype.c,FT_UInt get_glyph_index(). -- Dmitry.

Jan. 15, 2004

Unicode and CP_SYMBOL question.

by Rein Klazes

Hi, Trying to fix a problem with Win2K's charmap.exe, I have a question for the unicode experts. If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K system, like in this snippet: char c;WCHAR w; for( c = 32; c; c++) MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1); I get that w == c + 0xf000 ( codes 0-31 are unchanged, any flag setting makes the function fail). Wine's implementation of MultiByteToWideChar() does something quite complicated based on standard unicode tables and returns Unicode characters in all kind of ranges. The loop above is basically what Win2K's charmap.exe does. Of course it does not properly display symbol fonts like "Symbol". Is there any reason why in this case MultiByteToWideChar should not do w = c + 0xf000 ? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 15, 2004

Re: Better cpuid support

by Robert Lunnon

On Thursday 15 January 2004 15:53, Alexandre Julliard wrote: > Robert Lunnon <bobl(a)optushome.com.au> writes: > > 1. The original cpuid and i386 detect are merged into a single assembly > > call for convenience. > > Much less readable IMO. A little less readable in my opinion, this assembly code is documented in the intel/AMD handbooks as implemented. It performs a single logical function by determining CPUID information from 386 through Athlon. > > > 2. The data is then interpreted into a structure for use. Understanding > > CPUID means knowing the cpuid_t structure and CPUID_IsFeatureAvailable > > call. All the specifics are isolated into GetId for maintainablity. > > There's no reason to introduce that structure, we can set the Windows > fields directly. We don't need the specifics of CPUID anywhere else > than for setting the corresponding bits which already have well > defined names. > We disagree, I think this is much easier to maintain, the names I use relating to registers are reflected in the cpuid documentation from intel and AMD so the actuall cpuid details are clearer. Because the feature names are used in adding the equivalent features to the Windows Structures it is easy to see where this information comes from. > > 3. The OS Specifics for testing OS support of multiple CPUs and SSE were > > moved into their own subroutines. This abstracts these functions to > > permit the code in the FREEBSD section to be OS independent. Note that I > > copied/added code to each of these subroutines to support all the > > platforms that were already supported for that feature. Much of this code > > is currently redundant unless someone wants to change the existing linux > > or NETBSD sections (Which currently use other methods). The redundant > > code was added to allow this to happen. > > On linux your new code will cause multiple opening and parsing of > /proc/cpuinfo (and leak file descriptors...) OOPs, yes a bug, I will fix that if you like (or you can add the close call). And yes this re-reading is a side effect of making the cpuid code OS independent (hopefully the linux buffer-cache is good) ... There may be a better way to implement this under linux and avoid the re-reading but without knowing linux I wanted to avoid adding too many bugs that I can't necessarily debug (You already found one !) > > > 3. The information collection and feature tests in the FREEBSD code were > > changed to use cpuid_t and IsFeatureAvailable in a way exactly equivalent > > to the original adding support for detection of PAE and SSE in the > > process (Though OS_SSESupported will need a test for SSE for FREEBSD to > > work) There is no test for Solaris SSE test since SSE isn't supported at > > all there (Yet). > > The new IsFeatureAvailable thing results in calling cpuid and parsing > the results again and again at least a dozen times for no good reason. > This is true, but it is not very time consuming. I had considered caching the cpuid results which would eliminate the multiple handling but didn't feel it was worth the effort. This function does not tend to get called often in windows programs (Usually once) but If you like I'll add the caching. > Please consider working with the existing code instead of throwing it > all away and replacing it by your own favorite routines which simply > don't fit in with the rest of the code. I threw very little away, I just abstracted the interface to the cpuid instruction and OS specifics. The change in the assembly code is incidental. Bob

Jan. 15, 2004

Re: Wine User's guide : using Windows ODBC driver manager seems to work

by Boaz Harrosh

Yes it works. My QA tested it throughly with MSSQL driver and there are no reported problems. The best way to go is a free download from Microsoft. mdac_typ.exe . Just Install it under wine and off you go. Also many MS applications Install them (like office). Than in system folder find cliconfig.exe & odbcad32.exe put them on the desktop. These are the same apps from the windows control panel. (you do have .exe associate with wine! yes?) Emmanuel Charpentier wrote: > Following a suggestion in Wine User's Guide, (§ 1.1.2), I'd like to > suggest an addition. > > The "ODBC" section (§ 5.12) gives details (§ 5.12.1) about the use of > the native ODBC driver, routed through a fake "builtin" ODBC driver. I > have not yet had to test it in real conditions. All I can tell is that > I wasn't able to use it to "Attach" (M$ jargon) Postgres data in MS > Access (see PPS for the setup) : when I tried to select "ODBC sources" > from the "Attach tables" dialog, I got immediately an error box from > unixODBC telling me that no data source was specified. > > However, the User's Guide is quite terse about the Windows ODBC > driver. Exhaustive quotation : " Does anyone actually have any > experience of this and anything to add?". > > Well, I do. In the same setup as before, I have been able to use the > *native* odbc32.dll ODBC driver by pulling it from a real Windows > instalation and adding "odbc32"="native,builtin" in the config file. I > Installed the psqlodbc driver from the Postgres database, and retried > : selecting "ODBC sources" in the "Attach tables" dialog box led me to > the usual ODBC manager dialogs, where I have been able to create a DSN > to my Postgres database. I have then been able to "Atach" my Postgres > tables and views to an M$ Access database and peruse them. > > My conclusion is that such a setup can be used, if only to be able to > export MS Access data to a more reasonable database manager. This > information could be of some help to some people, and I'd like to see > it reflected in the User's guide. > > Of course, I'm aware that such a quick test is no substitute to real > tests and explorations. Feel free to reach to me for further > information, test cases, etc ... > > Sincerely yours, > > Emmanuel Charpentier > > PS : I'm not on this list. Please Cc: me if you wishme to react to > your answers. > > PPS : Setup : Debian (unstable), 2.4.21 kernel, Wine 20031212 as > packaged in Debian, Win98SE (french), "fake windows" setup, using > native stdole.tlb, ole32.dll, oleaut32.dll, rpcrt4.dll and, of course, > odbc32.dll, MS Office 97 (installed without a hitch from the CD, > except for a "Can't DDE connect to desktop" error in the setup, > ignored) + SR1 parch. I have had success with SR2b, but this needs a > lot more native DLLs, and I can't recall them at the moment (work > machine). >

Jan. 15, 2004

Re: Janitorial: Get rid of W->A calls for shlexec [RESEND]

by Marcelo Duarte

Why my patch was not applied? If it will be because it conflicts with the patches of the ROS, can leave that in the next weekend I intend to make this, thus diminishes the work of them. But necessary to know if my patch it goes to be accepted, if I do not go to be losing my time. Thank you. Em Sáb 10 Jan 2004 04:51, Marcelo Duarte escreveu: > Updated with the lastest cvs. > > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > -Janitorial: Get rid of W->A calls for shlexec > -Implementation of FindExecutableW -- Marcelo Duarte

Jan. 15, 2004

Re: Better cpuid support

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > 1. The original cpuid and i386 detect are merged into a single assembly call > for convenience. Much less readable IMO. > 2. The data is then interpreted into a structure for use. Understanding CPUID > means knowing the cpuid_t structure and CPUID_IsFeatureAvailable call. All > the specifics are isolated into GetId for maintainablity. There's no reason to introduce that structure, we can set the Windows fields directly. We don't need the specifics of CPUID anywhere else than for setting the corresponding bits which already have well defined names. > 3. The OS Specifics for testing OS support of multiple CPUs and SSE were moved > into their own subroutines. This abstracts these functions to permit the code > in the FREEBSD section to be OS independent. Note that I copied/added code to > each of these subroutines to support all the platforms that were already > supported for that feature. Much of this code is currently redundant unless > someone wants to change the existing linux or NETBSD sections (Which > currently use other methods). The redundant code was added to allow this to > happen. On linux your new code will cause multiple opening and parsing of /proc/cpuinfo (and leak file descriptors...) > 3. The information collection and feature tests in the FREEBSD code were > changed to use cpuid_t and IsFeatureAvailable in a way exactly equivalent to > the original adding support for detection of PAE and SSE in the process > (Though OS_SSESupported will need a test for SSE for FREEBSD to work) There > is no test for Solaris SSE test since SSE isn't supported at all there (Yet). The new IsFeatureAvailable thing results in calling cpuid and parsing the results again and again at least a dozen times for no good reason. Please consider working with the existing code instead of throwing it all away and replacing it by your own favorite routines which simply don't fit in with the rest of the code. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2004

Re: Solaris specific configuration

by Robert Lunnon

On Thursday 15 January 2004 06:57, Alexandre Julliard wrote: > Robert Lunnon <bobl(a)optushome.com.au> writes: > > Changelog > > Autodetection of XFREE86 as required for Solaris. > > This should be done in configure, assuming it is really necessary. Why > can't we use the standard Xlib? It would be nice but there is a bug in Solaris XLib that wine tickles so for the moment you need to use a third party XLib. Hence LD_OPTIONS must be set to serch /usr/X11R6/lib first. configure does detect Xfree86 but Xsun gets used by default where both are present. This is a very common configuration. Since configure has strictly the correct default behaviour (aside from the fact it doesn't work) I wanted to override it in wineinstall rather than get autoconf to prefer Xfree86! Ultimately I am hoping Sun will follow my advice and fix their xlib. It could also be due to the threding implementation using _lwps which aren't guaranteed safe Besides wineinstall already had a section to add os specifics I just automated mine and thought it'd be a useful addition.

Jan. 15, 2004

Re: ifenum.c mtu acquisition - Solaris

by Robert Lunnon

On Wednesday 14 January 2004 14:50, Dimitrie O. Paun wrote: > On January 13, 2004 09:46 pm, Robert Lunnon wrote: > > +#if !defined sun > > *mtu = ifr.ifr_mtu; > > +#else > > + *mtu=ifr.ifr_metric; > > + #endif > > The #endif is not properly indented, any special reason? Damned editor !

Jan. 15, 2004

Re: Better cpuid support

by Robert Lunnon

On Thursday 15 January 2004 10:45, Alexandre Julliard wrote: > Robert Lunnon <bobl(a)optushome.com.au> writes: > > Improves CPUID instruction support in cpu.c by reorganising the existing > > FREEBSD code. Added more robust cpuid detection with built in 386 > > detection. Code should work for all i386 platforms and has been tested > > under solaris. Created subroutines for detecting number of CPUs and OS > > SSE support as this can't be done in a uniform way across different OSes. > > Extracted relevant code from each section to perform these OS specific > > operations (Mostly untested). > > It's hard to tell exactly what has changed, since you basically > rewrote the whole thing, for no good reason IMO. Could you please > try to merge your changes with the existing code instead? I see no reason to, the code functions perfectly well as it is, I restructured it for a couple of reasons. 1. Firstly I had the code available tested and working. Increasing the distribution of the code through cpu.c risked breaking it. 2. The code as it stood was hard to understand particularly in seeing what was being detected from the cpuid instruction due to hardcoded shifts and masks. I think this code is much easier to read ( Especially without the CPUID instruction documentation in front of you ) 3. Merging was difficult due to the specific calls to OS functions for number of cpus and the hardcoded numbers. 4. The code as it stands is more modular and more extensible/maintainable. For example Cyrix or Winchip support should be trivial to add as would support for other cpuid extensions (IA64 perhaps) Only CPUID_GetId should need to be changed to support future cpuid extensions assuming the chip manufactures follow the same calling conventions. To assist I will explain the scope of the changes 1. The original cpuid and i386 detect are merged into a single assembly call for convenience. 2. The data is then interpreted into a structure for use. Understanding CPUID means knowing the cpuid_t structure and CPUID_IsFeatureAvailable call. All the specifics are isolated into GetId for maintainablity. 3. The OS Specifics for testing OS support of multiple CPUs and SSE were moved into their own subroutines. This abstracts these functions to permit the code in the FREEBSD section to be OS independent. Note that I copied/added code to each of these subroutines to support all the platforms that were already supported for that feature. Much of this code is currently redundant unless someone wants to change the existing linux or NETBSD sections (Which currently use other methods). The redundant code was added to allow this to happen. 3. The information collection and feature tests in the FREEBSD code were changed to use cpuid_t and IsFeatureAvailable in a way exactly equivalent to the original adding support for detection of PAE and SSE in the process (Though OS_SSESupported will need a test for SSE for FREEBSD to work) There is no test for Solaris SSE test since SSE isn't supported at all there (Yet). So there isn't a documented way to query it. 5. Finally #elif defined (__FREEBSD__) was changed to #elif defined (__i386__) since the code within now works for all i386 platforms. (Ultimately this was the objective of the patch) The #ifdef sections for linux and NETBSD remain unchanged for the moment in order to minimise the possibility of me breaking anything. Bob

Jan. 15, 2004

Re: Better cpuid support

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > Improves CPUID instruction support in cpu.c by reorganising the existing > FREEBSD code. Added more robust cpuid detection with built in 386 detection. > Code should work for all i386 platforms and has been tested under solaris. > Created subroutines for detecting number of CPUs and OS SSE support as this > can't be done in a uniform way across different OSes. Extracted relevant code > from each section to perform these OS specific operations (Mostly untested). It's hard to tell exactly what has changed, since you basically rewrote the whole thing, for no good reason IMO. Could you please try to merge your changes with the existing code instead? -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2004

Re: comctl32/imagelist -> ImageList_Remove problem

by Michael Stefaniuc

On Wed, Jan 14, 2004 at 02:25:33PM -0800, hatky wrote: > I run a free program call The All-seeing Eye, > available for free at: > http://www.udpsoft.com/eye2/index.html > And run into a few errors like this: > err:imagelist:ImageList_Remove index out of range! 0 That's probably only cosmetic, see below > ImageList_Remove gets( > ????????HIMAGELIST??himl, > ????????int??i) > > line 2040 of imagelist.c says: > if ((i < -1) || (i >= himl->cCurImage)) { > ERR("index out of range! %d\n", i); > return FALSE; > } The name cCurImage in HIMAGELIST is misleading, it's not the current image but the count of images in the imagelist (see imagelist.h). With i=0 that means that himl->cCurImage=0 aka no images in the imagelist. MSDN dosn't specify what to return when we try to free the first image of an empty imagelist so this needs to be checked with a wine test. > > But since > "When an image is removed, the indexes of the > remaining images are adjusted so that the ...." > > I assume most call do not include an index but only > the handle as the case with this program from the > trace I checked it sends 0 as the i and a true handle > in himl and it makes since, since it first calls > ImageList_Create to add images and ImageList_Create > returns "Handle to the created image list" and not the > place (remember the place changes anyway....) > So..... > > I assume that in the case of the i = 0 the procedure > should locate the i itself from the handle, am I > right? No, it means delete the image at position 0. bye michael > > getting close to his first patch :), > Hatky. > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 15, 2004

Need help debugging ...

by Frank.Schruefer＠t-online.de

Hy list, I like to learn how to fix wine problems myself and am trying to track down an exception occuring while starting good old 'Dungeon Keeper'. For now I have two problems: 1. When I invoke the game with 'wine' and with 'winedbg' I get different exception messages (traces see below), why? 2. How to compile debug information into the 32bit DLL's so I don't get 'No debug information in 32bit DLL' anymore and maybe some better info? I tried 'configure --enable-debug && make depend && make && su -c "make install"' to no avail. I compiled 'fixme's into the 'SetThreadExecutionState' and 'VerSetConditionMask' funcs to see where the exceptions occure but it seems the methods aren't even called at all because the messages don't get printed out (or need the fixme messages switched on somewhere for that particular dll?). I also tried to start with --debugmsg +all in which case the output is overwriting the winedbg command line interface and crashing it when trying to exit with CTRL-C and CTRL-D. Only killall -9 wine-pthread helps then. The wine I'm using is fresh from CVS as of 15. Jan. 2004 but I had the problem with earlier versions too. ============= STARTING WITH 'wine' ================ merlin(a)Merlin:~/.wine/fake_windows/Program Files/Bullfrog/Keeper> wine KEEPER95.EXE wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 Loaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40760000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408f0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x409e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40960000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40022000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40be0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40c30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40a80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41390000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x413e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x413c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41400000) Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x00406062). In 32-bit mode. 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): movb $0x0,0x0(%eax) Wine-dbg>bt Backtrace: =>0 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) (ebp=406cff2c) 1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL32.DLL) (ebp=406cfff4) 2 0x4003e60d (SMACKW32.DLL..reloc+0x660d) (ebp=00000000) Wine-dbg> ============= STARTING WITH 'wine' END ============ ============= STARTING WITH 'winedbg' ============= merlin(a)Merlin:~/.wine/fake_windows/Program Files/Bullfrog/Keeper> winedbg KEEPER95.EXE fixme:console:SetConsoleCtrlHandler (0x405feed0,1) - no error checking or testing yet WineDbg starting on pid 19 Breakpoint 1 at 0x004f1ed0 Unable to add breakpoint, will check again any time a new DLL is loaded Loaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40760000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408f0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x409e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40960000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40a05000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40be0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40c30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41390000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x413e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x413d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41400000) In 32-bit mode. Wine-dbg>cont Stopped on breakpoint 1 at 0x004f1ed0 (KEEPER95.EXE.EntryPoint in KEEPER95.EXE) Wine-dbg>cont First chance exception: page fault on write access to 0x00000000Invalid address for breakpoint 1, disabling it in 32-bit code (0x00406062). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0007 EIP:00406062 ESP:406cfd18 EBP:406cff2c EFLAGS:00010206( R- 00 I - -P1 ) EAX:00000000 EBX:ffffffff ECX:00000000 EDX:406cfcec ESI:00776685 EDI:406cfd99 Stack dump: 0x406cfd18 (KERNEL32.DLL.VerSetConditionMask+0x14e97a): *** Invalid address 0x406cfd18 (KERNEL32.DLL.VerSetConditionMask+0x14e97a) 0200: sel=1007 base=4001a000 limit=00001f83 32-bit rw- Backtrace: =>0 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) (ebp=406cff2c) Can't read TEB:cur_stack 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): *** Invalid address 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE) -- no code -- Wine-dbg> ============= STARTING WITH 'winedbg' END ========= -- Thanks, Frank

Jan. 15, 2004

winecfg: a patch to review

by Kirk Ruff

Hello, I have started to work on winecfg a little in attempt to get used to some workings of WINE. This is the first real open source project I have actually tried to submit a patch to. I have started to work on a few functions that were not implemented yet and before I forget to try to submit a patch again I thought I would do it now. The only part I have included in this patch is the ability to remove an application from the "Application" tab. The way I assumed that this was to do is remove the appropriate key from the registry and update the listview. I realize this is a pitiful patch since it really doesn't add much but I thought I would see if I am doing it correctly and to see if does what it should. Any help is appreciated(I hope this patch is inline, my first try at it. Kirk

Jan. 14, 2004

comctl32/imagelist -> ImageList_Remove problem

by hatky

I run a free program call The All-seeing Eye, available for free at: http://www.udpsoft.com/eye2/index.html And run into a few errors like this: err:imagelist:ImageList_Remove index out of range! 0 ImageList_Remove gets( HIMAGELIST himl, int i) line 2040 of imagelist.c says: if ((i < -1) || (i >= himl->cCurImage)) { ERR("index out of range! %d\n", i); return FALSE; } But since "When an image is removed, the indexes of the remaining images are adjusted so that the ...." I assume most call do not include an index but only the handle as the case with this program from the trace I checked it sends 0 as the i and a true handle in himl and it makes since, since it first calls ImageList_Create to add images and ImageList_Create returns "Handle to the created image list" and not the place (remember the place changes anyway....) So..... I assume that in the case of the i = 0 the procedure should locate the i itself from the handle, am I right? getting close to his first patch :), Hatky. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 14, 2004

Re: Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?

by Mike Hearn

On Wed, 14 Jan 2004 14:51:13 +0200, MediaHost (TM) wrote: > Well, I guess, that there are people actively developing...It might be > easier for them to get a fix done... It wouldn't be too hard to stub it. Wine doesn't really have any of the multi-user APIs implemented, there seems little point when you we can just pretend we're a single user system and let the underlying OS deal with multi-user capabilities. If I were you I'd just make this function return HKEY_LOCAL_USER and ignore which user was requested, assuming that would satisfy the spec

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > Looks like a solution to me. What about dxguid? Should we split > uuid up by creating a seperate directory with Makefile etc. or > will a symlink to libuuid do? I think we should create a separate library. I'm also wondering if we shouldn't move them to dlls/, these are more like import libs than normal Unix libs. -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: strange warning message when buildint current cvs

by Vincent Béron

Le mer 14/01/2004 à 12:01, Ivan Leo Murray-Smith a écrit : > With current cvs, I get this strange warning message > [snip] > gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe > -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g > -O2 -o winetest.exe.spec.o winetest.exe.spec.c > {standard input}: Assembler messages: > {standard input}:856275: Warning: .stabs: description field '1a385' too big, try > a different debug format [snip] > Wine build complete. > > I've tried make distclean and I still get it. I'm using gcc 3.3.1-2mdk, does > this classify as something that should be fixed? IIRC, somebody else also reported this and Eric replied saying it didn't really matter. Stabs has a size limit for some info, and winetest has more info than the limit. It doesn't seem to cause some problems though. Vincent

Jan. 14, 2004

Re: More Vacation backlog

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > appended patch opens the devicefile connected to a drive as connected by the > user in ~/.wine/config [Drive X] "Device" = "/dev/yyy". > The appropriate action on that file ( read, write, set_file_pointer, ...) > succeed > according the the righte the user has on that device. The device should be opened like a normal file, using the create_file request. Then there wouldn't be any need to change the server device object (which is a nasty hack that should be removed). -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: Solaris specific configuration

by Alexandre Julliard

Robert Lunnon <bobl(a)optushome.com.au> writes: > Changelog > Autodetection of XFREE86 as required for Solaris. This should be done in configure, assuming it is really necessary. Why can't we use the standard Xlib? -- Alexandre Julliard julliard(a)winehq.com

Jan. 14, 2004

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine

by Eric Pouech

Dimitrie O. Paun a e'crit : > On January 14, 2004 01:05 am, Dmitry Timoshkov wrote: > >>I don't mind either, but if the new iccvid code will be placed under >>dlls/ then dlls/msvideo/msrle32 should be moved there as well. > > > I'd much rather move msrle32 to dlls/, then create new DLLs > deep inside the dir hierarchy. Ideally we should have all > DLLs just under dlls/, let's not make the problem worse. > I still don't see the point of having a unique dlls/ flat structure. Which more than 100 dlls right now, I do think we need to structure it. So putting the video codec in msvideo directory seems the easiest structure. We could also envisage to have a drivers or codecs directory, but that'll boil down to the same thing. A+

Jan. 14, 2004

strange warning message when buildint current cvs

by Ivan Leo Murray-Smith

With current cvs, I get this strange warning message make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' cp ../../dlls/advapi32/tests/advapi32_test.exe.so advapi32_test.exe.so && strip -s advapi32_test.exe.so cp ../../dlls/gdi/tests/gdi32_test.exe.so gdi32_test.exe.so && strip -s gdi32_test.exe.so cp ../../dlls/kernel/tests/kernel32_test.exe.so kernel32_test.exe.so && strip -s kernel32_test.exe.so cp ../../dlls/ntdll/tests/ntdll_test.exe.so ntdll_test.exe.so && strip -s ntdll_test.exe.so cp ../../dlls/user/tests/user32_test.exe.so user32_test.exe.so && strip -s user32_test.exe.so cp ../../dlls/winmm/tests/winmm_test.exe.so winmm_test.exe.so && strip -s winmm_test.exe.so cp ../../dlls/winspool/tests/winspool.drv_test.exe.so winspool.drv_test.exe.so && strip -s winspool.drv_test.exe.so LD_LIBRARY_PATH="../../libs/unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -fowinetest.res winetest.rc ../../tools/winebuild/winebuild -D_REENTRANT -fPIC -o winetest.exe.spec.c --exe winetest.exe --exe-mode gui winetest.res main.o send.o util.o winetest.exe.dbg.o -L../../dlls -luser32 -lwsock32 gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c {standard input}: Assembler messages: {standard input}:856275: Warning: .stabs: description field '1a385' too big, try a different debug format {standard input}:856278: Warning: .stabs: description field '1a38c' too big, try a different debug format {standard input}:856281: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856287: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856291: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856299: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856302: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856305: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856308: Warning: .stabn: description field '1a390' too big, try a different debug format {standard input}:856316: Warning: .stabn: description field '1a393' too big, try a different debug format {standard input}:856321: Warning: .stabn: description field '1a397' too big, try a different debug format {standard input}:856324: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856331: Warning: .stabn: description field '1a391' too big, try a different debug format {standard input}:856344: Warning: .stabn: description field '1a392' too big, try a different debug format {standard input}:856349: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856357: Warning: .stabn: description field '1a39a' too big, try a different debug format {standard input}:856378: Warning: .stabn: description field '1a39b' too big, try a different debug format {standard input}:856383: Warning: .stabn: description field '1a39c' too big, try a different debug format {standard input}:856389: Warning: .stabn: description field '1a39d' too big, try a different debug format {standard input}:856401: Warning: .stabn: description field '1a39e' too big, try a different debug format {standard input}:856413: Warning: .stabn: description field '1a39f' too big, try a different debug format {standard input}:856416: Warning: .stabn: description field '1a3a0' too big, try a different debug format {standard input}:856420: Warning: .stabn: description field '1a3a1' too big, try a different debug format {standard input}:856428: Warning: .stabn: description field '1a394' too big, try a different debug format {standard input}:856442: Warning: .stabs: description field '1a38d' too big, try a different debug format {standard input}:856443: Warning: .stabs: description field '1a38e' too big, try a different debug format {standard input}:856444: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856445: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856446: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856509: Warning: .stabs: description field '1a3f3' too big, try a different debug format {standard input}:856513: Warning: .stabn: description field '1a3f3' too big, try a different debug format {standard input}:856522: Warning: .stabn: description field '1a3f5' too big, try a different debug format {standard input}:856530: Warning: .stabn: description field '1a3f6' too big, try a different debug format {standard input}:856548: Warning: .stabs: description field '1168a' too big, try a different debug format {standard input}:856549: Warning: .stabs: description field '12078' too big, try a different debug format {standard input}:856550: Warning: .stabs: description field '12fff' too big, try a different debug format {standard input}:856551: Warning: .stabs: description field '13f10' too big, try a different debug format {standard input}:856552: Warning: .stabs: description field '148d9' too big, try a different debug format {standard input}:856553: Warning: .stabs: description field '17277' too big, try a different debug format {standard input}:856554: Warning: .stabs: description field '181cf' too big, try a different debug format {standard input}:856555: Warning: .stabs: description field '18d39' too big, try a different debug format {standard input}:856556: Warning: .stabs: description field '19709' too big, try a different debug format {standard input}:856557: Warning: .stabs: description field '1a290' too big, try a different debug format {standard input}:856558: Warning: .stabs: description field '1a2a8' too big, try a different debug format {standard input}:856559: Warning: .stabs: description field '1a2f2' too big, try a different debug format {standard input}:856560: Warning: .stabs: description field '1a3cf' too big, try a different debug format gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winetest.exe.spec.o main.o send.o util.o winetest.exe.dbg.o -o winetest.exe.so -L../../libs/wine -lwine -L../../libs/port -lwine_port -lm -lc make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs' make[1]: Entering directory `/home/ivan/Development/Wine/CVS/wine/server' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/server' Wine build complete. I've tried make distclean and I still get it. I'm using gcc 3.3.1-2mdk, does this classify as something that should be fixed? Ivan.

Jan. 14, 2004

Shell32 Patch 1.1

by Steven Edwards

This patch replaces the prior patch. The ReactOS changelog wasnt very good and Martin pointed out that I missed the spec file. Changelog: "Martin Fuchs" <martin-fuchs(a)gmx.net> Implement RestartDialog and RestartDialogEx __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 14, 2004

Re: More Vacation backlog

by Hans Leidekker

On Tuesday 13 January 2004 23:57, Uwe Bonnes wrote: > +HANDLE DEVICE_Open( LPCWSTR filenameW, DWORD access, DWORD attributes, LPSECURITY_ATTRIBUTES sa ) > { > const struct VxDInfo *info; > char filename[MAX_PATH]; > @@ -283,7 +283,7 @@ > > for (info = VxDList; info->name; info++) > if (!strncasecmp( info->name, filename, strlen(info->name) )) > - return FILE_CreateDevice( info->id | 0x10000, access, sa ); > + return FILE_CreateDevice( info->id | 0x10000, access, access, sa ); ^^^^^^ I think you want to pass 'attributes' here, right? -Hans

Jan. 14, 2004

Re: slight trouble running winetests under windows

by Dimitrie O. Paun

On January 13, 2004 08:06 pm, Alexandre Julliard wrote: > The main problem is that winegcc only knows about gcc, and we want > Wine to build with other compilers too. So no, we can't use it yet. Good point. Situation is not too bad though. Wine source is not gcc specific, so we can invoke whatever compiler ./configure detected. It's true, we're currently passing -fshort-wchar and -fPIC which are gcc specific, but we cat easily test for these things in ./configure, and add them only if the compiler supports them. To summarize, here are the gcc-specific dependencies that I see: winegcc -fshort-wchar -fPIC winewrap -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini -shared -fPIC It is easy to just use what ./configure figures out instead. I know, if we do that winegcc will be forced to use the same compiler that was used to build Wine. It's a bummer, but also kinda theoretical problem for now, as all binaries are build with gcc. I think we can worry about this issue when it does become a real problem. -- Dimi.

Jan. 14, 2004