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

Re: debugger fix

by Mike McCormack

Hi John, As i understand, Alexandre wants to get rid of the service thread completely. He rejected an async i/o patch of mine that used the service thread on these grounds. The server would also need to wait on the service thread somehow... something else that might be frowned upon. i'm pretty sure that currently there isn't any way to do this except use the service thread though :-( 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. Mike > Is there any reason _not_ to use the service > thread of the target process to perform cross-process ? > virtualAlloc/Protect etc? > > Jon ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +61 2 9427 2196 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

Feb. 5, 2001

recording sound?

by Thomas Flynn

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. thanks, tom -- "Mongooses are famous for their snake-fighting ability, and are almost always victorious because of their speed, agility, and timing and also because of their thick coat."

Feb. 5, 2001

Re: Reverse engineering court decision

by Robert W. Cunningham

"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." > > <http://www.planetit.com/techcenters/docs/security/news/PIT20010123S0001/1?s…> > Unfortunately, this decision applies directly only to those bringing such cases within the California 9th Circuit Court. While other courts may "take note" of this decision, it has not yet risen to the level of a "precedent". Unless, of course, the case gets appealed all the way to the Supreme Court, they decide to hear it, and they then decide to affirm the decision. Then (and only then) would the decision become the law of the land. Until that time, it will likely first have to be pursued on a case-by-case basis in all other Circuit Courts. Which means we can expect all similar cases to avoid the 9th Circuit like the plague so long as they have other venues to run to. 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. 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 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. 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. 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. One can only hope, and patiently wait for the court decisions... -BobC (IANAL, but I'm Perry f*ing Mason in my dreams.)

Feb. 5, 2001

Re: debugger fix

by Jon Griffiths

> So, does anyone have a hint on how to go about supporting > VirualProtectEx/VirtualQueryEx on other provesses? Looking into this, the VirtualEx functions work within the address space of the target process. At user level I can't see any way to support this from the sever or any other process external to the target. What I had in mind was a service thread request that would have the target process preform the call itself. Is there any reason _not_ to use the service thread of the target process to perform cross-process virtualAlloc/Protect etc? 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

The printer setup dialog

by Duane Clark

Howdy, Since I see there has been a fair amount of activity on the printer stuff lately, I thought I would try submitting this patch to hopefully fix some things in the printer setup dialog box. I have been using this patch unchanged for about six months, on a couple of different applications under wine. The patch contains two chunks. The first chunk attempts to fix these problems in the Paper Size and Source combo boxes: 1) Every time the printer setup dialog is opened, the settings are set back to garbage settings. 2) If the paper size or source is changed, and then the printer is changed, the new printer does not get the new size and source settings even though it appears to from the dialog. The second chunk simply attempts to make the Landscape/Portrait buttons do something. They were there and could be clicked on, and all the supporting code for actually printing in a landscape orientation was there, but the actual code for making the buttons invoke something was for some mysterious reason missing. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.34 diff -u -r1.34 printdlg.c --- dlls/commdlg/printdlg.c 2001/01/22 02:13:58 1.34 +++ dlls/commdlg/printdlg.c 2001/02/05 00:13:50 @@ -373,8 +373,30 @@ /* query the dialog box for the current selected value */ Sel = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETCURSEL, 0, 0); if(Sel != CB_ERR) { - oldWord = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETITEMDATA, Sel, - 0); + /* we enter here only if a different printer is selected after + * the Print Setup dialog is opened. The current settings are + * stored into the newly selected printer. + */ + oldWord = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETITEMDATA, + Sel, 0); + if (dm) { + if (nIDComboBox == cmb2) + dm->u1.s1.dmPaperSize = oldWord; + else + dm->dmDefaultSource = oldWord; + } + } + else { + /* we enter here only when the Print setup dialog is initially + * opened. In this case the settings are restored from when + * the dialog was last closed. + */ + if (dm) { + if (nIDComboBox == cmb2) + oldWord = dm->u1.s1.dmPaperSize; + else + oldWord = dm->dmDefaultSource; + } } if (nIDComboBox == cmb2) { @@ -873,6 +895,16 @@ break; } + case rad1: /* Paperorientation */ + if (lppd->Flags & PD_PRINTSETUP) + lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + break; + + case rad2: /* Paperorientation */ + if (lppd->Flags & PD_PRINTSETUP) + lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + break; + case cmb1: case cmb4: /* Printer combobox */ if (HIWORD(wParam)==CBN_SELCHANGE) {

Feb. 5, 2001

Re: debugger fix

by Ulrich Weigand

I wrote: > Eric Pouech wrote: > > > > Could you send me the libwinspool.drv.so file that objcopy > > > is choking on? I'd like to look whether there's something > > > strange with that. > > here it is... (I've used libpsapi.so instead, because it's smaller, but > > effects are the same) > > Well, one difference I see is that yours has a .rel.stabs section, > while mine doesn't. Now I don't quite understand why stabs need > to be relocated, but I guess this could be a source of confusion. > In any case, after I strip the stabs data using objcopy --strip-debug, > I can subsequently use objcopy -N without problems. > > The problem might be caused by the objcopy -L step not correctly > updating the debug info. Could you try adding a --debugging > argument to objcopy in both localize_imports and strip_imports? No, it's definitely a problem with the .rel.stabs section. In fact, *every* invocation of objcopy that leaves the .rel.stabs section in its output fails -- even a simple identical copy. (Note that if you *remove* the .rel.stabs section, it works -- this is why a normal 'strip' works ...) The reason for this is that objcopy relies on the bfd library to assign the file offsets of the sections in the output file. Unfortunately, the automatic assignment is done only for sections that are part of a segment (i.e. loaded into memory), and also for *those* sections outside of segments that are *not* reloc sections ... For reloc sections outside of segments, like the .rel.stabs section, no automatic file offset assignment is performed. Instead, the upper layers must do this themselves, which e.g. the linker does in its final_link step. The objcopy tool, however, never does. This leads to an invalid file offset being used when writing out the .rel.stabs section, which causes the abort. As a side note: I've tried using the --debugging argument, which basically recreates the debug sections from scratch instead of copying them, and this fails completely with my toolchain -- it runs into an endless loop. The reason for this is apparently a compiler bug in gcc 2.95.2 that miscompiles a routine from objcopy by converting a recursive function call into tail recursion in an invalid way ... I still don't understand why your toolchain creates a .rel.stabs section in the first place. Could you check at which point this is created first (as, ld, ld -shared)? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

Feb. 4, 2001

Reverse engineering court decision

by Paul E. Merrell

"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." <http://www.planetit.com/techcenters/docs/security/news/PIT20010123S0001/1?s…> -- Paul E. Merrell, E-Mail: pem(a)televar.com WordPerfect Links: http://www.wpwin.com/links.html WordPerfect Linux Links: http://www.qwkscreen.com/WPLinuxLinks.html WP8 FAQ: http://w3.one.net/~kgibson/wp8faq.htm WP7 Help: http://home.earthlink.net/~tlhuffman/wp7/wp7help.htm Search WP web sites: http://www.wpwriter.com/You_Find_the_Answer/you_find_the_answer.html

Feb. 4, 2001

Re: psdrv: map Courier New to Courier

by Ian Pilcher

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.) I went ahead and used the registry APIs, which really aren't all that bad, as long as you're good at counting NULLs. I'm not sure I could have structured the table as a series of values with GetPrinterData anyway, and I think this will be a lot easier for people to configure. (Neither the Wine registry files or regapi seem to support REG_MULTI_SZ data in a very user friendly way.) > The Wine registry files are ascii, and adding stuff to the registry > can be done via the regapi program anyway. 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. 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. > > I anticipate that most people will just be happy using TT/Type1/.fon > fonts all served by FreeType and will not bother using XLFD fonts at > all. This makes font configuration quite easy, we just tell the > FreeType font driver which font files we want it to serve and that's > it. The psdrv may still want to substitute builtin type1 fonts, but > that seems to me to be psdrv's role and thus its configuration is > unique to that; this becomes more obvious when you think that the user > may install 2 instances of psdrv that print to different printers > which may have different fontsets installed, therefore font > substitution would be on a printer by printer basis. > 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. I'll send my changes in as soon as I've had a chance to get them cleaned up. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 4, 2001

Re: psdrv: map Courier New to Courier

by Huw D M Davies

On Sat, Feb 03, 2001 at 04:18:45PM +0600, Ian Pilcher wrote: > I just spent some time poking around in the Registry of my Windows 2000 > system. Neither "TTFontSubTable" or "FontSubTable" appears anywhere. > (I have printers installed that use both the Adobe and Microsoft Post- > Script drivers.) Try changing an entry in the font sub table. The driver doesn't write anything until you move anyway from the default. > Another point of interest -- none of the printer properties dialogs seem > to allow me to configure the font substitution, even though I have > "TrueType Font: Substitute with Device Font" set in the Advanced Options > of the Apple LaserWriter 12/640 PS driver. My LaserJet 4/4M driver allows you to edit the table in the Device Settings tab of the Property dailog got by going to Control Panel -> Printers, selecting the printer and then doing Printer->Properties. 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. > So is "FontSubTable" what we want to use? It should be easy enough for > me to have the driver use GetPrinterData and set up a simple array when > it is initialized. (Although it does seem a little weird to have the > driver calling OpenPrinter; is this OK?) 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. > > Not really convinced about this. I'd like to move all of the psdrv > > stuff out of the config file (which afterall is just a bit of the > > registry) into its correct place under > > HKLM\System\CurrentControlSet\Control\Printers\Print > > The configuration should all be done via a GUI control. > > Two points: > > 1) How can a user get this information into the Registry until the GUI > control is written? (I hope you weren't thinking that this is some- > think I'm capable of doing. Me stupid procedural guy; OO GUI stuff > make head feel oogey!) > > 2) Just because people use Wine to run Windows applications, doesn't > mean that they've bought into the "everything should be GUI" > philosophy; some of us actually *like* ASCII configuration files. The Wine registry files are ascii, and adding stuff to the registry can be done via the regapi program anyway. > I actually see a manual font configuration as a *very* small step in > this direction. At least it will let Wine control it's view of what > fonts are available, rather than trying to make intelligent guesses > based on the X font list and the PostScript driver. > > It does assume a certain intelligence on the user's part; mapping the > core Windows fonts to X fonts that aren't installed on the system would > be "bad", but it shouldn't be too hard to supply a reasonable default > configuration. I anticipate that most people will just be happy using TT/Type1/.fon fonts all served by FreeType and will not bother using XLFD fonts at all. This makes font configuration quite easy, we just tell the FreeType font driver which font files we want it to serve and that's it. The psdrv may still want to substitute builtin type1 fonts, but that seems to me to be psdrv's role and thus its configuration is unique to that; this becomes more obvious when you think that the user may install 2 instances of psdrv that print to different printers which may have different fontsets installed, therefore font substitution would be on a printer by printer basis. 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. 4, 2001

Re: PATCH: "Manual" trays for ppd

by Huw D M Davies

On Sat, Feb 03, 2001 at 07:21:54PM +0100, Marcus Meissner wrote: > Hi, > > The ppd also has Tray1,Tray2,Tray3 ... Now where should those map to? I think these should go to DMBIN_USER, DMBIN_USER+1, etc. So if the lookup of the standard names fails, we just start allocating bin numbers from DMBIN_USER. 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. 4, 2001