wine-devel

wine-devel@winehq.org

7 participants
84405 discussions

wine regression - win16 file read problem!?
by Rizsanyi Zsolt 30 Aug '02

30 Aug '02

Hi! I have recently upgraded wine cvs and done a recompile and install. But now one of the programs I'm using does not work. My last cvs update was about 2 weeks ago. Its an old dictionary program (win16). It starts up ok, but when it tries to open the dictionary data, it says, that it is not found, and I should specify a location. I have looked at the +file debug channel output, and it does not even contain the location I have specified. Does that mean, that it does not even tries to open the file? Does somebody has some ideas where the problem could come from? Or which debug channel should I turn on to get some info about the problem? I just would like to ask for ideas before I start more serious debugging... Thanks Zsolt

1 0

Re: Wine Status
by Andriy Palamarchuk 30 Aug '02

30 Aug '02

[skipped] > 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. A couple of good sources of information about changes in Wine: 1) Wine Weekly News articles http://www.winehq.com 2) Notes in the release ANNOUNCE file http://cvs.winehq.com/cvsweb/wine/ANNOUNCE Good luck, Andriy Boston, MA, USA __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

3 2

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
by Duane Clark 30 Aug '02

30 Aug '02

Martin Wilck wrote: > > 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. Since I also was stumbled for a long period on a similar problem, due to specifying a "unix" filesystem, perhaps it would be appropriate in the documentation to put some large warnings on that option.

3 3

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

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