June 2006 - Wine-Devel - list.winehq.org

Re: riched20: EM_GETLINE implementation and test

by Marcus Meissner

On Thu, Jun 22, 2006 at 10:36:10PM +0100, Andrew Talbot wrote: > James Hawkins wrote: > > Probably, L"" is not portable, and you have to use: > > > > static const WHCAR string[] = {'s','t','r','i','n','g',0}; > > > I'm just curious: not arguing, ;) but Plauger says, in "The Standard C > Library" (1992, p. 219): "You write a wide character constant as, for > example, L'x'. It has type wchar_t. You write a wide characer string > literal as, for example, L"hello". It has type array of wchar_t. wchar_t is > an integer type that can represent all the code values for all > wide-character encodings supported by the implementation." Why might it not > be portable? In Linux, L"" makes 4 byte character strings (if not using explicit -fshort-wchar). Also, if the user then calls wc* functions from glibc, they will use 4 byte characters. It is all to avoid confusion. Ciao, Marcus

June 23, 2006

Re: riched20: EM_GETLINE implementation and test

by Andrew Talbot

James Hawkins wrote: > To be as portable as possible, we code to the lowest common > denominator. Not all compilers support L"". We adhere to C89, but I > can't remember what it says about L"", if anything. The point is that > WCHAR blah[] ={...} will work for every compiler. > >From what I can tell, L"" is good in C89 (although the result of concatenating a wide string and a narrow string is undefined). However, the width of wchar_t is implementation-dependent, and may have a width anywhere between that of char and unsigned long (though, in practice, it is likely to be a synonym for an integer type that has at least a 16-bit representation, such as short or unsigned short). Whereas WCHAR is set to have a width of sixteen bits. So I think this is why the L-prefix form is not portable. Thanks for helping me down this road of discovery. -- Andy.

June 22, 2006

Re: Move all common Dll[un]RegisterServer stuff to advapi

by James Hawkins

On 6/22/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Ok, no problem. > we can add delay import for advapi32. (guessing) > As most of the implemented functions use the same code, for > implementing those functions. > So I thought moving them to a common location would be a good idea. > Do you know where should i move the common implementation to? > The imports for current dlls concerning advapi32 are fine; no need to change to delay import. I understand where you're going with moving factoring out registration, it's just that advapi32 is not the place. I'm not sure where else you could put this. I would ask Alexandre whether he wants it done at all, and if so, where the new code should be located. -- James Hawkins

June 22, 2006

Re: riched20: EM_GETLINE implementation and test

by Kari Hurtta

"James Hawkins" <truiken(a)gmail.com> writes in gmane.comp.emulators.wine.devel: > On 6/22/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > > James Hawkins wrote: > > > Probably, L"" is not portable, and you have to use: > > > > > > static const WHCAR string[] = {'s','t','r','i','n','g',0}; > > > > > I'm just curious: not arguing, ;) but Plauger says, in "The Standard C > > Library" (1992, p. 219): "You write a wide character constant as, for > > example, L'x'. It has type wchar_t. You write a wide characer string > > literal as, for example, L"hello". It has type array of wchar_t. wchar_t is > > an integer type that can represent all the code values for all > > wide-character encodings supported by the implementation." Why might it not > > be portable? > > > > To be as portable as possible, we code to the lowest common > denominator. Not all compilers support L"". We adhere to C89, but I > can't remember what it says about L"", if anything. The point is that > WCHAR blah[] ={...} will work for every compiler. Well, perhaps you then need also special options if you use L"..." man gcc: -fshort-wchar Override the underlying type for wchar_t to be short unsigned int instead of the default for the target. This option is useful for building programs to run under WINE. / Kari Hurtta

June 22, 2006

Re: Move all common Dll[un]RegisterServer stuff to advapi

by Vijay Kiran Kamuju

Ok, no problem. we can add delay import for advapi32. (guessing) As most of the implemented functions use the same code, for implementing those functions. So I thought moving them to a common location would be a good idea. Do you know where should i move the common implementation to? Thanks, Vijay PS: I am now going home, will discuss on IRC On 6/22/06, James Hawkins <truiken(a)gmail.com> wrote: > On 6/22/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > Most of the dlls which have implemented the above functions > > are importing advapi, because all/most of the Reg*Key functions are > > implemented in advapi > > > > I think this makes no difference to the existing dlls. > > > > You misunderstood what I said. There's nothing wrong with a dll > importing advapi32 exports. What you want to do would require > *adding* an export to advapi32 that is not in native advapi32, which > is wrong. > > -- > James Hawkins >

June 22, 2006

Re: Move all common Dll[un]RegisterServer stuff to advapi

by James Hawkins

On 6/22/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Most of the dlls which have implemented the above functions > are importing advapi, because all/most of the Reg*Key functions are > implemented in advapi > > I think this makes no difference to the existing dlls. > You misunderstood what I said. There's nothing wrong with a dll importing advapi32 exports. What you want to do would require *adding* an export to advapi32 that is not in native advapi32, which is wrong. -- James Hawkins

June 22, 2006

Re: riched20: EM_GETLINE implementation and test

by James Hawkins

On 6/22/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > James Hawkins wrote: > > Probably, L"" is not portable, and you have to use: > > > > static const WHCAR string[] = {'s','t','r','i','n','g',0}; > > > I'm just curious: not arguing, ;) but Plauger says, in "The Standard C > Library" (1992, p. 219): "You write a wide character constant as, for > example, L'x'. It has type wchar_t. You write a wide characer string > literal as, for example, L"hello". It has type array of wchar_t. wchar_t is > an integer type that can represent all the code values for all > wide-character encodings supported by the implementation." Why might it not > be portable? > To be as portable as possible, we code to the lowest common denominator. Not all compilers support L"". We adhere to C89, but I can't remember what it says about L"", if anything. The point is that WCHAR blah[] ={...} will work for every compiler. -- James Hawkins

June 22, 2006

Re: Move all common Dll[un]RegisterServer stuff to advapi

by Vijay Kiran Kamuju

Most of the dlls which have implemented the above functions are importing advapi, because all/most of the Reg*Key functions are implemented in advapi I think this makes no difference to the existing dlls. Thanks, Vijay On 6/22/06, James Hawkins <truiken(a)gmail.com> wrote: > On 6/22/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > Hi All, > > > > I would like to move all the helper functions register_coclass,etc to > > a separate file in advapi.dll called regsvr_helper.c and all > > declarations of structs, consts moved to a separate file called, > > wineregsvr.h in include/wine > > > > So that it would be easy for other dlls to implement the > > DllRegisterServer and DllUnRegisterServer. > > And also clean up the code base. > > > > I need your suggestions, before i submit patches. > > > > That would require at least one extra import from advapi32, which is > not a good idea. We're trying to separate connections between dlls > and extra exports, not create new ones. > > -- > James Hawkins >

June 22, 2006

Re: Move all common Dll[un]RegisterServer stuff to advapi

by James Hawkins

On 6/22/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi All, > > I would like to move all the helper functions register_coclass,etc to > a separate file in advapi.dll called regsvr_helper.c and all > declarations of structs, consts moved to a separate file called, > wineregsvr.h in include/wine > > So that it would be easy for other dlls to implement the > DllRegisterServer and DllUnRegisterServer. > And also clean up the code base. > > I need your suggestions, before i submit patches. > That would require at least one extra import from advapi32, which is not a good idea. We're trying to separate connections between dlls and extra exports, not create new ones. -- James Hawkins

June 22, 2006

Re: riched20: EM_GETLINE implementation and test

by Andrew Talbot

James Hawkins wrote: > Probably, L"" is not portable, and you have to use: > > static const WHCAR string[] = {'s','t','r','i','n','g',0}; > I'm just curious: not arguing, ;) but Plauger says, in "The Standard C Library" (1992, p. 219): "You write a wide character constant as, for example, L'x'. It has type wchar_t. You write a wide characer string literal as, for example, L"hello". It has type array of wchar_t. wchar_t is an integer type that can represent all the code values for all wide-character encodings supported by the implementation." Why might it not be portable? -- Andy.

June 22, 2006

Move all common Dll[un]RegisterServer stuff to advapi

by Vijay Kiran Kamuju

Hi All, I would like to move all the helper functions register_coclass,etc to a separate file in advapi.dll called regsvr_helper.c and all declarations of structs, consts moved to a separate file called, wineregsvr.h in include/wine So that it would be easy for other dlls to implement the DllRegisterServer and DllUnRegisterServer. And also clean up the code base. I need your suggestions, before i submit patches. Thanks, Vijay

June 22, 2006

Re: wine-1.0 goal: fix all reported msi and ole bugs?

by James Hawkins

On 6/22/06, Dan Kegel <dank(a)kegel.com> wrote: > I just looked, and there aren't *that* many msi and ole bugs > reported in bugzilla. > > Would it be unreasonable to set a goal of having > all msi and ole bugs fixed for wine-1.0 ? > Just to clarify that last statement, you mean all reported msi and ole bugs? My opinion is that this is a reasonable goal for 1.0, and a necessary goal at that. When we say, "1.0 is out!" new users should at least be able to try their software in wine, which requires the installers to work. At this point, at least with msi, fixing the bugs isn't requiring major infrastructure change, just changing the behavior of a certain feature (in most cases). -- James Hawkins

June 22, 2006

Re: riched20: (updated) EM_GETLINE implementation and test

by James Hawkins

On 6/22/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > This is the EM_GETLINE patch from Thomas Kho, updated to current git and > with L"" replaced by proper WCHAR array. > > Krzysztof > > ====================================================== > > Hi, > > The following patch implements EM_GETLINE. This feature was requested in > bug #4305 <http://bugs.winehq.org/show_bug.cgi?id=4305> and also > mentioned at > <http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/f89762653…> > > Regards, > > Thomas Kho > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 9a2b966..23538ab 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c ... > @@ -2016,6 +2016,62 @@ LRESULT WINAPI RichEditANSIWndProc(HWND > return nChars; > } > } > + case EM_GETLINE: > + { > + ME_DisplayItem *run; > + ME_String *strText; > + int nMaxChars = (int) *(WORD *) lParam; > + int nBPC = 1; /* bytes per character */ > + int nEndChars; > + char *dest = (char *) lParam; > + > + TRACE("EM_GETLINE: row=%d, nMaxChars=%d (%s)\n", (int) wParam, nMaxChars, > + IsWindowUnicode(hWnd) ? "Unicode" : "Ansi"); > + A case this long should be moved into its own function and called from case EM_GETLINE. In fact, most of these should probably be factored into separated functions to reduce clutter. As it stands, RichEditANSIWndProc is a 1048 line function...yikes. -- James Hawkins

June 22, 2006

wine-1.0 goal: fix all reported msi and ole bugs?

by Dan Kegel

I just looked, and there aren't *that* many msi and ole bugs reported in bugzilla. http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-ole&keywords… lists 37 ole bugs with downloadable demos http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-ole&bug_stat… lists 89 ole bugs total http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&keywords… lists 35 msi bugs with downloadable demos http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&bug_stat… lists 71 msi bugs total Would it be unreasonable to set a goal of having all msi and ole bugs fixed for wine-1.0 ?

June 22, 2006

Re: riched20: EM_GETLINE implementation and test

by James Hawkins

On 6/22/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > This patch seems to have been overlooked or rejected - yet I do not see > any reason being mentioned. > > Was it rejected because of use of L"" syntax? > Probably, L"" is not portable, and you have to use: static const WHCAR string[] = {'s','t','r','i','n','g',0}; -- James Hawkins

