- Wine-Devel - list.winehq.org

Wine Winex Half-life/Nox and alsa
by FT Rathore July 25, 2001

July 25, 2001

Hi I tried Jul 23 cvs of wine and winex and tried with Nox and Half Life. Both wine and winex work fine with the stock kernel sound drivers (es1371) but they do not work well with alsa with oss emulation. The sound gets played extremely fast in Half-Life like someone hit the fast-forward button. It is strange because the timing on the alsa oss-emulation (and commercial oss drivers) is better than the stock kernel drivers. Winex does a lot of improvement in Half-Life and it is fully playable (the splash, the menu and everything). Nox works near perfect with wine but it does not work at all with winex. FT

1 0

(no subject)
by José Soriano Díaz July 25, 2001

July 25, 2001

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. After that I tried to compile my program without winemaker, and I obtained a HEAP_PTR error when executing what I copiled. And If I tried to link the lib*.so and load the main symbol I obtained the same error. So my question is quite siple How can I link a native dll in a Unix project? I've read somewhere that I have to use a parser, Is there anybody who can give me some code? Thanks for your precious time. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

1 0

CallWindowProc syntax
by Marco Bizzarri July 25, 2001

July 25, 2001

Hi all. While looking at the source code of wine, I looked into the synopsys of the CallWindowProc function. According to winproc.c, the hWnd parameter should be the handle to the window which has to receive the message. OTOH, if you look at MSDN, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/hh/w… it looks like the hWnd is the windows procedure which should receive the message. Can anyone help? Thanks Marco Bizzarri m.bizzarri(a)icube.it

1 0

Re: Make built-in font data read-only
by Alexandre Julliard July 25, 2001

July 25, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > If all pointers have to be eliminated, I can't see any way to do it. > In order for the code to have any kind of sanity, built-in font metrics > and dynamically loaded font metrics have to use the same data model, and > I don't think it's even remotely practical to get rid of the pointers in > the case of the dynamically loaded metrics. Well, if it's not feasible so be it. But if it's at all possible I think it's worth some reasonable amount of trouble. > I'm open to suggestions, but I think that the effort involved in doing > this (assuming a sane way could be found) probably far outweighs the > benefit (less swap usage if the data is paged out; is there any other > benefit?). The main benefit is sharing between processes; so if you have 10 processes that want to print you only have one copy of the font data in memory. Plus it gets loaded on-demand so data that isn't used doesn't need to be loaded from disk at all. > Just in case I get inspired, though, what tool/command are you using to > determine read-only vs. read/write data sizes? Can I just go by what > objdump says about .data and .rodata? objdump is fine yes. size works too, though I seem to remember some versions not counting .rodata correctly. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Make built-in font data read-only
by Alexandre Julliard July 24, 2001

July 24, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > Log message: > Ian Pilcher <ian.pilcher(a)home.com> > WINEPS: make built-in font data read-only Unfortunately the data still isn't stored in read-only memory even though it is declared const, because the structures contain pointers that require relocation. Would it be possible to store offsets instead of pointers? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: move 16bit COMM code to USER
by lawson_whitney＠juno.com July 24, 2001

July 24, 2001

On Tue, 24 Jul 2001 11:11:05 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_83577347 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This patch completes the seperation of the 16bit COMM code from > KERNEL > and moves it to USER. Seems to work with Terminal from WFW 3.11. > > Mike If you get this, it seems to work for juno 1.49 too. Lawson ---oof--- > ChangeLog: > move 16-bit COMM code to USER dll > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Microsoft source code releases - a danger to Wine?
by Ian Pilcher July 24, 2001

July 24, 2001

According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it. This leads me to wonder if anyone's ever thought of taking steps to protect Wine from "contamination" by Microsoft IP (legally, not tech- nically :-). As the number of programmers who have been exposed to MS source code grows the chances of this happening will increase. I believe that the FSF uses some type of form/statement before they will accept code, and it seems like the nature of this project would make it particularly beneficial. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

5 6

Re: oleaut32 patch
by Alexandre Julliard July 24, 2001

July 24, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > - changes OaBuildVersion() to always return a very high version value > (2.xx.0xffff), which can be overridden in the config file to deliver > an exact value instead Do we really need such an obscure parameter in the main config file? Are there actual cases where setting the version based on -winver is not enough? -- Alexandre Julliard julliard(a)winehq.com

1 0

Compile error, Please help!!!!!Thanks
by EriK W July 24, 2001

July 24, 2001

Hi gurus, Please help me out with the fatal compiling problem. I am using soalris8 x86 with wine-20010629, Any suggestion would be highly appreciated! /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h 1.2 00/07/05 SMI gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec ./ntdll.spec ld.so.1: ../../tools/winebuild/winebuild: fatal: /usr/local/lib/libwine_unicode.so: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target `ntdll.spec.c' Current working directory /export/home/ericw/system/wine-20010629/dlls/ntdll *** Error code 1 make: Fatal error: Command failed for target `ntdll/libntdll.so' Current working directory /export/home/ericw/system/wine-20010629/dlls *** Error code 1 make: Fatal error: Command failed for target `dlls'

1 0

Re: Function declaration fixes
by Francois Gouget July 23, 2001

July 23, 2001

On Mon, 23 Jul 2001, Patrik Stridvall wrote: [...] > *** declarations > > * dlls/msvcrt/cpp.c, > dlls/msvcrt/exit.c, > dlls/msvcrt/mbcs.c, > dlls/msvcrt/msvcrt.h, > dlls/ntdll/signal_i386.c, > dlls/shell32/shlmenu.c, > include/wine/undocshell.h: > - Made sure that the files that contains the declarations > of the implementated functions are included. > - Corrected mismatching prototypes. > - Cleaned up the include section. You should not add a prototype for MSVCRT_isleadbyte and MSVCRT_realloc in wine/dlls/msvcrt/msvcrt.h. These are declared in include/msvcrt/wctype.h and include/msvcrt/malloc.h respectively. The correct fix is to include these headers where needed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

1 0