February 2001 - Wine-Devel - list.winehq.org

Re: annoying EndDialog "feature"

by gerard patel

At 10:37 AM 5/2/01 -0600, you wrote: >> I can't see this WM_NULL with Winsight. Maybe it's a bug in >> Winsight :-/, but are you sure it's not some framework that is >> sending it ? >Hmm, what are you talking about ? > >And I don't quite understand what you're investigating here... ;-) *I* don't understand what it is supposed to fix. Using Winsight was a rather brainless attempt to see what is happening under Windows. Now I think I see : this can only be useful if EndDialog is called from another thread, right ? If yes, you really *should* mention this in the remark before the code. No need to be mysterious IMHO. Anyway, I tested your patch with a thread I launched before the DialogBox call; after 15" of sleep the thread is calling EndDialog. To add fun I added a WM_NULL handler in the dialog procedure to display a MessageBox; under Windows the MessageBox does not fire, under Wine with your patch, it does (test app available) So probably Windows does not do it this way (or the WM_NULL message is filtered). It probably does not matter much, granted. Gerard

Feb. 5, 2001

Re: Reverse engineering court decision

by Patrik Stridvall

> "Paul E. Merrell" wrote: > > > "Hypothetically, similar efforts taken by others to > > reverse-engineer Microsoft Windows could be deemed justifiable > > if the aim of those efforts were to make other companies' > > programs, designed for Windows, run on an operating system > > other than Windows. This assumes that the 9th Circuit ruling > > holds up." [snip] > As Paul mentioned in the quote he selected, the key item > involves moving an application to a > different platform. Application "portability" may legally no > longer require "porting"! It may > instead allow for "OS Compatibility Layers" to be written > instead. This may also drive a needed > wedge into the notion of migrating applications into the OS, > a strategy MS has evolved into a fine > art. One thing that is important to note is unless you do an internal redesign of your application "porting" will involve some sort of compabillity layer. The difference is whether you have it distributed as part of your application or whether you distribute it seperately. In fact Wine can, in some meaning be both, depending whether you use Wine to run the PE executable or whether you dynamically link with Winelib or whether you statically link with Winelib. In short if you try do make a legal difference between different kind of porting you will get all sorts of logical inconsistancies. > This affects far more than Wine: One project that comes to > mind is MAME (games). There are many > more seemingly similar projects that are NOT affected, such > as MOL(Mac-on-Linux), Win4Lin, Plex86, > VmWare and probably several others that actually run the > target OS, not emulate (clone) it. > > An extreme interpretation of this decision could be as > follows: If I need a reason to legally > clone a new feature in some market-leading desktop OS, all I > need to do is find an app (any app) > that uses that feature, then declare my intent to make that > app run under some other (any other) > OS. It does not matter if the feature being emulated is > "documented" or not. Taken further, it One thing to note is that "documented", as I guess you suggest by quoteing it, is a very vague term. If you are intelligent and knowledgable enough you can simply look at the binary and "read" what it does as accurately, and in some meaning even more so, as a less knowledgable person could read any existing documentation that might even be incorrect. In short trying to make legal differance of what is reverse enginering or what is not has severe problems. > may even be possible to dispose of the specific API used to > implement the feature, and use a > different one instead. > > Eventually (assuming this decision survives), the courts will > see that ALL such forms of reverse > engineering should be legal WITHOUT the necessity of an app to port. Probably, any alternative will have either severe logical problems or will be complete arbitrary, I think. > However, this notion still needs to be more fully explored > via additional cases before its full > scope can be determined. Presently, the scope appears to be > very restricted: The article points > out that the DeCSS decision would probably not be affected in > any way. In the current > environment, this is probably true. But what if you can > convince the courts to view DVD "content" > as a "program"! While this may seem obviously true to > technical folks, especially those who > create multimedia apps and content for a living, it may take > many visits to court to properly > communicate this understanding to the legal system. I think from the legal defintion of a program in US Law it should be obvious for a court as well. I don't remember exactly what it said but a remember making that reflection when I read it. > Anyway, since most of the available content security systems > ARE software, and MS has already > migrated theirs into the latest versions of Windows, this > entire issue already has the potential > to snowball completely out of the control of OS and content > companies, and possibly even Congress > itself. > > With the major media companies trying to tie software > protection and content protection together > under copyright law (via laws such as DMCA and UCITA), this > may be just the wedge needed to pry > them back apart. Note that the issues of the legallity of Wine and DeCSS is connected in an abstract sense. Among them the Amicus Brief from the 65(!) Law Professors in the DeCSS argued that forbidding DeCSS, regardless of whether it violates the first amendment or not, lies outside the scope of the power of the Congress because of the 10th amendment. Following the same reasoning then _all_ reverse engineering obviously does so as well. > One can only hope, and patiently wait for the court decisions... Personally I don't worry that much. First of all I live in Europe secondly any kind of regulation of these kind of issues will IMHO be either logically inconsistant or completely arbitrary. Neither of the cases are likely to survive in the long run for several reason among them. 1. Constitional/"Human rights" reasons 2. Legal enforcement is close to impossible 3. It is unlikely to serve the public good

Feb. 5, 2001

Re: Baldurs Gate 2 near perfect with transgaming and disk change problem

by Uwe Bonnes

FT Rathore writes: > Hi > > After applying latest transgaming patch, Baldurs Gate 2 works real nice > with wine and oss (Commercial) drivers, there are still underruns but > sound seems pretty good. Alsa drivers still not working well. > > That brings us to the problem of playing multidisk games. How does wine > plan to deal with disk change. BG2 is spread on 3 disks and you need to > change em prety often. Try copying the first CD to disk and start from disk. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 5, 2001