June 22, 2006

Re: OleView: Added CreateInstanceOn functionality

by James Hawkins

On 6/22/06, Piotr Caban <piotr.caban(a)gmail.com> wrote: > Hi, > > Changelog: > - Added CreateInstanceOn functionality > Make sure you label a series of patches as OleView [1/x] etc. where x is the total number of patches, so if they are received out of order, Alexandre knows what order to apply them in. -- James Hawkins

June 22, 2006

Re: msi: Load all components, not just components associated with a feature

by James Hawkins

On 6/21/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > This fixes bug 3590. > > Changelog: > * Load all components, not just components associated with a feature. > Ignore this patch, it's not correct. -- James Hawkins

June 22, 2006

Re: [SETUPAPI] SetupDiCreateDeviceInfoA stub

by Christian Gmeiner

On Thursday 22 June 2006 17:50, Detlef Riekenberg wrote: > Hi Christian Gmeiner: > > It seems that there > > is no SetupDiCreateDeviceInfoW exporteded by setupapi.dll on windows > > SetupDiCreateDeviceInfoW is exported: > http://support.microsoft.com/dllhelp/?dlltype=file&l=55&S=1&alpha=setupapi. >dll > > > Example Version: > http://support.microsoft.com/dllhelp/?fid=91484&l=55&det=1 > > > $ winedump dump -j export setupapi* | grep SetupDiCreate > 00023DFE 299 SetupDiCreateDevRegKeyA > 00001C0F 300 SetupDiCreateDevRegKeyW > 000173E8 301 SetupDiCreateDeviceInfoA > 000015A7 302 SetupDiCreateDeviceInfoList > 000170D1 303 SetupDiCreateDeviceInfoListExA > 000048E5 304 SetupDiCreateDeviceInfoListExW > 0001746F 305 SetupDiCreateDeviceInfoW > 00018A9F 306 SetupDiCreateDeviceInterfaceA > 0002471C 307 SetupDiCreateDeviceInterfaceRegKeyA > 00001CCE 308 SetupDiCreateDeviceInterfaceRegKeyW > 00018B03 309 SetupDiCreateDeviceInterfaceW Okay,,, will add it in a second patch... Greets, Christian -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net Wanna listen to good music? - http://www.purevolume.com/sinceyouaredead

June 22, 2006

Re: [SETUPAPI] SetupDiCreateDeviceInfoA stub

by Detlef Riekenberg

Hi Christian Gmeiner: > It seems that there > is no SetupDiCreateDeviceInfoW exporteded by setupapi.dll on windows SetupDiCreateDeviceInfoW is exported: http://support.microsoft.com/dllhelp/?dlltype=file&l=55&S=1&alpha=setupapi.… Example Version: http://support.microsoft.com/dllhelp/?fid=91484&l=55&det=1 $ winedump dump -j export setupapi* | grep SetupDiCreate 00023DFE 299 SetupDiCreateDevRegKeyA 00001C0F 300 SetupDiCreateDevRegKeyW 000173E8 301 SetupDiCreateDeviceInfoA 000015A7 302 SetupDiCreateDeviceInfoList 000170D1 303 SetupDiCreateDeviceInfoListExA 000048E5 304 SetupDiCreateDeviceInfoListExW 0001746F 305 SetupDiCreateDeviceInfoW 00018A9F 306 SetupDiCreateDeviceInterfaceA 0002471C 307 SetupDiCreateDeviceInterfaceRegKeyA 00001CCE 308 SetupDiCreateDeviceInterfaceRegKeyW 00018B03 309 SetupDiCreateDeviceInterfaceW -- By By ... ... Detlef

June 22, 2006

Re: Wine developers?

by Molle Bestefich

Jonathan Clark wrote: > Judging by the two negative reactions Based on the expressive smiley in my posting, I'd hardly consider it negative. It was more of a well-meaning joke, but perhaps also one that told how your posting could be interpreted. I *would* find it interesting to know how much inspiration you guys find in the Wine codebase, though. Have you thought about collaborating with the Wine project instead of hiring people from it? Since Thinstall versus the Wine project are not exactly targeting the same markets, collaboration on API development could be fruitful for both parties. (Oh, and I'm not exactly a Wine developer either, so no reason to take my comments too seriously.)

June 22, 2006

Re: OleView: Removed use of strlenW, strcmpW and strcpyW functions

by Jacek Caban

Hi, Piotr Caban wrote: > Hi, > > Changelog: > - Removed use of strlenW, strcmpW, strcpyW functions > > programs/oleview/details.c | 14 +++++++------- > programs/oleview/tree.c | 16 ++++++++-------- > 2 files changed, 15 insertions(+), 15 deletions(-) > > -- > Piotr > You should also remove include wine/unicode.h. Jacek

June 22, 2006

Re: forgotten patch

by Phil Krylov

On 22/06/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > > This patch apparently has been lost, and there's at least one bug in > Bugzilla that the patch seems to fix (bug# 4452, checked here). > > http://www.winehq.org/pipermail/wine-patches/2006-January/023875.html > > I don't see anything wrong with the patch, did Phil just send it in a > wrong moment, or is there anything to fix? Alexandre said that it should check for other invalid hWnd values as well. I had no time to improve it since that day ;(( -- Ph.

June 22, 2006

Re: oleview: Link with wine's unicode libarary

by James Hawkins

On 6/21/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > oleview: Link with wine's unicode libarary. > We should be changing the strlenW to lstrlenW, not adding $(LIBUNICODE) to the Makefile. -- James Hawkins

June 22, 2006

Re: Oleview: undefined references

by James Hawkins

On 6/21/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Excellent. Thanks, Mike. > > I shall submit a patch to add $(LIBUNICODE) to the EXTRALIBS line. > I personally think we should change the strlenW to lstrlenW. lstrlenW is win32, and doesn't require $(LIBUNICODE). Plus, we use it pretty much everywhere in the tree. -- James Hawkins

June 22, 2006

Re: Oleview: undefined references

by Andrew Talbot

Excellent. Thanks, Mike. I shall submit a patch to add $(LIBUNICODE) to the EXTRALIBS line. -- Andy.

June 22, 2006

Re: Oleview: undefined references

by Mike McCormack

Andrew Talbot wrote: > Sorry, yes: compilation breaks if the -Wwrite-strings flag is specified. If you configure with: CFLAGS="-Wwrite-strings" ./configure the configure script will not add -O2, which means inline function won't be inlined. The problem seems to be that oleview isn't linked with -llibwineunicode. Using lstrlenW() instead of strlenW() or adding $(LIBUNICODE) to Makefile.in should fix that. eg. EXTRALIBS = -luuid $(LIBUNICODE) Or you can just add -O2 yourself: CFLAGS="-Wwrite-strings -O2" ./configure Mike

June 22, 2006

Re: Wine developers?

by Vitaliy Margolen

Wednesday, June 21, 2006, 11:41:32 AM, Andreas Mohr wrote: > Hi, > On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: >> I wouldn't necessarily judge the whole list by just two negative >> reactions. It's interesting to see that with my wine experience there >> might be jobs out there working on something similar. (Not that I'm >> interested right now, I'm still at university...) >> >> I'm sure you're aware that in every open source project, there's people >> who oppose commercial software development for philosophical reasons. > "proprietary" please, not "commercial". HUGE difference. I was talking more about nature of the job. I'm sure that lots of Wine code can "leak" into commercial product and wise versa. > As for those people even opposing commercial development: go wherever > I don't need to see you ;) There are such people? If so, my guess would be 99.99% of them never wrote a line of code. Vitaliy

June 22, 2006

Re: Oleview: undefined references

by Andrew Talbot

James Hawkins wrote: > I'm guessing you mean -Wwrite-strings. I don't know the answer to the > question, but we should probably be using lstrlenW instead. > Sorry, yes: compilation breaks if the -Wwrite-strings flag is specified. Thanks, -- Andy.

June 21, 2006

Re: Oleview: undefined references

by James Hawkins

On 6/21/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Does anyone know why details.c and tree.c might have undefined references to > the unicode string functions, such as strlenW()? > > My guess is that there might be something wrong with the Makefile.in. > Compilation breaks if the -Write-strings flag is specified. > I'm guessing you mean -Wwrite-strings. I don't know the answer to the question, but we should probably be using lstrlenW instead. -- James Hawkins

June 21, 2006

Oleview: undefined references

by Andrew Talbot

Does anyone know why details.c and tree.c might have undefined references to the unicode string functions, such as strlenW()? My guess is that there might be something wrong with the Makefile.in. Compilation breaks if the -Write-strings flag is specified. Thanks, -- Andy.

June 21, 2006

forgotten patch

by Krzysztof Foltman

This patch apparently has been lost, and there's at least one bug in Bugzilla that the patch seems to fix (bug# 4452, checked here). http://www.winehq.org/pipermail/wine-patches/2006-January/023875.html I don't see anything wrong with the patch, did Phil just send it in a wrong moment, or is there anything to fix? Krzysztof

June 21, 2006

Re: WineD3D: VBO patch 3/3

by Stefan Dösinger

Am Mittwoch 21 Juni 2006 15:05 schrieb Stefan Dösinger: > This patch finally adds code for creating VBOs. > > ChangeLog: > Stefan Dösinger(for CodeWeavers): Create vertex buffer objects for D3D > vertex buffers Do not apply that patch yet. It is missing some GL constant definitions(GL_STREAM_DRAW, GL_STATIC_COPY, ...) I will send an updated patch tomorrow

June 21, 2006

Re: Win64 status

by Kuba Ober

> As for the documentation I can recommend > - http://blogs.msdn.com/freik/archive/category/12430.aspx > - MSDN > - the PE-COFF v8 document recently updated by MS > (http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx) > - the ABI document that comes with some MSVC versions Thank you for the pointers, and thanks to H. Verbeet for the link as well! That looks like some fun reading :/ Anyway, it seems easier than porting gcc to a new architecture from scratch ;) Cheers, Kuba

June 21, 2006

Re: Win64 status

by Filip Navara

----- PŮVODNÍ ZPRÁVA ----- Od: "Kuba Ober" <kuba(a)mareimbrium.org> Komu: wine-devel(a)winehq.org Předmět: Re: Win64 status Datum: 21.6.2006 - 13:01:23 > On Wednesday 21 June 2006 06:39, Filip Navara wrote: > > Hello guys, > > > > I'm about to jump in the middle of discussion. The > > problem is not only > > > with the calling convention, but with the whole ABI > > rather. I've had > > > GCC patched to use the MSVC x64 calling convention > > (without a switch > > > though) for about a year now, but it doesn't solve > > the problem. There > > > is much more ABI differences including the exception > > handling (and yes, > > > I mean exception handling in C, not only C++) where > > MSVC generates special > > > unwinding information for the functions. I'm not > > sure if it would be > > > even possible to mix the ABI this way, but I'm open > > to hear some > > > suggestions. > I started uploading the diffs to www.volny.cz/xnavara/mingw64/, but it's kind of hard to rescue it since I have nothing to diff against since the MinGW64 CVS is down and it takes quite a while to find the right revision of files... > Does gcc have some C exception handling of its own? > If not then we may be able > to add that. gcc is pretty well tweakable, although > it takes a lot of time to > figure things out for the first time. No, it doesn't. > If you'd have any more pointers to specific information, > that would help me > out immensely. The diffs that you have would help me > out for sure. > > Is the MSVC x64 ABI documented somewhere? I didn't > have time to wade through > MSDN in search of that yet . . . As for the documentation I can recommend - http://blogs.msdn.com/freik/archive/category/12430.aspx - MSDN - the PE-COFF v8 document recently updated by MS (http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx) - the ABI document that comes with some MSVC versions Regards, Filip

June 21, 2006

Re: appdb redesign

by Chris Morgan

If you ignore the color changes there are still quite a few useful things we can improve. I think the coloring in the top-X list is neat. Putting icons next to the application would be really cool too. Both of those wouldn't require that we change the color theme from what we have but would improve the look of the page. Chris On Wednesday 21 June 2006 2:39 pm, Tony Lambregts wrote: > Evgeny Burzak wrote: > > take a new look at appdb. > > Suggestions, crtitical opinion, spell-checking, pizza, money, > > post-cards are welcome -__- > > > > Evgeny > > We have an overall theme that is consistent across all web sites. It > important that the all the wine websites have a common look an feel and I > don't think it is a good idea to throw that away. > > It took a long time to get to this point. Jonathan Ernst put a lot of work > getting the style sheets common for the main site, bugzilla and the AppDB. > I know that WineHQ and the Wiki are theme-able but that is not true for the > AppDB nor Bugzilla. I do not know how difficult it would be to change the > defaut theme for the wiki and the main site but I know that it would > require a fair amount of work to change over bugzilla. > > From my point of view I think that making the AppDB theme-able would be a > nice to have but unless we have the same default theme across all the > websites then I cannot suport this kind of change. > > -- > > Tony Lambregts

June 21, 2006

Re: APPDB patch - adminAppQueue.php

by Tony Lambregts

EA Durbin wrote: >> >> I'm going to look into the orphaned version issue right now but there >> may be >> others. >> > > What is the orphaned version issue? > When users submitted an new version of an application the appId was set to 0 instead of the proper number. Fixed by Chris with this patch http://cvs.winehq.org/patch.py?id=25914

June 21, 2006

Re: appdb redesign

by Tony Lambregts

Evgeny Burzak wrote: > take a new look at appdb. > Suggestions, crtitical opinion, spell-checking, pizza, money, > post-cards are welcome -__- > > Evgeny We have an overall theme that is consistent across all web sites. It important that the all the wine websites have a common look an feel and I don't think it is a good idea to throw that away. It took a long time to get to this point. Jonathan Ernst put a lot of work getting the style sheets common for the main site, bugzilla and the AppDB. I know that WineHQ and the Wiki are theme-able but that is not true for the AppDB nor Bugzilla. I do not know how difficult it would be to change the defaut theme for the wiki and the main site but I know that it would require a fair amount of work to change over bugzilla. From my point of view I think that making the AppDB theme-able would be a nice to have but unless we have the same default theme across all the websites then I cannot suport this kind of change. -- Tony Lambregts

June 21, 2006

Re[2]: appdb redesign

by Evgeny Burzak

in a while will make html page with suggestion for all developers. Then i think internal pages needed for reviews. Evgeny CM> It looks pretty cool man. I like moving the search up to the top of the page CM> because its width is pretty cramped on the left side. The coloring of the CM> top-X lists looks pretty neat as well with the icons there. CM> Was your plan to post a suggestion or to follow it up with patches to start to CM> implement the changes on the site? CM> Chris CM> On Wednesday 21 June 2006 11:32 am, Evgeny Burzak wrote: >> take a new look at appdb. >> Suggestions, crtitical opinion, spell-checking, pizza, money, >> post-cards are welcome -__- >> >> Evgeny

June 21, 2006

Re: Wine developers?

by Andreas Mohr

Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: > I wouldn't necessarily judge the whole list by just two negative > reactions. It's interesting to see that with my wine experience there > might be jobs out there working on something similar. (Not that I'm > interested right now, I'm still at university...) > > I'm sure you're aware that in every open source project, there's people > who oppose commercial software development for philosophical reasons. "proprietary" please, not "commercial". HUGE difference. As for those people even opposing commercial development: go wherever I don't need to see you ;) > As for stealing developers, I think the terms of contract could make > sure that the developer is free to work on wine in his spare time, but > that's a thing for people interested in the job to take care of. Indeed. If the conditions are fine OSS-wise then I don't see a reason to complain. More offers is always a good thing :) Andreas Mohr

