wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

2 1

Fwd: Re: [putty]Winelib support + patch
by Dimitrie O. Paun 01 Dec '02

01 Dec '02

This is a very valid question. Alexandre, do we support generating regular executables for the apps we don't necessarily need the wrapper stuff for initialization purposes? ---------- Forwarded Message ---------- Subject: Re: [putty]Winelib support + patch Date: Mon, 25 Nov 2002 10:17:18 +0000 From: Simon Tatham <anakin(a)pobox.com> To: dpaun(a)rogers.com Cc: putty(a)projects.tartarus.org "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > FYI: the way it works is that instead of compiling the app as an > executable, we generate a .so that's loaded by wine. Now, > wine is simply a one page program that loads the libraries > that the program expects (like kernel, gdi, user), and then > loads the program itself. This is required by some apps which > have C++ static initializers, which expect to be able to call > Win32 functions, and they do so before we get a chance to > initialize them, if we were to have the app load the libs. OK, I've now read the docs and I understand this a bit better now. My next awkward question is: I can see that this is necessary for some apps which have C++ static initialisers, or which load libraries that have C++ static initialisers, but why does that mean it's necessary for PuTTY? PuTTY contains no C++, and as far as I know it uses no libraries _except_ standard Win32 API ones. Surely it should be possible _for these particular applications_ to compile them as standalone binaries? Or does Winelib currently only support doing things the inconvenient way? Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the <anakin(a)pobox.com> terminally confused is only apparent to the latter." ------------------------------------------------------- -- Dimi.

3 5

Texture problems under Wine - more info
by David D. Hagood 01 Dec '02

01 Dec '02

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

2 2

SetWindowHookEx
by steve.lustbader＠philips.com 01 Dec '02

01 Dec '02

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

Compilation with -DSTRICT
by Thomas Wickline 01 Dec '02

01 Dec '02

Hello, I just want to say Thank you to all the people who put work into the Compilation with -DSTRICT Tom

1 0

Reopened a bug
by Dustin Navea 30 Nov '02

30 Nov '02

I have reopened bug #15 due to the fact that the bug still exists to a certain extent and in a different form. When sending an IM in AIM with any recent version of wine (including a couple of days before the latest cvs snapshot), I can resize the window and when the buttons go to reposition themselves, they move much slower than the border of the window, and you can see them updating their position. Would there be any debug traces I could post to the bug to help resolve this? -Dustin

1 0

RE: strcat+strcat+strcat == baaad
by Medland, Bill 30 Nov '02

30 Nov '02

