wine-devel

wine-devel@winehq.org

10 participants
84461 discussions

winelib and active-X dll´s
by christian richter 16 Feb '01

16 Feb '01

hello, has anyone an idea how I can use Functions from Active-X dll´s in my C-programm? those dll´s seem to export com-objects or classes, and i do not know how to use those classes... is it possible ? how `?

1 0

Re: VerQueryValue[A|W]
by François Jacques 16 Feb '01

16 Feb '01

James, Where's HEAP_strudupAtoW called from? For all OLE/COM DLLs, strings should be internally stored as OLECHAR* (wchar_t*) strings. I remember it wasn't the case with typelib.c when I started playing with it. A side-effect of that is that we had to HEAP_strdupAtoW / HEAP_strdupWtoA all over the place in that file - making ASCII-based stored strings more expensive than OLECHAR*-based strings (yeah yeah we're still converting back to ASCII strings a lot, but that's for tracing - not run-time) For all OLE/COM DLLs, I would internally store the strings as OLECHAR* strings (or BSTR, as you wish...) wherever it makes sense to do it, e.g. most places. Cheers, Francois -----Message d'origine----- De : James Hatheway <james(a)macadamian.com> À : amohr(a)codeweavers.com <amohr(a)codeweavers.com> Cc : WineHQ Devel <wine-devel(a)winehq.com> Date : 15 février, 2001 10:44 Objet : Re: VerQueryValue[A|W] >> > To convert an ASCII string to Unicode, you can use the >> > function HEAP_strdupAtoW, as in: >> Wrong ;-) > >Yeah, I know, Huw already set me straight on that. ^_^ > > >> HEAP_str* is deprecated (the header file says so). >> Use MultiByteToWideChar() or WideCharToMultiByte() instead. > >I'll admit I wrote the email when my brain wasn't quite >working (by def'n anytime after 1am), thought to >myself "what is that API again?", did a quick search in >WINE, said to myself "oh HEAP_strdupAtoW" >sent a quick email and went to bed. :) That teaches me to >send email without thinking. > >But that gets me to my point. HEAP_strdupAtoW is used in >this capacity 78 times in the WINE source tree (WtoA another >182 times). We should probably change it sometime, since a >lot of people who are writing new code are sure to use >the current code base as an example of "how to do things". > >Out of curiosity, why are we killing these macros? They >seem quite convenient. If it is because they aren't in >standard windows headers, can't we put them somewhere >in include/wine? > > >-James > >-- >James Hatheway >Software Designer - Macadamian Technologies, Inc. >james(a)macadamian.com ~ http://www.macadamian.com > > "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" > "One could be happy if the air were as pure as the beer" > > > >

2 1

Re: GetPixel bug!!!
by Ove Kaaven 16 Feb '01

16 Feb '01

On Fri, 16 Feb 2001, François Gouget wrote: > I just wanted to avoid copying the pixmap back into the DIB for the > GetPixel case since obviously it has not been modified. That's what > commit is here for of course. OTOH the subtleties of lossy are a bit > lost on me. AFAICS it's always set to false so I'll just do the same. The "lossy" is only meant for extreme optimization cases - "lossy" suppresses the copying entirely, and is only meant to be useful when some operation would completely overwrite/obliterate everything on the DIB surface anyway, for example, a SRCCOPY blit that'd cover the entire destination DIB. In such cases, it'd just be a waste to do a copy only to have all of the copied data overwritten, it would be more efficient to not copy anything then. But such optimization checks isn't being done yet. I think the reason GetPixel/PutPixel hasn't done DIB updates yet is because it's wasteful to copy the entire DIB graphic back and forth for a single pixel, when it should really be easy to add code that could access the DIB data directly... just that nobody did that yet. We're going to need a proper DIB (aka FB) graphics engine someday...

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall 16 Feb '01

16 Feb '01

> > I think you have missunderstood what the judges meant. > > > > The fact the computer programs are functional doesn't take away > > their copyrightabillity. But copyright only protects the creative > > expression and then the form of these expressisions are dictated > > by external factors such as in the courts words "compatibility > > requirements and industry demands" they are not creative expression > > and thus not copyrightable. > > > > It almost sounded to me as if they were saying that it was purely > functional. But then again I didn't read it really > carefully. The correct > representation is that they are creative but then yield a > function. The > creative part (the source code) should be copyrightable, but > the actual > functionality should not be, and it should be perfectly legal > to duplicate > the functionality of a piece of code so long as you do not > actually verbatim > copy the copyrighted source code. Exactly. > Protecting the functionality would be an issue for patents and not > copyrights. And with the exception of things like the RSA > patent, software > patents for the most part have not been working. Of course, IIRC the > RSA patent is not actually a software patent but a patent on > a hardware > implementation of the algorithm. Note quite, patents do not protect functiality, they protect a specific way to achieve a certain functionality. For example, you could, providing software patents are valid, patent a specific algoritm that sorts list, but you can't patent all algoritms that have the same functionallity, is this cases that sorts list. Patents are for promoting progress by finding new and better way of achieving some specific functionality. The functionallity (end result) is itself it an idea and not protectable. > > Not that fact that the court said "functional" and not > > "is not a creative expression" is AFAICS largely irrelevant. > > > > But I think I can see what you are after, I you have an "optimal" > > compiler every computer program that are functionally equivivalent > > will be reduced to the same binary form. However that doesn't rob > > the source code from copyright, just the binary form. > > > > Binaries should only be copyrightable in the sense that doing > a verbatim > copy (e.g. copy file.exe newfile.exe) should be protected, Careful, we definitely don't want copyright law to mean that. There have been some strange cases involving whether the representation of the program in memory is a copy. While running an application obviously falls under fair use, such a view might be unfortunate since it like the DMCA will lead to logical contradictions which will enable scrupelus persons to use the confusion in legal arguments. IMHO the only sane definition of copy in the meaning of copyright is something is a copy (or a potential copy) if it is made with the intent to distribute. With potential copy I mean for example offering a protected work for download on a website or on Napster or where ever. All other defintion will lead to logical contradictions AFAICS. For example, if I look at protected work, have a copy been made in my eyes? If I have a camera attached to say my glasses that broadcast everything I see on a website will I be a copyright infringer if I look at a protected work. Without having intent as condition you can nail anybody for copyright infringement. > but if the > compiler happens to generate an exact copy, then so be it. Yes, but two works that are the same or similar by coincidence have never been considered copyright infringment. What I meant is that if the representation is optimal it will be purely functional and thus not protectable at all since copyright doesn't protected that. However since optimal compilers doesn't exist, this distinction is rather meaningless, the binary will always retain some of protected creative expression and thus be protectable as a whole.

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall 16 Feb '01

16 Feb '01

> > The court in that case said: > > > > Computer programs pose unique problems for the > application of the > > "idea/expression distinction" that determines the > extent of copyright > > protection. To the extent that there are many possible ways of > > accomplishing a given task or fulfilling a particular > market demand, > > the programmer's choice of program structure and design > may be highly > > creative and idiosyncratic. However, computer programs > are, in essence, > > utilitarian articles -- articles that accomplish tasks. > As such, they > > contain many logical, structural, and visual display > elements that are > > dictated by external factors such as compatibility requirements > > and industry demands... In some circumstances, even the > exact set of > > commands used by the programmer is deemed functional rather than > > creative for the purposes of copyright. When specific > instructions, > > even though previously copyrighted, are the only and > essential means > > of accomplishing a given task, their later use by > another will not > > amount to infringement. > > > > Hmm, I am not so sure I like all of that. Program code > serves two purposes. For one > thing it is functional, and for another (and actually for the > most part) it has a > human readable structure. I think you have missunderstood what the judges meant. The fact the computer programs are functional doesn't take away their copyrightabillity. But copyright only protects the creative expression and then the form of these expressisions are dictated by external factors such as in the courts words "compatibility requirements and industry demands" they are not creative expression and thus not copyrightable. Not that fact that the court said "functional" and not "is not a creative expression" is AFAICS largely irrelevant. But I think I can see what you are after, I you have an "optimal" compiler every computer program that are functionally equivivalent will be reduced to the same binary form. However that doesn't rob the source code from copyright, just the binary form. Anyway, regardless of whether optimal compilers possible, it still doesn't make copyright of computer programs meaningless, since you really want to be able to change the computer program and an optimal representation of it is not very easy to change. :-) So the creative expression of the source code is really useful and thus promotes progress, so it really should be and indeed is protectable.

2 1

RE: Turkish Keybard
by Nerijus Baliunas 16 Feb '01

16 Feb '01

> Adding a turkish keyboard layout. > > -aric Why do you use 28591? Shouldn't it be 28599?

1 0

Re: msvcrt/c++
by Alexandre Julliard 15 Feb '01

15 Feb '01

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > This is a resubmit of the previous patch. It now manages to do the > setjmp/longjmp stuff 90% in C rather than asm. It also implements setjmp3 > which is needed for programs compiled with VC++ v4.0+, and it should fix the > compilation problem reported on cemw. You should _really_ use register functions instead of inline assembly. Then you can do setjmp/longjmp 100% in C. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 15 Feb '01

15 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > Definitely a drawback, I agree. But the shared memory area could be relatively > high in the address space, so that a stray pointer is much more likely to run > into unmapped memory and segfault before overwriting crucial data. This is only one failure case, but there are many others; for instance stack corruption that causes the app to jump somewhere inside ReleaseMutex, which will then happily modify the right address in the wrong way. > The only way we're going to be able to get both speed and safety though is > to have some kernel support. While that's beyond the scope of what I'd like > to accomplish in the short term, I think that it's something worth thinking > about more. While the solution proposed by David Howells may be overkill, I'm > not sure that simply changing the communication mechanism as you suggested > (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - > we'll still have the context switch overhead. The main problem is the TLB flush due to switching address spaces; but I don't see any way to avoid this if we want memory protection (which we definitely do). The only way to know if we can make it fast enough is to implement it and benchmark it... > At least in the case of mutexes, I believe that all we need to do is > make sure that the count field is always modified through interlocked > increment/decrement/etc including the wineserver. I think you underestimate the complexity of getting this right. For instance, how do you determine the address of the count field from the mutex handle, keeping in mind that handles can be manipulated from other threads or even other processes (cf. DuplicateHandle)? How do you cope with a thread dying in the middle of an operation? Of course you can ignore all these special cases, and it will even work most of the time. But it's clearly not a viable general solution... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 15 Feb '01

15 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > After some more thinking, Ove and I have come up with a mechanism that should eliminate > most of the wineserver overhead for mutexes and semaphores, without the need to resort > to a kernel module. We're probably going to give this a try over the next few days, so > any feedback will be very much appreciated. I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important. As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dlls/ntdll/debugtools.c patch
by Alexandre Julliard 15 Feb '01

15 Feb '01

Chris Morgan <cmorgan(a)wpi.edu> writes: > Resubmit of this patch. Alexander, is this patch ok? Looks good, but I wonder if we shouldn't add an assert() instead. People are not supposed to use the debug interface to print out huge strings, and printing partial lines messes up the output in multi-threaded programs. -- Alexandre Julliard julliard(a)winehq.com

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