June 21, 2006

Re: Wine developers?

by Kai Blin

* Jonathan Clark <jclark(a)thinstall.com> [20/06/06, 23:35:26]: > > Judging by the two negative reactions, apparently I didn't follow protocol > for posting to the list and I want to apologize for that. I understand how > it can look from a different perspective. I checked with the #wine-hackers > channel first and those guys were very friendly. We had a great discussion > and when I mentioned we were looking for developers they suggested I post > here. > > Thanks for your time and consideration, I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. As for stealing developers, I think the terms of contract could make sure that the developer is free to work on wine in his spare time, but that's a thing for people interested in the job to take care of. The same people who proposed to post here will still back up that proposal, even if they don't speak up now. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Is a person who blows up banks an econoclast?

June 21, 2006

Re: appdb redesign

by Chris Morgan

It looks pretty cool man. I like moving the search up to the top of the page because its width is pretty cramped on the left side. The coloring of the top-X lists looks pretty neat as well with the icons there. Was your plan to post a suggestion or to follow it up with patches to start to implement the changes on the site? Chris On Wednesday 21 June 2006 11:32 am, Evgeny Burzak wrote: > take a new look at appdb. > Suggestions, crtitical opinion, spell-checking, pizza, money, > post-cards are welcome -__- > > Evgeny

June 21, 2006

Re: GetMessage: Return -1 if an invalid window handle has been passed

by James Hawkins

On 6/21/06, Michael Kaufmann <hallo(a)michael-kaufmann.ch> wrote: > Changelog: > GetMessage: Return -1 if an invalid window handle has been passed > A test case would be good. -- James Hawkins

June 21, 2006

Re: [ntdll patch] Patch dropped?

by Andrew Talbot

Reappearance noted with thanks. -- Andy.

June 21, 2006

appdb redesign

by Evgeny Burzak

take a new look at appdb. Suggestions, crtitical opinion, spell-checking, pizza, money, post-cards are welcome -__- Evgeny

June 21, 2006

Re: Resend: WineD3D: pixel format cleanup

by Stefan Dösinger

> It doesn't (last I checked)... neither does CreateVolume(). > This also requires a test to see what Windows does. > > Checking if a format is supported before > > > returning the gl config doesn't really make sense. If the format isn't > > supported and we ask gl for a compressed texture we will get an error > > returned and broken graphics(because we ignore gl errors generally). If > > we pass 0 instead for the gl format and internal format we will have > > broken graphics too but I don't think gl returns an error then(although > > I'd have to > > check the man page for that) > > I agree, but I thought the patch was a no-op :) Oh well, not a 100% no op then. But that is hard to nop with a constant table :-) Well, almost all cards support that extension, so it's a de-facto no-op

June 21, 2006

Re: Resend: WineD3D: pixel format cleanup

by Stefan Dösinger

Am Mittwoch 21 Juni 2006 15:21 schrieb Ivan Gyurdiev: > Stefan, can you clarify what happened to the GL_SUPPORT check for > compressed formats? The check wheter a pixelformat is actually supported will happen in IWineD3DImpl_CheckDeviceFormatand createsurface should call this function to verify wether a format is supported. Checking if a format is supported before returning the gl config doesn't really make sense. If the format isn't supported and we ask gl for a compressed texture we will get an error returned and broken graphics(because we ignore gl errors generally). If we pass 0 instead for the gl format and internal format we will have broken graphics too but I don't think gl returns an error then(although I'd have to check the man page for that) IWineD3DImpl_CheckDeviceFormat needs a fixup too, like whitelisting formats instead of blacklisting them. Stefan

June 21, 2006

Re: Resend: WineD3D: pixel format cleanup

by Ivan Gyurdiev

On 6/21/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > This is a resend of the patch from a few days ago with some modifications > requested by Alexandre: > > *getFormatDescEntry returns a pointer to a format structure, not an index > in > the array > > * Removed the format counter Stefan, can you clarify what happened to the GL_SUPPORT check for compressed formats?

June 21, 2006

Re: ntoskrnl followup

by Vitaliy Margolen

Tuesday, June 20, 2006, 5:39:26 AM, Frans Kool wrote: > Hi Vitaliy, > If I read the thread concerning ntoskrnl insertion into Wine correctly, the > patch will have to be divided into several parts to be accepted by AJ. That is not the main problem. It will have to be divided, but it would be few pieces. > For this, tests need probably be written to make sure each sub-patch is > performing as it should. I haven't written C-code for a while, but there are a > lot of tests available for me to have a crack at it. I'm not so sure how much can you test here. Under "tests" here we mean conformance tests that could be compiled as an exe and ran on native platforms. To test ntoskrnl you one would need kernel driver to test against. But this is not something that we can compile ourselves. It requires DDK. Also the only part that could be tested is ioctls, not the driver loading/unloading. > As I see it, the following tests/patches are needed (in this order?) > 1) Tests for talking to ntoskrnl through wineserver (setting up channel, testing > messages both correct and incorrect and closing channel again) in order to test > the new way of communication. This part can be a stand alone test, not a part of the test suite. It would be helpful of course but I'm not sure if it could be committed. > 2) Tests to try the ioctl structures I'm not sure what you mean here. There are lots of data types associated with predefined ioctls. But that's not what we need here. > 3) loading a device driver, talking to it, unloading it (including negatives > like unloading a non-loaded driver etc). This we can not really test with integrated tests. We need a driver and admin privileges. > 4) Open issues like detecting if the driver is actually loaded instead of > waiting X ms.... That's more of the design question. There are several ways how this could be done. It could be as simple as adding one more internal ioctl. > The questions I have are: > a) Is the breakdown correct, or are there more atomic parts (easier to test/get > into wine). Do you already have a breakdown idea of the patch into smaller parts > so I/we can focus on this? I would brake it down to the following pieces: 1. ioctls to the wineserver "devices" (named-pipe, mail-slot, etc). This is an atomic change. 2. Implementing ntoskrnl.exe. So far we have it as a separate program. It could be turned into a dll. 3. Other part of the ioctls (wineserver <-> ntoskrnl). 4. Pieces required to load/unload/query driver and processing ioctls. 5. Other pieces required for safedisc support (privileged instruction emulation, and process startup sequence). > d) Can I somehow access the most recent version of the patch? I have several > versions now, but they keep on changing/improving(!). It would be nice if you > could publish it somewhere (nightly CVS tarball?), so more people can provide > feedback on it too. I could make a current diff of what I have. But I don't really have time to make a daily snapshots. > As you can see, I'm just trying to see if I can contribute on such a big project. > Thanks for the feedback, Thank you for offering support in this area. I really do appreciate it. Vitaliy

June 21, 2006

Re: Win64 status

by H. Verbeet

On 21/06/06, Kuba Ober <kuba(a)mareimbrium.org> wrote: > Is the MSVC x64 ABI documented somewhere? I didn't have time to wade through > MSDN in search of that yet . . . http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_d/h… has some info.

June 21, 2006

Re: Win64 status

by Kuba Ober