> -----Original Message----- > From: wine-patches-admin(a)winehq.com > [mailto:wine-patches-admin@winehq.com]On Behalf Of Francois Gouget > Sent: Friday, November 29, 2002 10:11 PM > To: wine-patches(a)winehq.com > Subject: strcat+strcat+strcat == baaad > > > > I don't like pieces of code that go: > > strcpy(foo, bar1); > strcat(foo, bar2); > strcat(foo, bar3); > strcat(foo, bar4); > strcat(foo, bar5); > strcat(foo, bar6); > > It's really inefficient: the cost increases quadratically > with the size > of the resulting string. It's more efficient to do: > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); > > Here the cost is proportional to the size of the resulting string. And surely when the opportunity arises it would be better to use snprintf (i.e. when you know the size of the buffer). (I doubt that the code has already checked the size of the strings being pasted together) > > For for various reasons I came accross a couple of instances of > strcat+strcat badness and replaced them with a sprintf. So here's the > patch. > > Changelog: > > * memory/environ.c, > tools/makedep.c > > Use sprintf rather than calling strcat over and over > > > Index: memory/environ.c > =================================================================== > RCS file: /home/wine/wine/memory/environ.c,v > retrieving revision 1.38 > diff -u -r1.38 environ.c > --- memory/environ.c 9 Oct 2002 18:35:02 -0000 1.38 > +++ memory/environ.c 30 Nov 2002 05:20:12 -0000 > @@ -641,12 +641,7 @@ > > /* Set the new string */ > > - if (value) > - { > - strcpy( p, name ); > - strcat( p, "=" ); > - strcat( p, value ); > - } > + if (value) sprintf( p, "%s=%s", name, value ); > current_envdb.env = new_env; > ret = TRUE; > > Index: tools/makedep.c > =================================================================== > RCS file: /home/wine/wine/tools/makedep.c,v > retrieving revision 1.13 > diff -u -r1.13 makedep.c > --- tools/makedep.c 17 Aug 2002 18:28:43 -0000 1.13 > +++ tools/makedep.c 30 Nov 2002 06:10:17 -0000 > @@ -192,9 +192,7 @@ > if (SrcDir) > { > pFile->filename = xmalloc( strlen(SrcDir) + > strlen(pFile->name) + 2 ); > - strcpy( pFile->filename, SrcDir ); > - strcat( pFile->filename, "/" ); > - strcat( pFile->filename, pFile->name ); > + sprintf( pFile->filename, "%s/%s", SrcDir, pFile->name ); > } > else pFile->filename = xstrdup( pFile->name ); > > @@ -218,9 +216,7 @@ > for (path = firstPath; path; path = path->next) > { > char *filename = xmalloc(strlen(path->name) + > strlen(pFile->name) + 2); > - strcpy( filename, path->name ); > - strcat( filename, "/" ); > - strcat( filename, pFile->name ); > + sprintf( filename, "%s/%s", path->name, pFile->name ); > if ((file = fopen( filename, "r" ))) > { > pFile->filename = filename; > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > >

1 0

Re: somebody help me identify this bug please
by ezra daniel 30 Nov '02

30 Nov '02

that I have tried and needed yes, only valves with "acute accent" like you call it, excuse my english.. :) And I dont understand what you mean by dead key... but anyway... in every linux app I can type that right, only the new wine version breaks that, but I know it was fixed on 20021031 cause it worked great. To make an example of what I can't type : canción = in the wine version appears as cancion without the ó In my language this is very important or they will think I dont know how to write my language, hehehe Thanks :) -daniel http://www.debian-gnu.com >From: "Jeff Smith" <whydoubt(a)hotmail.com> >To: ezra_daniel(a)hotmail.com, wine-devel(a)winehq.com >Subject: Re: somebody help me identify this bug please >Date: Fri, 29 Nov 2002 13:31:46 -0600 > >Is it only characters with the acute accent? Is it that your are >attempting this using 'dead key' entry on a Spanish keyboard? > >If this is the case, the problem may be in a recent correction to >the Spanish keyboard layout. > >I will work on this some more when I get a chance, but hopefully >someone else will find something sooner. > > -- Jeff S > > >>From: "ezra daniel" <ezra_daniel(a)hotmail.com> >> >>Hello, >> >>At work I use Lotus Notes under Wine. >> >>I downloaded compiled and installed the new wine version 20021125 and I am >>no longer able to type accecented valves, like á é í ó ú. >> >>Ñ can be typed though correctly. >> >>With the other version 20021031 I could type accented valves.In fact I >>went back to using the older version and worked again so it is obvious it >>is a problem in the new wine version. >> >>Though I am a newbie and know nothing of developing, but I would like to >>submit the bug to the proper person so it fixes it back again but I dont >>know which section of wine or person deals with this character typing >>problem. >> >>Can anyone point me in the right direction? Thanks in advance. >> >>-daniel >>http://www.debian-gnu.com > _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx

1 0

Re: Yet another D3D patch....
by Christian Costa 30 Nov '02

30 Nov '02

Lionel Ulmer wrote: >Hi all, > >This patch should not be dependant of any others... But to prevent line >number errors, better to commit it after the 5 -> 9 series (yeah, the >attachements are numbered to ease tracking :-) ). > >Changelog: > - start of support for device locking / unlocking via glReadPixels / > glDrawPixels interface (slow but should be enough for a start) > - implement one vertex case for the D3D3/7 DrawPrimitive functions > - fix a missing \n in a TRACE call > > Lionel > This patch breaks the TWIST demo that was working fine. I think the changes in d3ddevice_create are responsible of that.

2 2

DPMI_CallRMProc trouble
by György 'Nog' Jeney 30 Nov '02

30 Nov '02

I realy need help with this. Whenever I call a DOSDEV_ function then that function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc. Now that function call DOSMEM_GetBlock( 64, (UINT16 *)&(context->SegSs) ) to try and allocate a stack. This fails for some reason but I dont understand why because it succeds if called from int21/48. Anyone know whats going on? nog.

1 0

Re: Janitorial Projects
by Rolf Kalbermatter 30 Nov '02

30 Nov '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: >I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > >with the list of cross calls from 32->16, and W->A. > >There are currently 13 cross calls from 32->16 bit code, >and 194 cross calls from Unicode to ASCII. I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version. But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions? Rolf Kalbermatter

2 1

MIDI Mapper fix
by Jeff Smith 30 Nov '02

30 Nov '02

