wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

Re:Re: native dll's
by José Soriano Díaz 27 Jul '01

27 Jul '01

>From: Francois Gouget <fgouget(a)free.fr> >To: José Soriano Díaz <jose__sor(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: native dll's >Date: Thu, 26 Jul 2001 10:10:17 -0700 (PDT) > >On Wed, 25 Jul 2001, José Soriano Díaz wrote: > > > > > Hi there, I'm working in a telerobotics project and I need to >link a > > windows dll in order to use a Cybernet Joystick. > > First I tried to use the winAPI functions LoadLibrary, > > FreeLibrary and GetProccessAddress as I were working on Windows, and > > I recompiled my program with winelib: > > *. winemaker /my_path/ > > *. ./configure > > *. make all > > but it didn't create any executable, what I obtained was a > > lib*.so, because winemaker thought I was trying to compile a dll, > > not to use one. > > To force winemaker to generate an executable simply use it as >follows: > * type "winemaker --cuiexe /my_path" to indicate a console executable > * type "winemaker --guiexe /my_path" to indicate a graphical executable > > You can also use "winemaker -?" to get a list of options supported by >winemaker. > > > > So my question is quite siple How can I link a native dll in > > a Unix project? > > I think you have used the right approach: LoadLibrary / >GetProccessAddress / FreeLibrary. If that works for you then it's the >simplest approach. I'm afraid it doesn't work, when I executed what I compiled , I obtained "Undefined Symbol" in any call to the native dll. Thanks anyway for the advice. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

2 1

[Fwd: Re: Any use for glyph bounding boxes in printer driver?]
by Ian Pilcher 27 Jul '01

27 Jul '01

Travis Michielsen wrote: > > What about GetCharABCWidth* what does this function use? (or could it use > this?) I see the function still shows a fixme (or atleast the last time I > checked). > The only one that works for printer fonts is GetCharABCWidthsFloat. I just tested it on Windows 2000 and verified that it always returns 0 for abcfA and abcfC (and returns the advance width in abcfB) when it is called on a printer font. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: ChangeDisplaySettings
by Travis Michielsen 27 Jul '01

27 Jul '01

--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > > This patch partially implements the ChangeDisplaySettings* functions. > > Well, I am 100 % sure that Alexandre will reject it :-) :-\ > If you want to do something like that, you need to implement the feature in > the X11 driver and then call it via the 'USER_Driver.pFunctionName' > protocol. Hmm, I was going to try something like that, however, I had problems with that method simply b/c of the load order between the dlls. ChangeDisplaySettings is implemented in user32.dll which loads BEFORE x11drv. This makes it impossible to initalize the function with the user32.dll. However, with DDraw, the x11drv.dll is loaded before the ddraw.dll! The only way I saw to exchange info was to initialize the function with a call from x11drv.dll. If you can suggest an alternative that takes load order into account I will likely use it. > Moreover, there are already some DDraw-related mode change functions (in > dlls/x11drv/xvidmode.c). This should be factorized between both code. Already using so of that code, although it could probably be cleaned up a bit. I will get to that soon. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

2 2

Re: How do I stop clipping?
by Travis Michielsen 27 Jul '01

27 Jul '01

--- Bill Medland <medbi01(a)accpac.com> wrote: > I don't like submitting incomplete code but I may have little choice unless > someone can point me in the correct direction here. As you may guess from > the following, my Windows experience is not that extensive but I think it's > enough to allow me to make sensible contributions. > > I am working on correcting the LISTVIEW_DrawLargeItem function, especially > when the item text is large. I have already got most of the way. However > the problem is this. > > When a user selects a large icon the text should be written completely (by > calling DrawText with DT_NOCLIP). It is doing so; I can prove it by > resizing the window and I will see the full text being displayed for a > selected item. However when drawing it at the moment of selecting it, the > text is being clipped to the usual two and a bit rows. Presumably this > means that there is a clipping rectangle in the DC or the window that I > need to inflate. Or Do I simply invalidate that rectangle (from within the > WM_PAINT handler!!!). > > Any help would be appreciated. > > Bill Looking at the DrawText code I see that DrawText just passes the NOCLIP flag to ExtTextOut, so the problem I likely not with DrawText but with ExtTextOut instead. I can take a look at the code for both functions (time providing) and find out what is happening. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