On Wednesday 21 June 2006 06:39, Filip Navara wrote: > Hello guys, > > I'm about to jump in the middle of discussion. The problem is not only > with the calling convention, but with the whole ABI rather. I've had > GCC patched to use the MSVC x64 calling convention (without a switch > though) for about a year now, but it doesn't solve the problem. There > is much more ABI differences including the exception handling (and yes, > I mean exception handling in C, not only C++) where MSVC generates special > unwinding information for the functions. I'm not sure if it would be > even possible to mix the ABI this way, but I'm open to hear some > suggestions. Does gcc have some C exception handling of its own? If not then we may be able to add that. gcc is pretty well tweakable, although it takes a lot of time to figure things out for the first time. If you'd have any more pointers to specific information, that would help me out immensely. The diffs that you have would help me out for sure. Is the MSVC x64 ABI documented somewhere? I didn't have time to wade through MSDN in search of that yet . . . Kuba

June 21, 2006

Re: RE: Win64 status

by Filip Navara

Hello guys, I'm about to jump in the middle of discussion. The problem is not only with the calling convention, but with the whole ABI rather. I've had GCC patched to use the MSVC x64 calling convention (without a switch though) for about a year now, but it doesn't solve the problem. There is much more ABI differences including the exception handling (and yes, I mean exception handling in C, not only C++) where MSVC generates special unwinding information for the functions. I'm not sure if it would be even possible to mix the ABI this way, but I'm open to hear some suggestions. Regards, Filip P.S. I'll try to publish the .diffs for GCC/binutils somewhere, but it's really not of much use.

June 21, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Stefan Dösinger