I'm so happy, I just had to share it with everyone :-D Changelog: Fix for MIDI Mapper. Notes: Finally found it! This was the last thing keeping sound from working in Auralia. With just this simple patch, it now works. Auralia still has a few problems, but they are minor in comparison. It *is* kind of important for sound to work in an ear training program ;-) BTW, Thanks to Eric P. for his help getting me off to a running start with his fixes to the OSS MIDI driver a couple of weeks back. (patch is attached - Hotmail has not been kind to my inlined patches the past few days) _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

The conformance tests need you!
by Francois Gouget 30 Nov '02

30 Nov '02

Hi, I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms. That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine). You can see things more graphically at the following URL: http://fgouget.free.fr/wine/tests-en.shtml Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

1 0

[RFC] Wine headers
by Dimitrie O. Paun 30 Nov '02

30 Nov '02

Alexandre, Patrik brought up the header location sometime ago, in this thread: http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 At the time, I thought it is a bit premature, that we have other things to do. Now I realize that this is one of those highly visible external things, that would be a _lot_ better to fix before people start using Winelib. Otherwise will piss people off when we change, or we will not change because people are already using the headers. Both versions are not good, and I think we can fix them now without too much pain. Here is my proposal: ${prefix}/include/win32 -- standard Win32 headers ${prefix}/include/msvcrt -- MS Visual C Runtime library ${prefix}/include/wine -- Wine specific headers It is simple (to understand & implement), clean, and pretty. And I think it solved Patrik's problem (even if I can't quite understand what the problem is from the first message :)), plus a bunch of other things (like making it easy to use other headers for the Win32 API, etc). And best of all, it seems to be easily implementable, no? -- Dimi.

2 1

Partial success report: Toshiba 220CDS electronic manual
by Dan Kegel 30 Nov '02

30 Nov '02

http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe is an "online manual" for the Toshiba 220CDS laptop. I unzipped it with Linux unzip, then ran its setup and the app itself with Wine20020605-2 from Red Hat 8. Both ran acceptably well, although I did get a few warnings like: err:ntdll:RtlpWaitForCriticalSection section 0x4011a4a8 "../../scheduler/syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) tid=08078300 fixme:scroll:ScrollBarWndProc Unimplemented style SBS_SIZEBOX. and there were display anomolies (mostly, areas of the window not being cleared, so old text piled up). Also, I had to grep through the registry for 'toshiba' to see where the darn thing installed itself. I'm looking forward to trying with a more modern wine, but don't have time at the moment. - Dan

2 2

[RFC] Winelib enhancements
by Dimitrie O. Paun 29 Nov '02

29 Nov '02

Folks, You are probably familiar with the Winelib page: http://www.dssd.ca/wine/Winelib-Apps.html where I describe what one needs to do to compile a Win32 application under Winelib. My original motivation for doing the work was to better understand what inconveniences one has to go through to do the port, and what we can do to eliminate them. Here are my thoughts on the subject, in the build order: Compilation This step require the addition of some flags, and the potential removal of others. Simple to do, and if there is a configure script, quite doable. However, these tweaks are really annoying in the initial stages of the port, and would be so nice if we had a nice compiler wrapper (call it wcc) that would do that behind the scenes, so that the only modification to the makefile would be: -CC=gcc +CC=wcc Q: Alexandre, would you accept such a utility in the tree? Resources These ones are nasty. Programs typically use the windres compiler that compiles a .rc file into a .o file directly, which is later simply linked into the application. We go a different route, by sticking the resources in the .spec.c files, and this entails non-trivial modifications to the makefiles. The ideal option would be to provide a windres compatible command line mode for wrc, so that we can do: -RC=windres +RC=wrc This would mean moving the resources out of the .spec.c file, and exporting the resources variable so we can link it into the .spec.c file. Q: Alexandre, is this acceptable? Does it warrant discussion? Linking Another tricky step, with multiple problems 1. We are missing import libraries. As a result, we can not link with -lwinspool, we need to link with -lwinspool.drv Small change, but it can present nasty problems if you want to submit the patch upstream, to the application maintainers. I understand this one is already on Alexandre's TODO, so we should have a solution to it not before too long. 2. Our linking process is quite different from the "standard" one which uses gcc/ld to do the linking. We generate intermediate files (.spec.c files), and use different flags. Again, the solution for this (to at least help initial porting efforts) would be a wrapper script that does this, that can be used instead of ld. And so the question comes back again, to haunt us: is this needed/wanted/acceptable? Running This is a new step in the process that we introduce. Currently we produce a shared library that requires a wrapper script to start it up. Many considers this (and I might say rightfully so) ugly/bloat/etc. The ideal situation would be to generate regular executables, like all well behaved libraries. Here are a few solutions: 1. An interim step is to improve the wineapploader script so that it can be used by all apps. This is a simple thing to do at the moment, but does not solve the root cause, it just ease the pain a bit. This way you don't need to fight the application maintainers to get such script included in their tree, and having to answer the eternal questions: "WTF is this? I thought that compiling under Winelib would yield an executable that did not need wine. What's the difference as compared to running the Win32 binary directly?" 2. Fix the build process so that we can actually generate regular executables. Thing is, I don't know what's involved in doing so, and I'm afraid only Alexandre knows the answer (hint, hint :)). So a discussion on this topic is needed, just to figure where we want to go from here. Now, this message is meant to elicit discussion on these topics, so that at the end of the day I can gather the conclusions, and track them on TODO page. So do not hesitate to send in your comments. :))) Thanks for your attention, and sorry for the long message. -- Dimi.

