August 2002 - Wine-Devel - list.winehq.org

Re: GetObject with empty buffer

by Uwe Bonnes

>>>>> "Fabian" == Fabian Cenedese <Cenedese(a)indel.ch> writes: ... Fabian> <MSDN> If the lpvObject parameter is NULL, the function return Fabian> value is the number of bytes required to store the information Fabian> it writes to the buffer for the specified graphics object. Fabian> </MSDN> Fabian> But I couldn't find this anywhere, not in the general function Fabian> in gdiobj.c nor in the subtypes FONT_GetObject or Fabian> BRUSH_GetObject (sure others neither). As my app uses this Fabian> feature Wine tries to memcpy to a NULL pointer and jumps out of Fabian> the window... literally :) FONT_GetObject sure checks: if(buffer) memcpy( buffer, &lfA, count ); return count; BRUSH_GetObject does not: if (count > sizeof(brush->logbrush)) count = sizeof(brush->logbrush); memcpy( buffer, &brush->logbrush, count ); return count; Someone has to carefully check all subtypes... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 29, 2002

heise online: Tumultuous Response to Alleged Change in MP3 Licensing Conditions

by Thomas Rösch

>From a huge german computer magazin, you can found it under: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ -------------------------------------------------------------------- Tumultuous Response to Alleged Change in MP3 Licensing Conditions Ever since the early morning heise online has been receiving a swelling stream of disapproving comment on alleged changes to MP3 licenses: According to a posting at Slashdot[1] Thomson Multimedia, the exclusive licensor of MP3, is said to have erased a passage from its licensing conditions according to which no licensing fees were due for non-commercial free MP3 decoders. In doing so the company was said to be referring to the official table of fees[2], according to which a fee of 75 US cents per MP3 decoder or a one-off payment of 60,000 US dollars (for patent and software; 50,000 US dollars for the patent only) was due. As a matter of fact this rule has been in force for about eighteen months now[3]. At that time not only was the web design of MP3licensing.com modified, in the course of the creation of the then new MP3Pro the licensing conditions were also adjusted. Another decisive passage was also scrapped at that time: "No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users". By inquiring with the Fraunhofer Institute for Integrated Circuits (IIS[4]) and MP3Pro developer Coding Technologies[5] heise online was able to verify the existence of this link -- the tumult has hence been pretty late in coming. Given that Thomson Multimedia has since then not taken any legal steps against developers or distributors of non-commercial MP3 decoders, it does not appear that the future of free MP3 decoders is in jeopardy. As it is, for Thomson to take drastic legal measures in this matter would not make much sense: There is not much money to be had from freeware and open source developers who have created their own MP3 decoders. This is probably the reason why the licensor has refrained to date from taking the appropriate steps. The situation appears to be different with regard to encoders for the creation of MP3 files, however: As a rule in these cases the Fraunhofer Institute as well as Thomson insist that the licensing conditions be met; an open source packet called lame does, however, exist (whether, in the event, its self-referential Gödelian acronym reading LAME Ain't a Mp3 Encoder has enough protective charm is a moot point). It is also not to be feared that such popular players as Winamp or the Musicmatch Jukebox will in future be distributed free-of-charge only without an MP3 decoder: Nullsoft as well as Musicmatch are among the official licensees of MP3(Pro), in the case of Musicmatch this statement also applies to its integrated encoder. Whatever the merits, if any, of the changes in licensing conditions, Mr. Emmett Plant, CEO by profession of Xiph.org Foundation has expressed his considerable delight at the turn of events. In an open letter[6] he thanked Thomson Multimedia. "Thank you for the huge amount of free advertising to our benefit created by your announcement that licensing conditions had changed," Mr. Plant wrote. The letter closes with: "We support all actions on the part of Thomson that make it plain that MP3 costs money. Once again thank you and good luck." Unlike MP3, Ogg Vorbis, recently published in its version 1.0 (according to its developers' statements), is free of patent protection and subject to the GNU Public License; hence, even in future no license fees of any sort would be due for this compression process. It is not a good idea as yet to rely exclusively on Ogg Vorbis, however: Even if Ogg Vorbis manages to close the quality gap between it and MP3 or even manages to get ahead of the latter, it will still take some time before Ogg-capable portable players make their appearance as hardware. (Robert W. Smith) / (jk[7]/c't) URL of this article: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ Links in this article: [1] http://www.slashdot.org [2] http://www.mp3licensing.com/royalty/software.html [3] http://web.archive.org/web/20010331223305/www.mp3licensing.com/royalty/swde… [4] http://www.iis.fhg.de/ [5] http://www.codingtechnologies.com/ [6] http://www.xiph.org/ogg/vorbis/openletter.html [7] mailto:jk(a)ct.heise.de -------------------------------------------------------------------- Copyright 2002 by Verlag Heinz Heise

Aug. 29, 2002

GetObject with empty buffer

by Fabian Cenedese

Hello I think I found my (or better a :) problem with fonts. The function GetObject <MSDN> int GetObject( HGDIOBJ hgdiobj, // handle to graphics object int cbBuffer, // size of buffer for object information LPVOID lpvObject // buffer for object information ); </MSDN> should either return the info in the object buffer or, if this pointer is zero, just the size the required info would need. <MSDN> If the lpvObject parameter is NULL, the function return value is the number of bytes required to store the information it writes to the buffer for the specified graphics object. </MSDN> But I couldn't find this anywhere, not in the general function in gdiobj.c nor in the subtypes FONT_GetObject or BRUSH_GetObject (sure others neither). As my app uses this feature Wine tries to memcpy to a NULL pointer and jumps out of the window... literally :) bye Fabi

Aug. 29, 2002

Menu patch breakage

by Rein Klazes

Hi, Yesterday's destroymenu patch broke a number of applications, among them Forte Agent. Because I don't quite understand the issues yet, I have uploaded a +relay,+menu log to www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. Thanks, Rein. -- Rein Klazes rklazes(a)xs4all.nl

Aug. 29, 2002

Re: Return value GetStockObject

by Fabian Cenedese

> > In my app I try to get a handle to a system font with following call: > > HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); > > If the call succeeds it should return a handle to the requested object, > > otherwise zero. In Windows I get something like 0x018A000E (looks ok), > > but in Wine I get 0x0000009E. Even not zero I can't imagine that this is > > a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, > > only SYSTEM_FONT. > > Is this an error or am I barking up the wrong tree? > >In Wine, handles are not (yet) all void * (see bug #90). Even then, it >doesn't mean a handle is a valid heap address; I know there are a couple >places in Wine where they are used as an index in an array locating all >objects of a kind. It doesn't exactly follow the Windows convention, but >I think handles are supposed to be passed back to APIs, not handled >(dereferenced) directly by apps. > >So 0x0000009E doesn't strike me as bad. If you use it in calls to font >APIs, does it work correctly? With this returned handle I try to fill a structure with GetObject: HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); LOGFONT lfSys; int ret=GetObject(hobj, sizeof(lfSys), &lfSys); (Windows returns 36) After that lfSys has all the info about this font. In Windows the members are filled nicely, lfSys.lfFaceName is "Courier". In Wine GetObject returns 60 (for whatever reason), and lfSys.lfFaceName is empty. Now this could mean that the handles are invalid or that there is something wrong with my fonts. Thanks Fabi