1 0

Any use for glyph bounding boxes in printer driver?
by Ian Pilcher 27 Jul '01

27 Jul '01

Currently, the Wine PostScript driver stores the bounding box (xMin, yMin, xMax, yMax) for every glyph in every font. This information is not currently used, and I'd like to get rid of it. (Note: this is distinct from the advance width of each glyph, which is certainly required.) >From what I can tell, there is no API that a Win32 application or the Windows GDI can use to get this information from a printer driver. Since I'm not that familiar with either, however, I figure I should try to confirm that this is indeed the case. So, does anyone know of any API that an application or the GDI can use to get the dimensions of an individual glyph from a "real" Windows printer driver? (I have verified that calling the GetTextExtentPoint functions with a one-character string returns the height of the font, not the height of the glyph. For example, it returns the same height for 'A' and '_'.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

RE: winapi update
by Patrik Stridvall 27 Jul '01

27 Jul '01

> Btw, what does make filter do? > > Your post to wine-patches says it's nice an all but it does not say > what it does. Try and run it it is self describing. :-) Since Alexandre didn't apply the Makefile patch, running it is a little awkwark. Will fix that it later versions though. Try do: cd wine ./tools/winapi/make_filter make You can also give it parameters like ./tools/winapi/make_filter make clean Warning "make clean" doesn't look that good currently. PS. It filters the make messages and only display important messages. It might not always work 100% though, but I will fix problems as I find them. I wrote it many months ago and have run it from time to time since, so most issues have been fixed. The reason I wrote it was that I was irritated that important messages scrolled of screen. > If it's nice isn't it worth advertising to the Wine > developper community? I had intended to do that if but since I was unsure that Alexandre would apply my Makefile patch I decided to wait until it could present a better "user interface". But by all means test it.

2 1

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> [...] > > > Most of these are because of the transition to making > HANDLE a void* > > > and compiling with STRICT. > > > > Yes, I notice this was the case with TIMERPROC casts. > > However it is no so with the HOOKPROC casts, > > and yes it is the same with the real Windows headers. > > ??? > AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a > FARPROC one. Hmm. I looked again and it seems you are right. Must have missed it somehow. Strange. > [...] > > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. OK. Will look at it later.

1 0

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> The volatile stuff in dplay.h is part of the Windows header, you > cannot remove it. No it isn't. I'm not sure why it was added in the first place. It is neither used by Wine, nor defined by Windows. In fact only a few strange headers use volitile at all, and none of them is supported by Wine. > Most of these are because of the transition to making HANDLE a void* > and compiling with STRICT. Yes, I notice this was the case with TIMERPROC casts. However it is no so with the HOOKPROC casts, and yes it is the same with the real Windows headers. > Please don't add typecasts, consider the > warnings as an incentive to do the right fix... As you wish, but as I said HOOKPROC can't be fixed with STRICT. But OK I will try and compile with -DSTRICT and see what happends. IIRC somebody tried that but it didn't turn out so well. Oh well, lets see what happends.

2 1

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No it isn't. I'm not sure why it was added in the first place. > > It is neither used by Wine, nor defined by Windows. > > It is in the Windows headers I have. It is not in my Microsoft Visual C++ 6.0 header, but perhaps you have a newer version? DPlay using volatile seems a little strange, so I thought is was wrong especially since it was not in my version, but then I have seen stranger things. :-) > > As you wish, but as I said HOOKPROC can't be fixed with STRICT. > > Why not? Because it would be incompatible (warning wise) with Winelib applications compile with -DSTRICT since Windows doesn't provide a special -DSTRICT version of HOOKPROC. The application might pass a FARPROC to it and expect it to work. Well, of course it works but it would generate a warning.

1 0

Re: winapi update
by Alexandre Julliard 26 Jul '01

26 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > The make_filter.diff patch is quite nice. > > Try it after applying it with by running: > make filter I'm not sure about the portability of the wildcard rule. Why don't you have make_filter call make instead of the other way around? This would avoid the need for changing the makefiles at all. -- Alexandre Julliard julliard(a)winehq.com

2 1

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