Re: annoying EndDialog "feature"

by Andreas Mohr

On Mon, Feb 05, 2001 at 02:10:21PM +0100, gerard patel wrote: > At 08:52 PM 30/1/01 +0100, you (Andreas Mohr) wrote: > <snip> > >Just send WM_NULL to unblock the dialog's message loop after setting DF_END. > > I can't see this WM_NULL with Winsight. Maybe it's a bug in > Winsight :-/, but are you sure it's not some framework that is > sending it ? Hmm, what are you talking about ? And I don't quite understand what you're investigating here... ;-) Andreas Mohr

Feb. 5, 2001

Baldurs Gate 2 near perfect with transgaming and disk change problem

by FT Rathore

Hi After applying latest transgaming patch, Baldurs Gate 2 works real nice with wine and oss (Commercial) drivers, there are still underruns but sound seems pretty good. Alsa drivers still not working well. That brings us to the problem of playing multidisk games. How does wine plan to deal with disk change. BG2 is spread on 3 disks and you need to change em prety often. FT

Feb. 5, 2001

Re: annoying EndDialog "feature"

by gerard patel

At 08:52 PM 30/1/01 +0100, you (Andreas Mohr) wrote: <snip> >Just send WM_NULL to unblock the dialog's message loop after setting DF_END. I can't see this WM_NULL with Winsight. Maybe it's a bug in Winsight :-/, but are you sure it's not some framework that is sending it ? Gerard

Feb. 5, 2001

Re: Re: recording sound?

by Eric Pouech

>winmm wave recording is supposed to be supported, at least at the >low-level wave API level. Maybe less so at the MCI level, though, support at the MCI level should be more or less ok... (at least the Macadamiam folks did a great effort there) >and not >supported at all yet in the DirectSound layer. What kind of API does it >use to record these sounds? You don't say what kind of app it is... post the output of runnnig with the -debugmsg +wave,+mciwave,+dsound would help us pinpointing the issue A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 5, 2001

Re: psdrv: map Courier New to Courier

by Huw D M Davies

On Mon, Feb 05, 2001 at 01:31:08AM +0600, Ian Pilcher wrote: > Huw D M Davies wrote: > > > > We don't need to worry about compatibility with the native drivers to > > this extent (this data is private to the driver), I was just using > > this as an example to how a native driver does save its data. > > I'm glad you feel that way. I've implemented it as: > > [...\Printers\<printer name>\PrinterDriverData\FontSubTable] > <Windows font name>=<PostScript font family> > <Windows font name>=<PostScript font family> > . > . > . > > > It doesn't matter: TTFontSubTable is what the native M$ driver uses, > > but we can use anything you like. Calling OpenPrinter is fine within > > the driver - it only really retrieves a printer handle. > > Well, I couldn't get GetPrinterData to work. The driver would compile > OK, > but Wine was unable to load the driver, because it couldn't resolve the > 'GetPrinterData' symbol. (Probably something I did wrong.) You'd need to add the line import winspool.drv to wineps.spec Actually since you're storing the data as many values under a separate key would you mind moving the key to [..\Printers\<name>\FontSubTable] (i.e. get rid of the PrinterDriverData elememt), this will mean the GetPrinterDataEx will still be able to access the data (I really think that we should eventually use these APIs as hard coding the ..\Printers\<name> bit into the driver offends me ;) ). > Is it actually possible to just go in and edit them? I always figured > those numbers at the end of the key names were some sort of checksums > that would get messed up. The numbers are modification times, so it's safe to play with the values. > I was also under the impression that we would actually be reading the > font substitution table from the Windows PostScript driver. Since those > substitutions might not be appropriate for the Wine environment, I felt > it was important to provide the user with a way to override them. As > long as we keep WINEPS's data private, I agree. No (or is that Yes?), this is definitely private to a given instance of wineps.drv. > I absolutely agree. I see the manual mapping of X fonts to Windows > font names as an interim step in that direction. > > While I was playing with the registry, I moved the PPD file > specification > into the PrinterDriverData key, so the driver should support multiple > printers fairly well. Good. Actually it's hacked into the Devmode too, but this is ugly and I'll get rid of it. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1(a)physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK

Feb. 5, 2001

Re: recording sound?

by Ove Kaaven

On Mon, 5 Feb 2001, Thomas Flynn wrote: > Has anyone tried recording sound? It works fine under Linux (with grecord > for example), but I have I windows app that does a pretty simple record > and playback. Audio playing is fine, but recording fails (I get a stupid > meaningless windows dialog that says recording failed and that the error > code was -8602 or something). I was just wondering if perhaps recording > hasn't been touched yet, or whether I had run across a special case that > isn't handled yet. winmm wave recording is supposed to be supported, at least at the low-level wave API level. Maybe less so at the MCI level, though, and not supported at all yet in the DirectSound layer. What kind of API does it use to record these sounds? You don't say what kind of app it is...

Feb. 5, 2001

Re: debugger fix

by Jon Griffiths

Hi, > Perhaps it'd be nice to tie up all these memory issues with some kind > of kernel patch... a way to read/write and generally mess with another > process's memory that was broader and more efficient that p-trace. Something like that would be great for Linux, not sure how it could work with closed unices though. I've been trying to figure out the server and it does't look like anything currently implemented does anything like I wanted to do, so you're right, it probably wouldn't get accepted even if it could be used. Maybe I'll find something else to dabble with for now :-/ Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

Feb. 5, 2001