Aug. 29, 2002

Re: removing mp3 code

by Uwe Bonnes

>>>>> "Marcus" == Marcus Meissner <meissner(a)suse.de> writes: Marcus> Hi, Apparently distributing even mp3 decoders is not royaltee Marcus> free anymore, according to the slashdot thread and the Thomson Marcus> MultiMedia pages. http://www.heise.de/newsticker/data/vza-29.08.02-000/ (german) tell about a Thompson Statement that free decoders are still royalty free. The Thompson statement in in english. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 29, 2002

Re: removing mp3 code

by Marcus Meissner

On Thu, Aug 29, 2002 at 11:03:26AM +0200, Michael Stefaniuc wrote: > Hello, > > On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > > Apparently distributing even mp3 decoders is not royaltee free anymore, > > according to the slashdot thread and the Thomson MultiMedia pages. > > > > So we probably should remove the msacm mp3 decoder we include. :( > I would wait with that, because every day you get an other information. > Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ Hmm, ok. Ignore my last mail then ;) Ciao, Marcus

Aug. 29, 2002

RE: removing mp3 code

by Patrik Stridvall

> Apparently distributing even mp3 decoders is not royaltee > free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( At the very least we should make it compile option that is by default disabled. I don't think we need to go that far as to remove it. IIRC LAME an mp3 ENCODER (that was non royalty free even before) got around it by only distributing source code and so can we. BTW: Why do we include a mp3 decoder in the Wine tree? Why not just link to an external library? I can't see maintaining a mp3 decoder being in the best intrest of Wine anyway patents or not...

Aug. 29, 2002

Re: removing mp3 code

by Michael Stefaniuc

Hello, On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > Apparently distributing even mp3 decoders is not royaltee free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( I would wait with that, because every day you get an other information. Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Martin Wilck

Am Don, 2002-08-29 um 03.25 schrieb Alexandre Julliard: > I'd say that DOSFS_ToDosFCBFormat should fail when the file contains > upper-case chars on a case-sensitive file system. This will probably > make it impossible to access some files in certain cases though. I'm > afraid it's not possible to support case-sensitive file systems 100% > right given that Windows apps don't preserve case correctly. I propose another patch with is is IMO the least intrusive: - changes nothing for non-"unix" filesystems - for "unix", searches the whole directory for exact matches first, then again for DOS matches; i.e. DOS matches will be used, but only if there are no exact ones. Sorry the patch is difficult to read - you'll see the point if you compare the patched an non-patched versions visually. In any case this is relatively minor and we can live without. If we don't patch, we need to be prepared that other people stumble into the problem I had, though. I am still feeling dumb - my wine development was practically stuck for 2 months because of that "wine" file. Martin Index: dos_fs.c =================================================================== RCS file: /home/wine/wine/files/dos_fs.c,v retrieving revision 1.117 diff -u -r1.117 dos_fs.c --- dos_fs.c 27 Aug 2002 01:13:59 -0000 1.117 +++ dos_fs.c 29 Aug 2002 08:34:51 -0000 @@ -746,31 +746,53 @@ return FALSE; } - while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) + if (ignore_case) { - /* Check against Unix name */ - if (len == strlenW(long_name)) + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) { - if (!ignore_case) + /* Check against Unix name */ + if (len == strlenW(long_name) && !strncmpiW( long_name, name, len )) + goto found; + + if (dos_name[0]) { - if (!strncmpW( long_name, name, len )) break; - } - else - { - if (!strncmpiW( long_name, name, len )) break; + /* Check against hashed DOS name */ + if (!short_name) + { + DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); + short_name = tmp_buf; + } + if (!strcmpW( dos_name, short_name )) goto found; } } - if (dos_name[0]) + } + else /* ignore_case ("unix" file system): try to find exact match first */ + { + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) + if (len == strlenW(long_name) && !strncmpW( long_name, name, len )) + goto found; + + DOSFS_CloseDir( dir ); + dir = DOSFS_OpenDir( DRIVE_GetCodepage(path->drive), path->long_name ); + + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) { - /* Check against hashed DOS name */ - if (!short_name) + if (dos_name[0]) { - DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); - short_name = tmp_buf; + /* Check against hashed DOS name */ + if (!short_name) + { + DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); + short_name = tmp_buf; + } + if (!strcmpW( dos_name, short_name )) goto found; } - if (!strcmpW( dos_name, short_name )) break; } } + +found: + DOSFS_CloseDir( dir ); + if (ret) { if (long_buf) WideCharToMultiByte(DRIVE_GetCodepage(path->drive), 0, @@ -787,7 +809,6 @@ } else WARN("%s not found in '%s'\n", debugstr_w(name), path->long_name); - DOSFS_CloseDir( dir ); return ret; } -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Aug. 29, 2002