5 14

ppdebug
by Michael Sauer 29 Nov '02

29 Nov '02

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2 mIc P.S.: sorry if this mail reaches the list twice, but the first one i send with some private e-mail address and the list moderator will (hopefully) erase it (as he does it every time).

2 1

RE: Janitorial Projects
by Patrik Stridvall 29 Nov '02

29 Nov '02

> "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > >I have updated the Janitorial section: > > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > > > >with the list of cross calls from 32->16, and W->A. > > > >There are currently 13 cross calls from 32->16 bit code, > >and 194 cross calls from Unicode to ASCII. [snip] > But what the heck do the errors about AW functions calling Unicode > mean? It means that winapi_check has a bug. Fixed in my tree. > Isn't that the actual idea about the AW functions? Yes. :-)

1 0

RE: Wine conformance tests with MSVC headers
by Patrik Stridvall 29 Nov '02

29 Nov '02

> I tried to compile the various conformance tests with MSVC 6.0. There > are two different configurations for each project: with MSVC or Wine > headers. With the MSVC headers configuration, it doesn't find > "wine/test.h" (since wine/include is not in the include > path). Is it a > known behavior? With the Wine headers configuration, I don't > get those > errors It is bug. Fixed in my tree. Patch comming soon. > (but there are a bunch of warnings concerning signed/unsigned > comparisons, for which I'll try to send a patch tonight). OK.

1 0

Wine conformance tests with MSVC headers
by Vincent Béron 29 Nov '02

29 Nov '02

Hello, I tried to compile the various conformance tests with MSVC 6.0. There are two different configurations for each project: with MSVC or Wine headers. With the MSVC headers configuration, it doesn't find "wine/test.h" (since wine/include is not in the include path). Is it a known behavior? With the Wine headers configuration, I don't get those errors (but there are a bunch of warnings concerning signed/unsigned comparisons, for which I'll try to send a patch tonight). Vincent

1 0

ppdebug
by Michael Sauer 29 Nov '02

29 Nov '02

1 0

RE: msvcmaker
by Patrik Stridvall 29 Nov '02

29 Nov '02

> program/winetest doesn't exist anymore. Creating it empty is > enough for > msvcmaker to work, but is not the proper fix. I don't have the time > right now to check all the winetest references in msvcmaker > (there are > more than i thought). Working on it.

1 0

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
by Dan Kegel 29 Nov '02

29 Nov '02

Sylvain wrote: >> Thanks! >> It works fine with the version 2.96 I use. > Do you know RedHat's gcc 2.96 has SERIOUS bugs and that its support has > been totally dropped ? Support has been dropped by whom? Not Red Hat; they are still releasing updates for gcc-2.96-RH. The latest was 18 days ago, https://rhn.redhat.com/errata/RHBA-2002-200.html > It's update time. I agree, gcc 3.2[.1] is a better choice than gcc-2.96-RH these days. It is very close to compliance with the C++ ABI, and it's an official Gnu release rather than a vendor snapshot. (I'm building wine for the first time with gcc3.2 today, I hope I'm right about it being a better choice :-) - Dan

1 0

msvcmaker
by Vincent Béron 29 Nov '02

29 Nov '02

Hi all, program/winetest doesn't exist anymore. Creating it empty is enough for msvcmaker to work, but is not the proper fix. I don't have the time right now to check all the winetest references in msvcmaker (there are more than i thought). Vincent

1 0

RE: Janitorial Projects
by Patrik Stridvall 29 Nov '02

29 Nov '02

> What we need next: > 1. a way to run all tests. A batch file would do the job nicely. > Patrik, can that be added to msvcmaker? Planned but not done. However, since you asked for it, I will look into it right away.

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