wine-devel February 2007

wine-devel@winehq.org

130 participants
279 discussions

kernel32 (profile.c): allow profile section and key names of zero length patch
by Claudio Fontana 18 Feb '07

18 Feb '07

Hello all, I was wondering if there's anything wrong with my patch to kernel32/profile.c and its tests: http://www.winehq.org/pipermail/wine-patches/2007-February/035468.html It fixes a problem that causes applications built with Multimedia Fusion to fail under wine, since the "INI object" of MF relies on zero length section and key names to store and retrieve values. The changes in tests/profile.c contain new testcases, and a generally useful fix to the tests, where some values are currently passed directly to the functions instead of using the values in the testcases table. If there's anything unclear or wrong about this patch, please tell me so that I will be able to fix it. Thanks, Claudio

1 0

Re: lostwages/ news/2006081001.xml news/2007021602 ...
by Francois Gouget 18 Feb '07

18 Feb '07

On Fri, 16 Feb 2007, WineHQ wrote: > ChangeSet ID: 30931 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: wineowner(a)winehq.org 2007/02/16 18:13:29 Could we get rid of wineowner account? It makes it impossible to know who's doing the changes. Each user having access to the WineHQ box should have his own login. Welcome back Brian (if I read the wwn right). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 1

Re: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627
by Detlef Riekenberg 18 Feb '07

18 Feb '07

On Sa, 2007-02-17 at 13:32 -0800, Dan Kegel wrote: > +++ b/tools/wine.inf > @@ -2149,6 +2149,7 @@ HKLM,%CurrentVersion%\Telephony\Country > > [FakeDllsSection] > +10,..\Program Files\Windows NT\Accessories,wordpad.exe > +++ b/tools/wineprefixcreate.in > + "$CROOT/Program Files" \ > + "$CROOT/Program Files/Windows NT" \ > + "$CROOT/Program Files/Windows NT/Accessories" The Idea sounds good, but your Patch is wrong for every system in the World, that does not use English as locale: My XP has wordpad.exe here: "C:\Programme\Windows NT\Zubehör\wordpad.exe" -- By by ... Detlef

1 0

Re: Error in ntdll/module.c?
by Rolf Kalbermatter 18 Feb '07

18 Feb '07

Christian Iversen [mailto:chrivers@iversen-net.dk] wrote: >According to: > >http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/ >Executable%20Images/LdrGetProcedureAddress.html > >The parameter order for LdrGetProcedureAddress is (Handle, Function, >Ordinal, Address) > >The file dlls/ntdll/module.c has the order as (Handle, Ordinal, >Function, Address) Ok. I took a look at the call sequence of this function in a native kernel32.dll and the second parameter is initialized with RtlInitString. So I guess the parameter order as on that web site would be correct. Having looked at the particular assembly code obviously excludes me from doing any work on this part anymore. As to the current implemenation I'm not sure that makes any difference since most undocumented APIs are unlikely to be used by applications. And since ntdll and kernel32 are both also Wine specific and therefore can't be replaced by Windows ones this won't matter either it would seem. You can try to post a proper patch to both kernel32 and ntdll to wine-patches and then let Alexandre decide if he wants to apply it. Rolf Kalbermatter

2 1

Error in ntdll/module.c?
by Christian Iversen 18 Feb '07

18 Feb '07

(Please CC me, I'm not on the list) According to: http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Execu… The parameter order for LdrGetProcedureAddress is (Handle, Function, Ordinal, Address) The file dlls/ntdll/module.c has the order as (Handle, Ordinal, Function, Address) This of course works well because kernel32.dll is the only caller (and it indeed uses, if not the correct, then at least the same order). I haven't attached a patch, because I'm not actually sure which version is right. Anyone? -- Mvh Christian Iversen

2 1

Re: patches and more
by Robert Shearman 18 Feb '07

18 Feb '07

David Saez Padros wrote: > This line should be added to commctrl.h: > > #define ListView_GetOrigin(hwndLV, ppt) \ > (BOOL)SNDMSG((hwndLV), LVM_GETORIGIN, (WPARAM)0, (LPARAM)ppt) I've submitted a patch for this. > this one should be added to windows.h (maybe it's not the best > place for it, but it works): > > #define stricmp strcasecmp This define is not present in the Platform SDK. It is a by-product of using glibc instead of msvcrt as your C library. If you used the headers in include/msvcrt and added -lmsvcrt to the linker command line then it should have worked out of the box. If you want to link against glibc, then think of changing stricmp to strcasecmp as part of porting the program. -- Rob Shearman

2 1

Font issue - workaround found
by Timm 18 Feb '07

18 Feb '07

My one win app that makes me a devotee of WINE is TablEdit (demo at www.tabledit.com/download/tabled32.exe) has a custom font , tef260.ttf, that has failed to display since somewhere after ver 9.6. The program installs the font into c:\windows\font, but can not display it within the program, instead displaying for the most part, empty squares. I tried putting/removing tef260.ttf into /usr/local/share/wine/fonts, /usr/local/share/fonts, and the wine windows/fonts directories in all permutations. The only way I got it to display was to remove ALL fonts from these three directories and install tef260.ttf into an X11 font directory along with other win ttf fonts. This forces WINE to build a cachedmetrics file like it used to, and the font is displayed properly in the program. Hope this is a clue for some developer, as I merely lurk here, looking for clues about wine behavior. I can't do a regression back to ver 9.6 (the version I was using that last worked) because my upgrades to freetype cause it to complain of missing functions. current (pertinent ? ) specs libfreetype.so.6.3.7 ] built from source libfontconfig.so.1.0.4 ] built from source fontforge 20060715 ] built from source WINE 0.9.20 ] built from source kernel 2.6.17.11 Slack current (10.2, with upgrades from "current" tree) -- Timm

3 2

re: generic.ppd does not appear in the build dir - cannot print
by Dan Kegel 18 Feb '07

18 Feb '07

> [I keep my source and object in different directories, and generic.ppd isn't found during build] That method of building is great, and is supported, but not too many people build that way, so bugs do creep in. You can either keep living with the workaround you found, or submit a patch to fix the build. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

32 bpp cursors?
by Dan Kegel 17 Feb '07

17 Feb '07

http://bugs.winehq.org/show_bug.cgi?id=4273 points to a patch set that implements 32 bit per pixel cursors and a bunch of other cursor stuff. Looks like the patch got dropped by the author, though, and since it makes server changes, it's going to be hard to get past Alexandre. Is anyone interested in picking this up? - Dan

4 5

Re: comctl32: rebar: New conformance test for CCS_NORESIZE style.[PATCH 1/2]
by Dmitry Timoshkov 17 Feb '07

17 Feb '07

"Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > +/* MSDN 672579: "CCS_NORESIZE: Prevents the control from using the default width and height when setting its > + * initial size or a new size. Instead, the control uses the width and height specified in the request for > + * creation or sizing." This test checks both creation and sizing dimensions. */ You can't quote MSDN in the Wine code, but you can explain the problem using your own wording. -- Dmitry.

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
28
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 February 2007