Am Mittwoch 21 Juni 2006 10:41 schrieb Ulrich Dobramysl: > Vitaliy Margolen wrote: > > Tuesday, June 20, 2006, 11:27:04 AM, Peter Åstrand wrote: > >> On Mon, 19 Jun 2006, Wine Bugs wrote: > >>> vitaliy(a)kievinfo.com changed: > >>> > >>> What |Removed |Added > >>> ----------------------------------------------------------------------- > >>>----- Status|RESOLVED |CLOSED > >>> > >>> > >>> ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 > >>> ------- Again this is not a bug. There is nothing to fix because there > >>> is nothing that broke. > >> > >> I disagree. If IE doesn't run, it's a bug. I would actually say that > >> it's a major bug - IE is one the those core applications that users > >> expects to work. > > > > What would you say if I open a bug about "Windows doesn't work on Wine"? > > Or better yet, "Can not upgrade Wine to winxp". > > > >> You are incorrect about "there is nothing to fix": Perhaps the source > >> code is fine, but the documentation is certainly not. > >> http://appdb.winehq.org/appview.php?versionId=469 even says: > >> "(to be continued because then it still doesn\'t run because of ole > >> errors)" > > > > This is _not_ a documentation. If you are not happy with something on > > appDB ask app maintainers to change that. Of course suggestions are > > welcome to what do you want to see there. > > > >>> Anyone is welcome to write up instructions on what to override and > >>> place them in appDB. Bugzilla is not the right place for that. > >> > >> Why do you think Bugzilla cannot be used for tracking documentation > >> bugs? There is a "wine-documentation" component and a "WineHQ Apps > >> Database" component, if you think that wine-misc is totally wrong. > > > > Because that's exactly what appDB is for. > > > >> I would very much prefer is this bug could be left open until someone > >> has managed to figure out what needs to be overridden to actually *run* > >> IE. > > > > I explained in the bug and will repeat here. Wine does not run windows. > > Wine runs windows applications. That's the main goal. The ultimate goal > > is to run every windows application without using any native component. > > That way Wine will be 100% replacement to windows. If you install any > > part of windows (per m$) you have to have windows licence. > > > > I'm not saying that some one can not find a way to run ie on Wine. In > > fact I spent quite some time putting that "magic" list of overrides > > together. Now it's been removed because Wine has it's own replacement for > > ie whenever app needs that. > > If you are saying that Wine shouldn't actively try to support IE like > other Apps, I very much regret this. As a part time web developer I have > learned to hate IE very much, each and every bit of web code written has > to be tested with it and I always had to go and find a Windows machine > to do this. Supporting IE in Wine would help a lot of web developers to > migrate completely to Linux. Well, not really Internet Explorer on wine is not guaranted to render things like Internet Explorer on Windows. You can reduce the differences by using as much native dlls as possible(mshtml, shdocvw, dcom, ...), but there might still be differences. If you run IE with the builtin dlls you have pretty much a Mozilla Gecko based Browser with the gui of IE. Just run the Acid 2 test in msie with builtin mshtml and compare the output to the rendering on Windows and the rendering in Firefox. What I want to say is that one can't really use wine to see if pages render correctly in IE. However, I still think that IE should be installable and work with its native dlls(including mshtml and dcom), because it is helpful to check if a bug in another application is caused by shdocvw, mhtml and friends.

June 21, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Ulrich Dobramysl

Vitaliy Margolen wrote: > Tuesday, June 20, 2006, 11:27:04 AM, Peter Åstrand wrote: >> On Mon, 19 Jun 2006, Wine Bugs wrote: > >>> vitaliy(a)kievinfo.com changed: >>> >>> What |Removed |Added >>> ---------------------------------------------------------------------------- >>> Status|RESOLVED |CLOSED >>> >>> >>> ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 ------- >>> Again this is not a bug. There is nothing to fix because there is nothing that >>> broke. > >> I disagree. If IE doesn't run, it's a bug. I would actually say that it's >> a major bug - IE is one the those core applications that users expects to >> work. > What would you say if I open a bug about "Windows doesn't work on Wine"? Or > better yet, "Can not upgrade Wine to winxp". > >> You are incorrect about "there is nothing to fix": Perhaps the source code >> is fine, but the documentation is certainly not. >> http://appdb.winehq.org/appview.php?versionId=469 even says: >> "(to be continued because then it still doesn\'t run because of ole >> errors)" > This is _not_ a documentation. If you are not happy with something on appDB ask > app maintainers to change that. Of course suggestions are welcome to what do > you want to see there. > > >>> Anyone is welcome to write up instructions on what to override and place them in >>> appDB. Bugzilla is not the right place for that. > >> Why do you think Bugzilla cannot be used for tracking documentation bugs? >> There is a "wine-documentation" component and a "WineHQ Apps Database" >> component, if you think that wine-misc is totally wrong. > Because that's exactly what appDB is for. > >> I would very much prefer is this bug could be left open until someone has >> managed to figure out what needs to be overridden to actually *run* IE. > I explained in the bug and will repeat here. Wine does not run windows. Wine > runs windows applications. That's the main goal. The ultimate goal is to run > every windows application without using any native component. That way Wine will > be 100% replacement to windows. If you install any part of windows (per m$) you > have to have windows licence. > > I'm not saying that some one can not find a way to run ie on Wine. In fact I > spent quite some time putting that "magic" list of overrides together. Now it's > been removed because Wine has it's own replacement for ie whenever app needs > that. If you are saying that Wine shouldn't actively try to support IE like other Apps, I very much regret this. As a part time web developer I have learned to hate IE very much, each and every bit of web code written has to be tested with it and I always had to go and find a Windows machine to do this. Supporting IE in Wine would help a lot of web developers to migrate completely to Linux. Nearly every Laptop-user has a (maybe unwanted) license for some windows version, so these people (including me) are allowed to run IE on any OS they want. And I think it good for Wine to have its own IE replacement too. Just my 2 €cents. > > Vitaliy. > Ulrich

June 21, 2006

Re: wined3d: Bind correct # of samplers for GLSL shaders

by H. Verbeet

On 21/06/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Specifically, have you tested a sampler > 4 with SetTexture()? SetTexture() will likely fail. > I think this problem should be solved by a single patch that updates all the > necessary places to use the higher texture units value, as opposed to the > legacy one (there's some caps code to write for this). My patch for set_tex_op() would fix a large number, if not all, of these. I mentioned the problem to Jason because I thought he might run into the problem with shaders that use more than 4 textures.

June 21, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Dmitry Timoshkov

"Peter Åstrand" <astrand(a)cendio.se> wrote: >>> I would very much prefer is this bug could be left open until someone has >>> managed to figure out what needs to be overridden to actually *run* IE. >> I explained in the bug and will repeat here. Wine does not run windows. Wine >> runs windows applications. That's the main goal. The ultimate goal is to run > > If you want to keep pretending that IE is "Windows", fine with me. In my > world, IE is an application. The problem is that Microsoft calls IE an "OS component" which implies that it's a part of Windows. Vitaliy tried to explain it. That doesn't mean though that Wine shouldn't be able to run IE. -- Dmitry.

June 21, 2006

Re: solution: IE6 setup says "The download location information is damaged"

by Peter Åstrand

On Tue, 20 Jun 2006, Peter Åstrand wrote: > On Tue, 20 Jun 2006, James Hawkins wrote: > >>> If you're still having this problem, please make sure you are not on a >>> remote or network-mounted drive. IE6 setup checks if the drive is >>> remote, and will not install if it is, complaining with the completely >>> non-related error that "The download location information is damaged." > >> Alternatively, you can go into winecfg->Drives->Show Advanced and >> change the Type from Autodetect to "Local hard disk". > > Indeed, this was the problem! On my FC4 machine, my home directory is NFS > mounted. I guess a lot of applications might behave bad with C: being a Network drive. It seems a lot safer to tag C: as "Hard disk" as default. What about this patch?: Index: tools/wine.inf =================================================================== RCS file: /home/wine/wine/tools/wine.inf,v retrieving revision 1.77 diff -u -r1.77 wine.inf --- tools/wine.inf 19 Jun 2006 08:36:44 -0000 1.77 +++ tools/wine.inf 21 Jun 2006 07:41:05 -0000 @@ -289,6 +289,7 @@ HKLM,System\CurrentControlSet\Control\VMM32Files,,,"" HKLM,System\CurrentControlSet\Services\VxD\MSTCP,,,"" HKCU,Software\Wine\shdocvw,"MozillaUrl",,"http://source.winehq.org/mozactivex" +HKLM,Software\Wine\Drives,"C:",,"hd" HKLM,HARDWARE\DEVICEMAP\PARALLEL PORTS,,,"" HKLM,HARDWARE\DEVICEMAP\SERIALCOMM,,,"" Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 21, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Peter Åstrand

On Tue, 20 Jun 2006, Vitaliy Margolen wrote: >>> ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 ------- >>> Again this is not a bug. There is nothing to fix because there is nothing that >>> broke. > >> I disagree. If IE doesn't run, it's a bug. I would actually say that it's >> a major bug - IE is one the those core applications that users expects to >> work. > What would you say if I open a bug about "Windows doesn't work on Wine"? Or > better yet, "Can not upgrade Wine to winxp". I would say that you are acting silly. "Windows" and "WinXP" is operating systems. IE is an application. >> You are incorrect about "there is nothing to fix": Perhaps the source code >> is fine, but the documentation is certainly not. >> http://appdb.winehq.org/appview.php?versionId=469 even says: >> "(to be continued because then it still doesn\'t run because of ole >> errors)" > This is _not_ a documentation. I think it is. > If you are not happy with something on appDB ask app maintainers to > change that. Of course suggestions are welcome to what do you want to > see there. For Wine to succeed, we need to have a fruitful communication and cooperation between the code wine developers and the AppDb maintainers. Currently, neither the AppDb maintainers nor the core developers (as far as I know) knows how to run IE. If it's not a documentation bug, it is at least a common lack of knowledge, which might be useful to track. >> I would very much prefer is this bug could be left open until someone has >> managed to figure out what needs to be overridden to actually *run* IE. > I explained in the bug and will repeat here. Wine does not run windows. Wine > runs windows applications. That's the main goal. The ultimate goal is to run If you want to keep pretending that IE is "Windows", fine with me. In my world, IE is an application. -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 21, 2006

RE: Wine developers?

by Jonathan Clark

Judging by the two negative reactions, apparently I didn't follow protocol for posting to the list and I want to apologize for that. I understand how it can look from a different perspective. I checked with the #wine-hackers channel first and those guys were very friendly. We had a great discussion and when I mentioned we were looking for developers they suggested I post here. Thanks for your time and consideration, Jonathan

June 21, 2006

Re: Wine developers?

by Molle Bestefich

Jonathan Clark wrote: > replaces the Windows loader for loading EXEs & DLLs, doing things like > mapping, imports, and thread/process management. It also replaces ~400 > Win32 api functions "We're currently borrowing code from the Wine project..." > with funding coming from our customers. Recently we've done fairly well > financially and have the opportunity to try to take the product and company > to the next level by hiring a couple of senior engineers. This brings me to > why I'm posting here.. "...which we're having good commercial success with, so now we'd like to knick a couple of developers from the project, too! Sign-up forms here." Or did I completely misread your posting? :-D

June 21, 2006

wined3d:add an "\n" to a fixme to fix an overflow

by Louis. Lenders

Hi, i get this crash in an application (ftp://ftp.avault.com/demos/puzzleblastsetup.exe) : wine_dbg_vprintf: debugstr buffer overflow (contents: 'fixme:d3d_surface:IWineGDISurfaceImpl_Blt Unsupported flags: 00000010 Unsupported flags: 00000010 Unsupported flags: 00000010 Unsupported flags: 00000010 etcetera This simple patch fixes it. Changelog:add an "\n" to a fixme to fix an overflow --------------------------------- All New Yahoo! Mail Tired of Vi(a)gr@! come-ons? Let our SpamGuard protect you.

June 21, 2006

Very large fonts cause loss of connection to X server

by Troy Rollo

Rendering text to a screen DC with a font height on the order of 17,000 pixels results in glyphs being uploaded to the X server that are on the order of 30MB in size (or more for some wide characters). The next attempt to make a request of the server results in a SIGPIPE. This is possible if an app has the ability to zoom in on a document containing text and allows the user to specify the scaling factor without limiting it. Very large screen fonts can also arise when some WYSIWYG display strategies are used, although this would not ordinarily get to the 17,000 pixel range. Windows deals with such behaviour without problems. I'm not sure there's anything that can be done about this other than imposing an arbitrary sanity check on the size of the screen font prior to uploading the glyph - if the font is much larger than the screen, for instance, then perhaps the best thing is just not to upload the glyph but mark it internally as having been uploaded. Presumably that will prevent the loss of connection without breaking WYSIWYG display strategies that involve calculating positions using large fonts in a screen DC. -- Troy Rollo - wine(a)troy.rollo.name

June 21, 2006

Re: [AppDB] - make variables more consistent, fix indenting

by Tony Lambregts

There are two issues here 1. large patches/commits are difficult to debug, test and fix. 2. Escaping input does not make the queries safe. We need to implement security by making the queries themselves safe. See below: Chris Morgan wrote: > On Tuesday 20 June 2006 5:03 pm, Tony Lambregts wrote: > >> Chris Morgan wrote: >> >>> On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: >>> >>>> Chris Morgan wrote: >>>> >>>>> Make the code more consistent by using the appdb coding standards. >>>>> >>>>> Change $result = query_appdb(...) to $hResult = ... etc. >>>>> >>>>> Also fix some odd indenting due to spaces vs. tabs. >>>>> >>>>> There are still a ton of variables that are integers or strings that >>>>> should be prefixed with 'i' or 's' if anyone is interested in cleaning >>>>> some of that up. >>>>> >>>>> Chris >>>>> >>>> I am not opposed to doing this but I think that the patch is way too big. >>>> At the momment we still have issues with the last "big patch" that are >>>> not cleared up [1]. On the whole unless we cannot avoid it I really do >>>> not think that we should be making such large changes in one go like >>>> this. Please break up the patch into smaller patches. That way it is >>>> easier to find and fix any issues that arise. >>>> >>>> [1] New versions end up as orphans with current setup. >>>> >>>> -- >>>> >>>> Tony Lambregts >>>> >>> Would per-directory patches be easier to read? Like one for /include, >>> one for /admin, one for / ? >>> >>> This patch is a precursor to a patch that will close up a bunch of >>> security holes that could result in the db being destroyed, then on to >>> finding a more appropriate solution to the makeSafe() patch. >>> >>> Chris >>> >> No That is not what I would prefer I would prefer a single patch for each >> file that is changed (ie one for addcomment.php and one for >> include/vendor.php. If the changes to one file need changes in other in >> order for the appdb to continue to function then they should be together in >> one patch. >> >> > > There is no way I'm going to send a patch in per-file. Its a huge pain in the > ass and doesn't change how the monolithic patch is reviewed since you'll end > up reviewing the same code anyway. Breaking the patch up given that its a > atomic noop change is also not necessary. > It may be a pain in the ass for you but it is an even bigger pain in the ass for everyone else when things break. With one big patch I cannot do a "CVS update -D" to find exactly where things broke or just back out the broken part easily. Also I cannot easily test a monolithic patch but I apply and test small patches. My compromise would be to have no more than 4 files changed in a patch unless it cannot be avoided. >> Now you may think that is overboard but I have seen these "big patches" >> break the AppDB too many times. >> >> As far as "security holes that could result in the db being destroyed" we >> do have backup. I dont want you to think I do not care about security. That >> is simply not true. I am however very much against breaking the AppDB for >> regular use. The fact is that so far we have lost more data through bad >> patches then through security holes. >> >> > > I agree. I'll fix the existing issues before applying any more patches like > this one. > Right now makesafe() does nothing because you turned it off. but with it turned on it breaks things and there are still real security issues to address. I'm not sure what else is broken at the moment but I know that there is some problem administering the user account's where you do not see the users data. > >> We have preaty good security in place already, We check that id's are >> numeric and escape date before running it. Right now if you ask me we would >> be better off making a audit of our querys than what you are advocating. >> >> > > Our security is awful. You should really re-read the email sent to the appdb > list by Mortiz Naumann and see how bad it is. > > This is exactly why I think we should audit queries. The "makesafe" patch does nothing to address the issues he brings up. If the queries are not safe then we need to fix them. See the patch I sent to you and appdb(a)winehq.org -- Tony Lambregts

June 21, 2006

Re: [MSI 1/4] add streams table

by Andrey Turkin

Mike McCormack wrote: > > Hi, > > Thanks for submitting the patch, and keeping the coding style consistent! Well, i tried :) > > Andrey Turkin wrote: >> This patch adds virtual _Streams table to MSI because native MSI >> maintains such table >> >> ChangeLog: >> virtual _Streams table added > >> +static UINT STREAMS_fetch_stream( struct tagMSIVIEW *view, UINT row, >> UINT col, IStream **stm ) >> +{ > .... > >> + >> + /* >> + * The column marked with the type stream data seems to have a >> single number >> + * which references the column containing the name of the stream >> data >> + * >> + * Fetch the column to reference first. >> + */ >> + r = view->ops->fetch_int( view, row, col, &ival ); > > I'm not so keen on the way this is done. > > You seem to have duplicated alot of code from TABLE_fetch_stream here. > >> + if( r != ERROR_SUCCESS ) >> + { >> + ERR("1: %d\n", r); >> + return r; >> + } >> + >> + ERR("fetched %d\n", ival); > > And forgotten to remove your debug code. Oops. It happens. > >> +MSIVIEWOPS streams_ops = >> +{ >> + TABLE_fetch_int, >> + STREAMS_fetch_stream, >> + TABLE_set_int, >> + TABLE_insert_row, >> + STREAMS_execute, >> + TABLE_close, >> + TABLE_get_dimensions, >> + TABLE_get_column_info, >> + TABLE_modify, >> + TABLE_delete, >> + TABLE_find_matching_rows >> +}; > > The streams table is just another table. How about generating an > MSITABLE structure containing the data rather than treat it as a special > case in here? I found about ten errors in various DLLs, and fixed them, but, frankly speaking, all of my patches are a bit hacky (sometimes it is shameless quick'n'dirty workaround). I've decided to go forth and find all the errors blocking .NET Framework installer (I'll submit tests shortly for error found so far). After that, when all the errors are known, I will try to write good "submittable" patches to fix the problems. The main problem with writing actual fixes for me is lack of knowledge/experience. I would have to get myself acquainted with target code in order to be able to answer key questions ("Could streams be added on fly? Should URL_ParseUrl parse c:\\blah as Url or not? etc) /me personally dislikes idea of adding internal tables to the database structures. I thought that it is better to split real and virtual tables, that's why I did things in such way. Well, as I said, I would have to think before rewriting this patch :) Regards, Andrey.

June 21, 2006

Re: [WiKI] Common site menu 4/4

by Dimi Paun

On Thu, 2006-06-15 at 16:49 -0600, Tony Lambregts wrote: > Is there anything wrong with this patch? No, I've just been away on vacation, I'll look at it soon. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

June 21, 2006

Re: Wine developers?

by Joseph Garvin

Lots of open source developers probably still have day jobs. Maybe they're looking for a new one. Vitaliy Margolen wrote: > Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: > >> Hello All, >> > > >> My name is Jonathan Clark, and I work with a team on a project that has >> > > I think it's a really really really rude to write to an open source project and > offer such a work. > Basically you are _stealing_ developers from the project. Because with your > closed source project such developer will be prohibited from participating in > the Wine project. > > Unless of course you want to open source your project and release it under at > least GPL licence. > > > Vitaliy. > > > > > >

June 21, 2006

Re: Wine developers?

by Chris Morgan

It's up to individual developers to decide whether or not to work on a project that precludes them from contributing to particular OSS projects. It might be slightly off topic but there haven't been a lot of job offer emails to wine-devel lately or ever. Chris On Tuesday 20 June 2006 9:32 pm, Vitaliy Margolen wrote: > Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: > > Hello All, > > > > My name is Jonathan Clark, and I work with a team on a project that has > > I think it's a really really really rude to write to an open source project > and offer such a work. > Basically you are _stealing_ developers from the project. Because with your > closed source project such developer will be prohibited from participating > in the Wine project. > > Unless of course you want to open source your project and release it under > at least GPL licence. > > > Vitaliy.

June 21, 2006

Re: Wine developers?

by Vitaliy Margolen

Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: > Hello All, > My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.

June 21, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Vitaliy Margolen

Tuesday, June 20, 2006, 11:27:04 AM, Peter Åstrand wrote: > On Mon, 19 Jun 2006, Wine Bugs wrote: >> vitaliy(a)kievinfo.com changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|RESOLVED |CLOSED >> >> >> ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 ------- >> Again this is not a bug. There is nothing to fix because there is nothing that >> broke. > I disagree. If IE doesn't run, it's a bug. I would actually say that it's > a major bug - IE is one the those core applications that users expects to > work. What would you say if I open a bug about "Windows doesn't work on Wine"? Or better yet, "Can not upgrade Wine to winxp". > You are incorrect about "there is nothing to fix": Perhaps the source code > is fine, but the documentation is certainly not. > http://appdb.winehq.org/appview.php?versionId=469 even says: > "(to be continued because then it still doesn\'t run because of ole > errors)" This is _not_ a documentation. If you are not happy with something on appDB ask app maintainers to change that. Of course suggestions are welcome to what do you want to see there. >> Anyone is welcome to write up instructions on what to override and place them in >> appDB. Bugzilla is not the right place for that. > Why do you think Bugzilla cannot be used for tracking documentation bugs? > There is a "wine-documentation" component and a "WineHQ Apps Database" > component, if you think that wine-misc is totally wrong. Because that's exactly what appDB is for. > I would very much prefer is this bug could be left open until someone has > managed to figure out what needs to be overridden to actually *run* IE. I explained in the bug and will repeat here. Wine does not run windows. Wine runs windows applications. That's the main goal. The ultimate goal is to run every windows application without using any native component. That way Wine will be 100% replacement to windows. If you install any part of windows (per m$) you have to have windows licence. I'm not saying that some one can not find a way to run ie on Wine. In fact I spent quite some time putting that "magic" list of overrides together. Now it's been removed because Wine has it's own replacement for ie whenever app needs that. Vitaliy.

June 21, 2006

Re: wined3d: Bind correct # of samplers for GLSL shaders

by Ivan Gyurdiev

On 6/20/06, Jason Green <jave27(a)gmail.com> wrote: > > - We are only checking against GL_MAX_TEXTURES when binding samplers, > when we should be checking against the maximum number of samplers that > the card supports. Spotted by H. Verbeet. Yes, I'm aware of that...it was done on purpose. This limit is in a lot of other places - stateblock code, drawprim code. Have you checked that it will all interact properly using this higher limit? Specifically, have you tested a sampler > 4 with SetTexture()? I think this problem should be solved by a single patch that updates all the necessary places to use the higher texture units value, as opposed to the legacy one (there's some caps code to write for this).

June 20, 2006

Re: [AppDB] - make variables more consistent, fix indenting

by Chris Morgan

On Tuesday 20 June 2006 5:03 pm, Tony Lambregts wrote: > Chris Morgan wrote: > > On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: > >>Chris Morgan wrote: > >>>Make the code more consistent by using the appdb coding standards. > >>> > >>>Change $result = query_appdb(...) to $hResult = ... etc. > >>> > >>>Also fix some odd indenting due to spaces vs. tabs. > >>> > >>>There are still a ton of variables that are integers or strings that > >>>should be prefixed with 'i' or 's' if anyone is interested in cleaning > >>>some of that up. > >>> > >>>Chris > >> > >>I am not opposed to doing this but I think that the patch is way too big. > >>At the momment we still have issues with the last "big patch" that are > >> not cleared up [1]. On the whole unless we cannot avoid it I really do > >> not think that we should be making such large changes in one go like > >> this. Please break up the patch into smaller patches. That way it is > >> easier to find and fix any issues that arise. > >> > >>[1] New versions end up as orphans with current setup. > >> > >>-- > >> > >>Tony Lambregts > > > > Would per-directory patches be easier to read? Like one for /include, > > one for /admin, one for / ? > > > > This patch is a precursor to a patch that will close up a bunch of > > security holes that could result in the db being destroyed, then on to > > finding a more appropriate solution to the makeSafe() patch. > > > > Chris > > No That is not what I would prefer I would prefer a single patch for each > file that is changed (ie one for addcomment.php and one for > include/vendor.php. If the changes to one file need changes in other in > order for the appdb to continue to function then they should be together in > one patch. > There is no way I'm going to send a patch in per-file. Its a huge pain in the ass and doesn't change how the monolithic patch is reviewed since you'll end up reviewing the same code anyway. Breaking the patch up given that its a atomic noop change is also not necessary. > Now you may think that is overboard but I have seen these "big patches" > break the AppDB too many times. > > As far as "security holes that could result in the db being destroyed" we > do have backup. I dont want you to think I do not care about security. That > is simply not true. I am however very much against breaking the AppDB for > regular use. The fact is that so far we have lost more data through bad > patches then through security holes. > I agree. I'll fix the existing issues before applying any more patches like this one. > We have preaty good security in place already, We check that id's are > numeric and escape date before running it. Right now if you ask me we would > be better off making a audit of our querys than what you are advocating. > Our security is awful. You should really re-read the email sent to the appdb list by Mortiz Naumann and see how bad it is. Chris

June 20, 2006

Wine talk in LA june 20th,22nd. Slide check, anyone?

by Dan Kegel

I'm giving a short talk on Wine at lula.org tonight and again at aitp-la.org Thursday night. The audience at aitp-la is IT professionals who don't really know much about Wine or Linux, so I'm trying for a gentle, practical talk. I'll demo a few apps (Office '97, Picasa, Firefox, Kid Pix, and Visual C++) and I'll even run an app that doesn't work too well yet (Visual Basic 6's IDE). The slides, such as they are, are up at kegel.com/wine/wine-2006-june-talk.ppt kegel.com/wine/wine-2006-june-talk.pdf (I usually use magicpoint, but for this talk, I used Office 97's powerpoint on the theory that one should eat one's own dogfood...) Corrections/improvements welcome. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 20, 2006

[ntdll patch] Patch dropped?

by Andrew Talbot

I saw a patch I posted yesterday (ntdll: server.c, write-strings fix) appear on the wine-cvs page for a while :), and now it has disappeared :(. Did it fall, or was it pushed? ;) -- Andy.

June 20, 2006

Re: [AppDB] - make variables more consistent, fix indenting

by Tony Lambregts

Chris Morgan wrote: > > On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: > >>Chris Morgan wrote: >> >>>Make the code more consistent by using the appdb coding standards. >>> >>>Change $result = query_appdb(...) to $hResult = ... etc. >>> >>>Also fix some odd indenting due to spaces vs. tabs. >>> >>>There are still a ton of variables that are integers or strings that >>>should be prefixed with 'i' or 's' if anyone is interested in cleaning >>>some of that up. >>> >>>Chris >> >>I am not opposed to doing this but I think that the patch is way too big. >>At the momment we still have issues with the last "big patch" that are not >>cleared up [1]. On the whole unless we cannot avoid it I really do not >>think that we should be making such large changes in one go like this. >>Please break up the patch into smaller patches. That way it is easier to >>find and fix any issues that arise. >> >>[1] New versions end up as orphans with current setup. >> >>-- >> >>Tony Lambregts > > > > Would per-directory patches be easier to read? Like one for /include, one > for /admin, one for / ? > > This patch is a precursor to a patch that will close up a bunch of security > holes that could result in the db being destroyed, then on to finding a more > appropriate solution to the makeSafe() patch. > > Chris > No That is not what I would prefer I would prefer a single patch for each file that is changed (ie one for addcomment.php and one for include/vendor.php. If the changes to one file need changes in other in order for the appdb to continue to function then they should be together in one patch. Now you may think that is overboard but I have seen these "big patches" break the AppDB too many times. As far as "security holes that could result in the db being destroyed" we do have backup. I dont want you to think I do not care about security. That is simply not true. I am however very much against breaking the AppDB for regular use. The fact is that so far we have lost more data through bad patches then through security holes. We have preaty good security in place already, We check that id's are numeric and escape date before running it. Right now if you ask me we would be better off making a audit of our querys than what you are advocating. -- Tony Lambregts.

June 20, 2006

Re: ntoskrnl status

by Jaap Stolk

On 6/20/06, Jaap Stolk <jwstolk(a)gmail.com> wrote: > <snip> > I noticed that the typical "make install" is missing. > I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok. > Found some more info about this in an old Wine newsletter: > http://www.winehq.com/?issue=269#Speeding%20Up%20Builds And a script to setup the correct wine variables without installing wine. http://wiki.jswindle.com/index.php/General_Developer_Information#Running_Wi…

June 20, 2006

Wine developers?

by Jonathan Clark

Hello All, My name is Jonathan Clark, and I work with a team on a project that has some similarities with Wine. The project is called Thinstall (http://thinstall.com) and on first glance similarities may not be apparent. Thinstall allows Win32 applications to run (on Windows) from a network share or usb flash drive with zero install. It isn't meant to allow applications to run cross platform like wine, but it is similar in that it replaces the Windows loader for loading EXEs & DLLs, doing things like mapping, imports, and thread/process management. It also replaces ~400 Win32 api functions in order to allow applications to run instantly in a sandbox so they don't need to touch the local filesystem or registry. Our approach is all in user mode so that applications can run under any login account without needing admin rights or drivers. Thinstall packages the entire application into a single EXE file and then tacks on it's runtime (300k on disk) so apps can be distributed and run as a single file that doesn't need to decompress to disk. The challenges in creating Thinstall are many of the same ones that Wine faces, achieving a high degree of compatibility in replacement functions means you need to be good at debugging and understanding the internals of Windows. Since most code can be run by multiple threads, it is also important to understand thread safety and have a lot of experience working through these types of issues. Thinstall is now about 6 years old and we are coming up on a version 3.0 release. Thinstall is a commercial product and everyone works full time with funding coming from our customers. Recently we've done fairly well financially and have the opportunity to try to take the product and company to the next level by hiring a couple of senior engineers. This brings me to why I'm posting here.. If you are experienced with Windows internals, have experience reimplementing Win32 APIs, and you are interested in some contract or full-time work please let me know. We are located in San Francisco, California (awesome town) and ideally I'd like to work with people locally. We can help with a move if needed. Otherwise, if you are outside of the USA - we could talk about doing something remotely. I hope to hear from you. Best Regards, Jonathan Clark P.S. As background info, I used to be heavily in the linux space when I co-founded a video game company "Crack dot com" which made the linux port of Doom & Quake as well as developed the original titles Abuse and Golgotha. I have been aware of wine for a long long time and I'm impressed by the quality of work by all the developers and how far it has come. P.S.S. I subscribed in digest mode so if you reply to the list, keep in mind I won't see it until tomorrow.

June 20, 2006

Re: ntoskrnl status

by Jaap Stolk

Thanks for the "tutorial" Saulius. (I'm new to git) It's all compiled now. Just to summarize: (with your enhancements) # (after completing: http://wiki.winehq.org/GitWine ) # rename/extract patch: $ cd wine-git $ mv origin_sd1.diff-0001.obj origin_sd1.diff.bz2 $ bunzip2 --keep origin_sd1.diff.bz2 # patch wine: $ git branch ntoskrnl 1d40bf0141b7f67b1188555962698f5dab631bc3 $ git branch $ git checkout ntoskrnl $ git branch $ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs git-update-index --add $ tools/make_requests $ git commit -a -m "ntoskrnl: Experimental implementation." # recompile Wine: $ ./configure && make depend && make && tools/wineprefixcreate --use-wine-tree . # below goes your experiments $ ... # and here we go back to the normal tree $ git checkout master # recompile Wine $ ./configure && make depend && make && tools/wineprefixcreate --use-wine-tree . # and do our stuff $ ... I noticed that the typical "make install" is missing. I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok. Found some more info about this in an old Wine newsletter: http://www.winehq.com/?issue=269#Speeding%20Up%20Builds

June 20, 2006

Re: [AppDB] - make variables more consistent, fix indenting

by Chris Morgan

Would per-directory patches be easier to read? Like one for /include, one for /admin, one for / ? This patch is a precursor to a patch that will close up a bunch of security holes that could result in the db being destroyed, then on to finding a more appropriate solution to the makeSafe() patch. Chris On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: > Chris Morgan wrote: > > Make the code more consistent by using the appdb coding standards. > > > > Change $result = query_appdb(...) to $hResult = ... etc. > > > > Also fix some odd indenting due to spaces vs. tabs. > > > > There are still a ton of variables that are integers or strings that > > should be prefixed with 'i' or 's' if anyone is interested in cleaning > > some of that up. > > > > Chris > > I am not opposed to doing this but I think that the patch is way too big. > At the momment we still have issues with the last "big patch" that are not > cleared up [1]. On the whole unless we cannot avoid it I really do not > think that we should be making such large changes in one go like this. > Please break up the patch into smaller patches. That way it is easier to > find and fix any issues that arise. > > [1] New versions end up as orphans with current setup. > > -- > > Tony Lambregts

June 20, 2006

Re: [AppDB] - make variables more consistent, fix indenting

by Tony Lambregts

Chris Morgan wrote: > Make the code more consistent by using the appdb coding standards. > > Change $result = query_appdb(...) to $hResult = ... etc. > > Also fix some odd indenting due to spaces vs. tabs. > > There are still a ton of variables that are integers or strings that should be > prefixed with 'i' or 's' if anyone is interested in cleaning some of that up. > > Chris I am not opposed to doing this but I think that the patch is way too big. At the momment we still have issues with the last "big patch" that are not cleared up [1]. On the whole unless we cannot avoid it I really do not think that we should be making such large changes in one go like this. Please break up the patch into smaller patches. That way it is easier to find and fix any issues that arise. [1] New versions end up as orphans with current setup. -- Tony Lambregts

June 20, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Jonathan Ernst

On Tue, 2006-06-20 at 13:49 -0400, Vijay Kiran Kamuju wrote: > Try adding wine overrides for iexplore This has been already tried of course. The problem is to find a good combination of native dlls to run IE (stock WineCVS let's you install it without problems now). You can see the current state of the How-To here: http://appdb.winehq.org/appview.php?versionId=469 If someone knows about the current minimal override required to run IE in win2k mode, I'll gladly add it to the How-to (because we have about one user a day and a bug a week for this damn IE ;-) ).

June 20, 2006

Re: solution: IE6 setup says "The download location information is damaged"

by Peter Åstrand

On Tue, 20 Jun 2006, James Hawkins wrote: >> If you're still having this problem, please make sure you are not on a >> remote or network-mounted drive. IE6 setup checks if the drive is >> remote, and will not install if it is, complaining with the completely >> non-related error that "The download location information is damaged." > Alternatively, you can go into winecfg->Drives->Show Advanced and > change the Type from Autodetect to "Local hard disk". Indeed, this was the problem! On my FC4 machine, my home directory is NFS mounted. Perhaps this can be mentioned in the AppDb Howto? I'll close the bug. Thanks. -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 20, 2006

Re: solution: IE6 setup says "The download location information is damaged"

by James Hawkins

On 6/20/06, James Hawkins <truiken(a)gmail.com> wrote: > Hey, > > If you're still having this problem, please make sure you are not on a > remote or network-mounted drive. IE6 setup checks if the drive is > remote, and will not install if it is, complaining with the completely > non-related error that "The download location information is damaged." > If you're not sure whether you're on a remote drive or not, and the > IE6 setup is still not working, please post back and attach a +volume > trace. I was frustrated that the setup was not working on my work > machine, while it was on my home machine. Reading through a +all log > showed that GetDriveTypeW was returning 4 for my work machine, which > is DRIVE_REMOTE, and then it would fail with the message box. Hacking > GetDriveTypeW to always return DRIVE_FIXED let me install onto my > remote drive. > Alternatively, you can go into winecfg->Drives->Show Advanced and change the Type from Autodetect to "Local hard disk". -- James Hawkins

June 20, 2006

solution: IE6 setup says "The download location information is damaged"

by James Hawkins

Hey, If you're still having this problem, please make sure you are not on a remote or network-mounted drive. IE6 setup checks if the drive is remote, and will not install if it is, complaining with the completely non-related error that "The download location information is damaged." If you're not sure whether you're on a remote drive or not, and the IE6 setup is still not working, please post back and attach a +volume trace. I was frustrated that the setup was not working on my work machine, while it was on my home machine. Reading through a +all log showed that GetDriveTypeW was returning 4 for my work machine, which is DRIVE_REMOTE, and then it would fail with the message box. Hacking GetDriveTypeW to always return DRIVE_FIXED let me install onto my remote drive. Thanks, James Hawkins

June 20, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Vijay Kiran Kamuju

Try adding wine overrides for iexplore Just my 2 cents, Vijay On 6/20/06, Peter Åstrand <astrand(a)cendio.se> wrote: > On Mon, 19 Jun 2006, Wine Bugs wrote: > > > vitaliy(a)kievinfo.com changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|RESOLVED |CLOSED > > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 ------- > > Again this is not a bug. There is nothing to fix because there is nothing that > > broke. > > I disagree. If IE doesn't run, it's a bug. I would actually say that it's > a major bug - IE is one the those core applications that users expects to > work. > > You are incorrect about "there is nothing to fix": Perhaps the source code > is fine, but the documentation is certainly not. > http://appdb.winehq.org/appview.php?versionId=469 even says: > > "(to be continued because then it still doesn\'t run because of ole > errors)" > > > > Anyone is welcome to write up instructions on what to override and place them in > > appDB. Bugzilla is not the right place for that. > > Why do you think Bugzilla cannot be used for tracking documentation bugs? > There is a "wine-documentation" component and a "WineHQ Apps Database" > component, if you think that wine-misc is totally wrong. > > I would very much prefer is this bug could be left open until someone has > managed to figure out what needs to be overridden to actually *run* IE. > > Regards, > -- > Peter Åstrand ThinLinc Chief Developer > Cendio http://www.cendio.se > Teknikringen 3 > 583 30 Linköping Phone: +46-13-21 46 00 > > > > >

June 20, 2006

riched slowdown

by James Hawkins

Hi, I just did a +relay log of the ie6setup.exe installation. I had to ctrl-c after the log grew to 3.5gb and the initial screen hadn't been displayed yet. tail -n 1000 relay.log showed call after call to WideCharToMultibyte before I finally killed the install. Here is a sample of one of the calls: WideCharToMultiByte(000004e4,00000000,40895ae4 L"S\5524",00000001,40895ae7,00000001,00000000,40895ae8) So the length of the "string" we're converting is 1. Not exactly efficient. grep'ing the log for WideCharToMultiByte reveals 39426680 calls, and it wasn't even done loading the EULA. I'm pretty sure this is a recent bug in riched, as overriding riched20 and riched32 gets rid of the problem. -- James Hawkins

June 20, 2006

Re: [Bug 5463] ie6 installs now, but doesn't work...

by Peter Åstrand

On Mon, 19 Jun 2006, Wine Bugs wrote: > vitaliy(a)kievinfo.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2006-19-06 14:11 ------- > Again this is not a bug. There is nothing to fix because there is nothing that > broke. I disagree. If IE doesn't run, it's a bug. I would actually say that it's a major bug - IE is one the those core applications that users expects to work. You are incorrect about "there is nothing to fix": Perhaps the source code is fine, but the documentation is certainly not. http://appdb.winehq.org/appview.php?versionId=469 even says: "(to be continued because then it still doesn\'t run because of ole errors)" > Anyone is welcome to write up instructions on what to override and place them in > appDB. Bugzilla is not the right place for that. Why do you think Bugzilla cannot be used for tracking documentation bugs? There is a "wine-documentation" component and a "WineHQ Apps Database" component, if you think that wine-misc is totally wrong. I would very much prefer is this bug could be left open until someone has managed to figure out what needs to be overridden to actually *run* IE. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 20, 2006

Re: lz32: remove dead code from the LZOpenFileW test.

by Saulius Krasuckas

* On Tue, 20 Jun 2006, Detlef Riekenberg wrote: > * Saulius Krasuckas wrote: > > > + ok(file >= 0, "LZOpenFileW failed on switching to a compressed file name\n"); > .. > > + ok(test.nErrCode == 0, "LZOpenFileW set test.nErrCode to %d\n", > > + test.nErrCode); > > Did you mean "test.nErrCode == ERROR_SUCCESS"? Yes, should I use the constant name in a case of success? > You test the Errorcode here, but you did not use SetLastError() before > LZOpenFileW. Well, I didn't because I don't test using GetLastError(). But you are right, I was too fast (falling asleep) and removed this needed line tonight: - memset(&test, 0xA5, sizeof(test)); Will put that back. > An extra Patch with the WINAPI-Documentation for the Implementation > would be nice. It was planned to be added as soon as I get on the stuff that LZOpenFile* does :) > This should include a note, that the ANSI-String "szPathName" in > "OFSTRUCT" is the correct Parameter for the UNICODE-Implementation. Uhu, quite confusing, isn't it? I was trying to eliminate LZOpenFileW -> LZOpenFileA crosscall and this confusion was a reason to write tests. > The Messages in the "W"-Tests have ANSI Function-Names Aha, copy&paste quirks. Thanks, Detlef.

June 20, 2006

appdb: makeSafe improvement

by Vitaly Lipatov

After last security fixes in AppDB there is introduced makeSafe function with one parameter. Typical using of makeSafe: $aClean['sub'] = makeSafe($_REQUEST['sub']); When $_REQUEST does not contain 'sub', we get "Notice: Undefined index:" if mod_php in strict mode (do not permit undefined variables). What about use makeSafe in the form $aClean['sub'] = makeSafe($_REQUEST,'sub'); Then we can use isset inside makeSafe for additional checking. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

June 20, 2006

Re: lz32: remove dead code from the LZOpenFileW test.

by Detlef Riekenberg

Saulius Krasuckas wrote: > + ok(file >= 0, "LZOpenFileW failed on switching to a compressed file name\n"); .. > + ok(test.nErrCode == 0, "LZOpenFileW set test.nErrCode to %d\n", > + test.nErrCode); Did you mean "test.nErrCode == ERROR_SUCCESS"? You test the Errorcode here, but you did not use SetLastError() before LZOpenFileW. > + ok(lstrcmpA(test.szPathName, expected) == 0, > + "LZOpenFileW returned '%s', but was expected to return '%s'\n", > + test.szPathName, expected); This is strange: An ANSI-Compare for an UNICODE-Function. After reading the source and OFSTRUCT, this is correct. I suggest a command before the above "ok()". An extra Patch with the WINAPI-Documentation for the Implementation would be nice. This should include a note, that the ANSI-String "szPathName" in "OFSTRUCT" is the correct Parameter for the UNICODE-Implementation. ---- cut ---- This part from your previous Patch is already in the tree, but: > > + /* Delete the file then make sure it doesn't exist anymore. */ > + file = LZOpenFileW(filename_W, &test, OF_DELETE); > + ok(file >= 0, "LZOpenFileA failed on delete\n"); > + retval = GetFileAttributesW(filename_W); > + ok(retval == INVALID_FILE_ATTRIBUTES, > + "GetFileAttributesA succeeded on deleted file\n"); The Messages in the "W"-Tests have ANSI Function-Names -- By By ... ... Detlef

June 20, 2006

Re: Winelib Getting Started 1.3.2. Test Drive

by Eric Frias

Alexandre Julliard wrote: >Eric Frias <efrias(a)syncad.com> writes: > >>here is one other part that is out-of-date: the procedure described >>won't create the 'notepad2' script. >> >winegcc should create the script. If it doesn't it's probably because >winemaker is not invoking it correctly. > That was the problem. Winemaker was invoking 'winegcc -o foo.exe.so', which suppresses the wrapper script. If it's invoked as 'winegcc -o foo.exe' it generates the wrapper script as desired. Something like the attached patch should fix the problem. Eric --- wine-0.9.15/tools/winemaker 2006-06-08 15:06:43.000000000 +0000 +++ ../wine-0.9.15/tools/winemaker 2006-06-20 14:17:36.000000000 +0000 @@ -1749,7 +1749,11 @@ } else { print FILEO "\t\$(CC)"; } - print FILEO " \$(${canon}_LDFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_LIBRARY_PATH) \$(DEFLIB) \$(${canon}_DLLS:%=-l%) \$(${canon}_LIBRARIES:%=-l%)\n"; + + # for .EXEs, tell winegcc to generate 'foo.exe', which will cause it + # to generate both 'foo.exe.so' and the 'foo' wrapper script. + my $output_file = @$target[$T_TYPE] == $TT_DLL ? "\$\@" : "\$(${canon}_MODULE)"; + print FILEO " \$(${canon}_LDFLAGS) -o $output_file \$(${canon}_OBJS) \$(${canon}_LIBRARY_PATH) \$(DEFLIB) \$(${canon}_DLLS:%=-l%) \$(${canon}_LIBRARIES:%=-l%)\n"; print FILEO "\n\n"; } }

June 20, 2006

Re: msi: Fix handling of the no-op identifier in the Directory table [resend]

by Saulius Krasuckas

* On Tue, 20 Jun 2006, Alexandre Julliard wrote: > * "James Hawkins" <truiken(a)gmail.com> writes: > > > > Is there anything wrong with this patch? > > You are assigning a const string to a non-const variable, that causes > warnings. Alexandre, maybe we should know what CGLAGS are you using so we can use them too and detect such compiler warnings in future? Would you reveal them, please? :)

June 20, 2006

Re: msi: Fix handling of the no-op identifier in the Directory table [resend]

by Alexandre Julliard

Saulius Krasuckas <saulius2(a)ar.fi.lt> writes: > Alexandre, maybe we should know what CGLAGS are you using so we can use > them too and detect such compiler warnings in future? Would you reveal > them, please? :) I don't use special flags, just a standard configure. You may need a more recent gcc to see all the warnings. -- Alexandre Julliard julliard(a)winehq.org

June 20, 2006

Re: [WINED3D 3/3] Fix fog in the case of vertex shaders

by H. Verbeet

On 20/06/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Is it really necessary to keep track of whether the shader uses fog or not? > What happens if you disable this post-processing for a shader that doesn't > write to the fog register? Not "really necessary", but it does save a couple of GL state changes if fog isn't used in the shader, and it's pretty easy to keep track of.

June 20, 2006

Re: Winelib Getting Started 1.3.2. Test Drive

by Alexandre Julliard

Eric Frias <efrias(a)syncad.com> writes: > There is one other part that is out-of-date: the procedure described > won't create the 'notepad2' script. It would be better to change that > part of section 1.3.2 to suggest you run 'wine notepad2.exe.so' or to > run 'ln -s ../../tools/winewrapper notepad2' to create the script. > Aside from that, the instructions look good to me. winegcc should create the script. If it doesn't it's probably because winemaker is not invoking it correctly. -- Alexandre Julliard julliard(a)winehq.org

June 20, 2006

Re: Winelib Getting Started 1.3.2. Test Drive

by Eric Frias

Robert Muller wrote: > Dee Ayy wrote: > | As a newbie, the statement "It can be found in the programs > subdirectory." > | had me lost. > > [...] > > At this point, the sentance that gave you problems could be modified to > say: It can be found in the programs subdirectory of the wine source. There is one other part that is out-of-date: the procedure described won't create the 'notepad2' script. It would be better to change that part of section 1.3.2 to suggest you run 'wine notepad2.exe.so' or to run 'ln -s ../../tools/winewrapper notepad2' to create the script. Aside from that, the instructions look good to me. Eric

June 20, 2006

ntoskrnl followup

by Frans Kool

Hi Vitaliy, If I read the thread concerning ntoskrnl insertion into Wine correctly, the patch will have to be divided into several parts to be accepted by AJ. For this, tests need probably be written to make sure each sub-patch is performing as it should. I haven't written C-code for a while, but there are a lot of tests available for me to have a crack at it. As I see it, the following tests/patches are needed (in this order?) 1) Tests for talking to ntoskrnl through wineserver (setting up channel, testing messages both correct and incorrect and closing channel again) in order to test the new way of communication. 2) Tests to try the ioctl structures 3) loading a device driver, talking to it, unloading it (including negatives like unloading a non-loaded driver etc). 4) Open issues like detecting if the driver is actually loaded instead of waiting X ms.... The questions I have are: a) Is the breakdown correct, or are there more atomic parts (easier to test/get into wine). Do you already have a breakdown idea of the patch into smaller parts so I/we can focus on this? b) Did I miss tests or do you have ideas for more? c) Is the order of the patches correct? If not, please correct me so I can start creating tests. d) Can I somehow access the most recent version of the patch? I have several versions now, but they keep on changing/improving(!). It would be nice if you could publish it somewhere (nightly CVS tarball?), so more people can provide feedback on it too. As you can see, I'm just trying to see if I can contribute on such a big project. Thanks for the feedback, Frans.

June 20, 2006

LoadResource with module=0x00400000 followed by stack overflow

by Jan-Espen Pettersen

I get this stack overflow exception while trying to run the Watchtower Library Setup on FreeBSD 6.1. I have extracted some debug lines which I think is relevant. Please ask if you need more information. 0009:Call ntdll.LdrFindResource_U(00400000,0034ecf0,00000003,0034ec8c) ret=9c266b12 0009:trace:resource:LdrFindResource_U module 0x400000 type #0006 name #0901 lang 0414 level 3 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b000 id 0006 ret 0x40b090 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b090 id 0901 ret 0x40bb98 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40bb98 id 0414 ret 0x40d1c8 0009:Ret ntdll.LdrFindResource_U() retval=00000000 ret=9c266b12 0009:Ret kernel32.FindResourceExA() retval=0040d1c8 ret=00405ac0 0009:Call kernel32.LoadResource(00400000,0040d1c8) ret=00405ae4 0009:trace:resource:LoadResource 0x400000 0x40d1c8 0009:Call ntdll.LdrAccessResource(00400000,0040d1c8,0034ed48,00000000) ret=9c26807b 0009:trace:resource:access_resource access resource 0009:trace:resource:access_resource *ptr=0x4219d0 0009:Ret ntdll.LdrAccessResource() retval=00000000 ret=9c26807b 0009:Ret kernel32.LoadResource() retval=004219d0 ret=00405ae4 0009:Call ntdll.NtCreateEvent(0034e634,001f0003,0034e8dc,00000001,00000000) ret=9c22d14a 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=9c22d14a wine: Unhandled stack overflow at address 0x405b1d (thread 0009), starting debugger... (There was thread two (to 000b and back to 0009) context switches in between, which I filtered out) I single stepped the last instructions before the crash and found that it crashed while trying to write to the memory pointed to by the returned pointer from LoadResource. It loaded the address with some offset into register %esi and crashed at an andw instruction: First chance exception: stack overflow in 32-bit code (0x00405b1d). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405b1d ESP:0035ee08 EBP:0035f224 EFLAGS:00010346( - 00 RITZP1) EAX:0000006c EBX:00000000 ECX:00000003 EDX:00000000 ESI:00421b5e EDI:00421a86 Stack dump: 0x0035ee08: 9c266cc0 0035f954 0035f230 00000000 0x0035ee18: 00401df3 00009003 0035f224 0035f958 0x0035ee28: 0035f954 00000000 9c086a19 9c0da2c0 0x0035ee38: 0035ee78 9c092b72 00120020 00000001 0x0035ee48: 9c086957 00000000 00000000 0035ee34 0x0035ee58: 005ca2c0 9c08b791 00167e10 00000000 0200: sel=1007 base=00110000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00405b1d in setup (+0x5b1d) (0x00405b1d) 0x00405b1d: andw $0,0x0(%esi) Wine-dbg>info share Module Address Debug info Name (3 modules) PE 0x9c070000-9c0dd000 --none-- ntdll PE 0x9c210000-9c2f1000 --none-- kernel32 PE 0x00400000-0042b000 Export setup Can a win32 program expect that it has write access to the memory pointed to by the return value of LoadResource with module 0x00400000? Should LoadResource in some cases copy the memory and return a writeable copy of the resource? Jan-Espen Pettersen

June 20, 2006

Re: [WINED3D 3/3] Fix fog in the case of vertex shaders

by Ivan Gyurdiev

On 6/19/06, Jason Green <jave27(a)gmail.com> wrote: > > - Fixes both ARB and GLSL shaders that use fog. > Is it really necessary to keep track of whether the shader uses fog or not? What happens if you disable this post-processing for a shader that doesn't write to the fog register? Also, how come the ARB version forces the fog value to be > 0, but the GLSL one has both lower and upper limit (clamp to 0,1) ? Shouldn't you use saturate (_SAT) to achieve the same effect?

June 20, 2006

Re: msi: Fix handling of the no-op identifier in the Directory table [resend]

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Is there anything wrong with this patch? > > Changelog: > * Fix handling of the no-op identifier in the Directory table. You are assigning a const string to a non-const variable, that causes warnings. -- Alexandre Julliard julliard(a)winehq.org

June 20, 2006

Re: ddraw assert prevents Ankh from starting

by Stefan Dösinger

Hi, > on the end of this mail is a patch, that removes an assert(0) from the > surface code in ddraw. but removing it let Ankh[1][2] start (it started > before, but there where no loading screen visible). yet there are other > problems with this game - but it now actually works better than before. > > so let the ddraw developers decide what to do there - this mail is just > a reminder, that there is a poor little homeless assert, that needs your > attention ;) Ooops. Well, that assert is a sort of debugging assertion to be sure to catch apps which call this function. It wasn't meant to go into the winehq tree, I missed it when doing my cleanup checks :-( Anyway, that call is pretty much untested, I don't expect it to work as-is(especially if the app sets a surface memory pointer). You can send the patch to remove that assert to wine-patches, it's clearly wrong. I'm just downloading the demo to test it myself, but I'm quite busy at university right now :-(

June 20, 2006

Re: ntoskrnl status

by Saulius Krasuckas

* On Tue, 20 Jun 2006, Mike McCormack wrote: > * Saulius Krasuckas wrote: > > > > > http://wiki.winehq.org/GitWine seems to be more oriented at making > > > patches, not importing a patch made by someone else. > > > $ cat origin_sd1.diff | patch -p1 > > $ tools/make_requests > > $ git commit -a -m "ntoskrnl: Experimental implementation." > > If the patch is created with "git format-message", you can use "git am > origin_sd1.diff" to add it to your tree. 'am' applies a mailbox, which is a > series of patches and their commit info. Nice, thanks Mike. BTW, my "tutorial" won't work well, because after the "patch" cmd no one instructs git to add newly created files to a repository. So my answer should be enchanced. I've just accidentally found a command to replace "patch", it's "git-apply". Unfortunately it doesn't add newly created files for me, thus I change my advise this way: $ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs git-update-index --add $ tools/make_requests $ git commit -a -m "ntoskrnl: Experimental implementation."

June 20, 2006