wine-devel

wine-devel@winehq.org

15 participants
84452 discussions

RE: Added H_SRCS (used by msvcmaker)
by Patrik Stridvall 29 Aug '02

29 Aug '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps files such as include/winuser.h should be included > > for USER32 for example? > > > > Anyway what do you think about adding H_SRCS to > > every Makefile.in file? > > I don't think we want that, especially if you want to add all relevant > includes it's going to be a nightmare to maintain. Yes, I'm a little worried about that myself, but then the C_SRCS doesn't change that often and the H_SRCS are likely to change MUCH less. Futhermore it doesn't really matter if it out out sync either. If somebody developing in MSVC misses a file he can add it. It not like Wine won't build correctly. > And make depend (or > some perl equivalent) can easily determine that information for you. Well, if you just want all .h files the DLL depends on MSVC already have that in a automatically generated "folder" called External dependencies. The H_SRCS is mostly for the .h files that you are likely to want to look at or modify while developing the DLL under MSVC. But it is not strictly nessary. It is more a convenience sort of thing. Another reason that I proposed it is that maybe H_SRCS could be used fo something else though I can't think of anything right now... But sure I can search for the .h files in the director{y,ies} of each DLL. However for a DLL like ntdll files like include/wine/exception.h is very much relevent and won't be included is such a case. Not that it really matters that much but still...

1 0

Re: Added H_SRCS (used by msvcmaker)
by Alexandre Julliard 29 Aug '02

29 Aug '02

Patrik Stridvall <ps(a)leissner.se> writes: > Perhaps files such as include/winuser.h should be included > for USER32 for example? > > Anyway what do you think about adding H_SRCS to > every Makefile.in file? I don't think we want that, especially if you want to add all relevant includes it's going to be a nightmare to maintain. And make depend (or some perl equivalent) can easily determine that information for you. -- Alexandre Julliard julliard(a)winehq.com

1 0

WineDbg and sources
by Fabian Cenedese 29 Aug '02

29 Aug '02

Hello If WineDbg stops it tries to show the actual source line. With my files it always says "Unable to open file X" Looking into debugger/source.c I found that it always bails out after stat (returns -1). This seems like it can't find the file. But if I use wine wcmd I can go there without a problem. My guess is that stat is a Unix tool and therefore case sensitive so this could arise a problem. But still after trying out different cases it could never find my source files. The code looks good as does the (windows-) path it is looking for the file. The only reason is the failing return value of stat. Is it important if the files are Dos/Unix style? (Kate says it's Unix). Does anybody have any ideas? Thanks Fabi

2 1

Wine Status
by tom 29 Aug '02

29 Aug '02

Hello , The Wine Status page located here : http://www.winehq.com/about/index.php?status Has gone for about one year now with out updates and I have volunteer'd to work on bringing this page up to date. I am new to the Wine Project and I am in need of some assistance to make sure all changes are corrct and accurate. Over the next week or so I plan to read over the change log's for the last year so I will have a feel of the changes that have been made. If current Users/Developers could send me changes that they are aware of I will start a log of changes against the current page. If anyone is willing to help me with this I would be most appreciative . Thomas Wickline

2 1

Menu patch breakage
by Rein Klazes 29 Aug '02

29 Aug '02

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

2 1

GetObject with empty buffer
by Fabian Cenedese 29 Aug '02

29 Aug '02

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

2 1

heise online: Tumultuous Response to Alleged Change in MP3 Licensing Conditions
by Thomas Rösch 29 Aug '02

29 Aug '02

>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@ct.heise.de -------------------------------------------------------------------- Copyright 2002 by Verlag Heinz Heise

1 0

Re: Return value GetStockObject
by Fabian Cenedese 29 Aug '02

29 Aug '02

> > 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

1 0

RE: removing mp3 code
by Patrik Stridvall 29 Aug '02

29 Aug '02

> 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...

1 0

(HELP) cannot run tests anymore
by Martin Wilck 29 Aug '02

29 Aug '02

$ make test /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so' make: *** [tests/alloc.ok] Fehler 1 What am I doing wrong? I have tried this and that, but I don't seem to be able to run the tests. This happens for any tests I try. It seems that wine isn't looking for "tests/kernel32_test.exe.so" below the current directory. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel