wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

RE: Reverse engineering court decision
by Patrik Stridvall 06 Feb '01

06 Feb '01

> On Tue, 6 Feb 2001, Patrik Stridvall wrote: > > > > Patrik, > > > > > > You are most likely correct. Eventually the court system > > > will get their > > > head out of their ass and figure this out. > > > > I hope so. > > There's optimism for you - they've had their heads there for > years, why > change now? They're just getting comfortable... What do you mean? Who are getting comfortable? The courts? > > > At the moment it > > > seems to me > > > like its way up in there and they are going "Damn, it's > dark in here". > > > > Well, since the DMCA IMHO is logically inconsistant, that > is not very > > suprising. I interpret Judge Kaplan opinion in the DeCSS as "I don't > > really understand this, but if I blame it on Congress and give the > > plaintiff the victory I will probably look less a fool in > the eyes of > > my peers". > > Perhaps. Some of the Slashdot comments on the matter won't > have helped, > though... With peers I was refering to fellow and especially superior court Judges not just anybody that criticized him. What Judge Kaplan basicly said was this is, judging from the letter of the law, what Congress meant and if if they didn't mean this, they should have put it more clearly and if so it is their fault not mine. Shifting blame is quite popular in all sectors of society. :-) > > > Even my dad could easily see the argument that > > > restricting someone from writing a program is really > really braindead > > > (although he has done coding way back in the day). His > > > response was that > > > eventually the court system will figure it out and it'll be > > > over and done > > > with. Seems to be much the same as your response. > > > > Yes, approximately, but don't forget that in the worst case laws can > > be changed and in the meantime enforcing it will be close to > > impossible. > > Indeed. It'll probably survive for a while, but with more and > more holes > being cut... More holes? It is already has holes big as barn doors. :-) One intresting aspect concerning Wine is the DRM (Digital Rights Management) that Slashdot reported that Microsoft are going to add to Windows. If we implement it is Wine we are not trying to circumvent it quite the opposite we are trying to to make it possible enforce it. ;-) Of course a one line patch making a critical function always return TRUE or something might be able to disable it for people that don't like it. :-)

2 1

Re: psdrv: map Courier New to Courier
by Ian Pilcher 06 Feb '01

06 Feb '01

Huw D M Davies wrote: > > Great! Well the Windows 2000 PS driver stores the font sub table > under the value name "TTFontSubTable" in the printer driver's > PrinterDriverData registry key. To do this we need to implement > Get/SetPrinterData (if you give me a couple of days I'll do it). The > data associated with TTFontSubTable is just a set of 2n \0 > terminated strings the final one terminated by 2 \0 > (i.e. REG_MULTISZ). The actual configuring should go on in the > printer setup property sheet. Hmmm, fancy learning a little of the > Win32 api? > 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.) In fact, when I searched on "Helvetica" the only things I found that looked like font substitution tables were under HKCU\Software\Microsoft\ Shared Tools\Font Mapping and HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\FontSubstitutes. 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. > > OK, I've just submitted G|SetPrinterData implementations to > wine-patches - please use these instead of direct Reg apis. (it should > make life easier anyway. > > You basically want > > HANDLE hprn; > OpenPrinterA("Wine PostScript Driver", &hprn, NULL); > SetPrinterDataA(hprn, "FontSubTable" /*or whatever*/, REG_MULTI_SZ, pData, size); > ClosePrinter(hprn); > > where pData is a list of \0 terminated strings that make up the table, > finally terminated by a double \0. > > Reading the data back is almost the same using GetPrinterDataA 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?) > > I think we should also allow the Wine config file to override what's > > in the registry. > > 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. > > In the old style, I would have suggested something of the form: > > > > Windows Font = X LFD, PostScript font name > > > > This would seem to be relatively straightforward to implement, and it > > would bring a small measure of sanity to the area. (I currently have > > both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and > > the PostScript driver don't agree on what the font should be called!) > > This should all be a lot easier when I get a FreeType engine bolted on > to gdi. Then psdrv,x11drv,ttydrv(?) will all have access to the same > data and thus consistancy should not be a problem. 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. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 4

RE: Misc / Unicode
by Patrik Stridvall 06 Feb '01

06 Feb '01

> > I know this comes from from someone who just forgot to put > a trailing > > '\0'. But still. > > Sounds like a job for winapi_check ;-) Yes. However it will not be so easy since winapi_check doesn't have a complete C parser. It currently skips these kind of lines, so don't hold your breath. > BTW, Is Alexandre away? I should guess so. > I haven't seen any cvs commits for a week... Neither have I.

1 0

Re: Misc / Unicode
by Dmitry Timoshkov 06 Feb '01

06 Feb '01

"Francois Gouget" <fgouget(a)free.fr> wrote: > <rant> > I checked the other cases and I have this question. Why does everyone > use 0 instead of '\0', 0 instead of FALSE, and '\0' instead of NULL? MS > even does the reverse and uses NULL in places where '\0' or 0 would have > been more appropriate. Man, if you know what you're doing prove it and > use the appropriate form: either 0, '\0' or NULL. > I know this comes from from someone who just forgot to put a trailing > '\0'. But still. > </rant> IMO it doesn't matter in the most cases, if you do not mix pointer data type (NULL) and others. '\0' == 0, and even better to use 0, because it automatically get casted by the compiler to the appropriate data type.

1 0

Re: Misc / Unicode
by Jon Griffiths 06 Feb '01

06 Feb '01

> I know this comes from from someone who just forgot to put a trailing > '\0'. But still. Sounds like a job for winapi_check ;-) BTW, Is Alexandre away? I haven't seen any cvs commits for a week... 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

1 0

RE: Reverse engineering court decision
by Patrik Stridvall 06 Feb '01

06 Feb '01

> Patrik, > > You are most likely correct. Eventually the court system > will get their > head out of their ass and figure this out. I hope so. > At the moment it > seems to me > like its way up in there and they are going "Damn, it's dark in here". Well, since the DMCA IMHO is logically inconsistant, that is not very suprising. I interpret Judge Kaplan opinion in the DeCSS as "I don't really understand this, but if I blame it on Congress and give the plaintiff the victory I will probably look less a fool in the eyes of my peers". > Personally I am glad there are people that are very > passionate about these > issues because someone has to bitch about it and start > getting normal people > thinking about it. Actually I don't think normal people will understand or care very much until it directly affects them, like why can't I record this TV program. > Even my dad could easily see the argument that > restricting someone from writing a program is really really braindead > (although he has done coding way back in the day). His > response was that > eventually the court system will figure it out and it'll be > over and done > with. Seems to be much the same as your response. Yes, approximately, but don't forget that in the worst case laws can be changed and in the meantime enforcing it will be close to impossible.

2 1

Re: Misc / Unicode
by Huw D M Davies 06 Feb '01

06 Feb '01

On Mon, Feb 05, 2001 at 08:51:45PM -0800, Francois Gouget wrote: > Index: include/richedit.h > =================================================================== > RCS file: /home/cvs/wine/wine/include/richedit.h,v > retrieving revision 1.4 > diff -u -r1.4 richedit.h > --- include/richedit.h 2001/01/22 19:25:27 1.4 > +++ include/richedit.h 2001/01/29 11:01:27 > @@ -15,7 +15,7 @@ > #define cchTextLimitDefault 0x7fff > > #define RICHEDIT_CLASS20A "RichEdit20A" > -#define RICHEDIT_CLASS20W L"RichEdit20W" > +static const WCHAR RICHEDIT_CLASS20W[] = { 'R','i','c','h','E','d','i','t','2','0','W' }; Doesn't this want a trailing 0 ? 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

1 0

Re: Reverse engineering court decision
by Patrik Stridvall 06 Feb '01

06 Feb '01

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

2 1

Strange window message / queue behaviour
by Marcus Meissner 06 Feb '01

06 Feb '01

Hi, I have an application that handles several text edit controls. At one point it flips from the first to the second (after you have entered the fourth character). This is done by a function, which does (simplified) this: { DWORD startsel,endsel; PostMessageA(hwnd1,EM_GETSEL,&startsel,&endsel); SetFocus(hwnd2); PostMessageA(hwnd2,EM_SETSEL,0,0); /* ... */ CallWindowProcA(hwnd,....); return; } According to the +relay,+edit trace the EM_GETSEL is executed way _AFTER_ the return from the function, so, since it uses stackvalues, it then smashes the stack somewhere else. My suspicion is that SetFocus() in Windows drains all posted messages by doing something like: while (PeekMessage()) { TranslateMessage(); DispatchMessage(); } but I do not really know. Does anybody have more knowledge of this? The respective trace is here, starting with the posting of the message with the pointers into the stack: Ciao, Marcus Call user32.455: PostMessageA(000006b4,000000b0,40599904,40599908) ret=0041a99b fs=008f Ret user32.455: PostMessageA() retval=00000001 ret=0041a99b fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041a9ab fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041a9ab fs=008f Call user32.527: SetFocus(0000074c) ret=0041a9b2 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_KILLFOCU S,wp=0000074c,lp=00000000) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,00000008,0000074c,00000000) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_KILLFO CUS,wp=0000074c,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=020007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=020007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=020007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=020007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_KILLFO CUS,wp=0000074c,lp=00000000) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_KILLFOCU S,wp=0000074c,lp=00000000) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=0000074c,msg=WM_SETFOCUS ,wp=000006b4,lp=00000000) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041aa7c fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041aa7c fs=008f Call user32.21: CallWindowProcA(41060311,0000074c,00000007,000006b4,00000000) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=0000074c,msg=WM_SETFOC US,wp=000006b4,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=010007d7,lp=0000074c) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=010007d7,lp=0000074c) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=010007d7,lp=0000074c) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=010007d7,lp=0000074c) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=0000074c,msg=WM_SETFOC US,wp=000006b4,lp=00000000) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=0000074c,msg=WM_SETFOCUS ,wp=000006b4,lp=00000000) retval=00000000 Ret user32.527: SetFocus() retval=000006b4 ret=0041a9b2 fs=008f Call user32.254: GetDlgItem(000002bc,000007d7) ret=0041a9cc fs=008f Ret user32.254: GetDlgItem() retval=0000074c ret=0041a9cc fs=008f Call user32.455: PostMessageA(0000074c,000000b1,00000000,00000000) ret=0041a9d3 fs=008f Ret user32.455: PostMessageA() retval=00000001 ret=0041a9d3 fs=008f Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,00000102,00000048,00230001) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_CHAR,w p=00000048,lp=00230001) trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=040007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=040007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=040007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=040007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=030007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=030007d6,lp=000006b4) trace:relay:WINPROC_CallWndProc (wndproc=0x41ae53,hwnd=000002bc,msg=WM_COMMAND, wp=030007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40702990,hwnd=000002bc,msg=WM_COMMAN D,wp=030007d6,lp=000006b4) retval=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=WM_CHAR,w p=00000048,lp=00230001) retval=00000000 Ret user32.21: CallWindowProcA() retval=00000000 ret=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=WM_CHAR,wp= 00000068,lp=00230001) retval=00000000 After this it directly returns from the function. trace:relay:WINPROC_CallWndProc (wndproc=0x41a73f,hwnd=000006b4,msg=EM_GETSEL32 ,wp=40599904,lp=40599908) Call user32.254: GetDlgItem(000002bc,000007da) ret=0041aa40 fs=008f Ret user32.254: GetDlgItem() retval=000004e4 ret=0041aa40 fs=008f Call user32.254: GetDlgItem(000002bc,000007d6) ret=0041aa5e fs=008f Ret user32.254: GetDlgItem() retval=000006b4 ret=0041aa5e fs=008f Call user32.21: CallWindowProcA(41060311,000006b4,000000b0,40599904,40599908) r et=0041aa26 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=EM_GETSEL 32,wp=40599904,lp=40599908) trace:relay:WINPROC_CallWndProc (wndproc=0x406dcf00,hwnd=000006b4,msg=EM_GETSEL 32,wp=40599904,lp=40599908) retval=00040004 Ret user32.21: CallWindowProcA() retval=00040004 ret=00000004 fs=008f ... but still uses its stack values here. faulted at EIP=0x00000004, CR2=0x00000004, EAX 0x00040004 EBX 0x407936fc, ECX 0x00000001, EBP 0x40599950 EDI 0x40599904, ESP 0x002b:0x40599908 FS 0x008f, pid 1772

3 2

Re: Strange window message / queue behaviour
by gerard patel 06 Feb '01

06 Feb '01

At 12:00 AM 6/2/01 +0100, you wrote: >last paragraph), there's also the possibility that Windows recognizes that >it's a message known to contain pointers, and so just drops the message, >so that EM_GETSEL is simply never dispatched? Indeed under NT4 such a call is discarded by Windows (returns 0, error is set to ERROR_INVALID_PARAMETER) Gerard

1 0

Jump to page:

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