Hi Patrik,
I get these hundreds of warnings about "config.h":
[dimi@dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16
dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include
dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include
dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include
controls/desktop.c: #include "config.h": file not found
controls/desktop.c: #include "config.h" is not a local include
controls/edit.c: #include …
[View More]"config.h": file not found
controls/edit.c: #include "config.h" is not a local include
controls/icontitle.c: #include "config.h": file not found
controls/icontitle.c: #include "config.h" is not a local include
controls/menu.c: #include "config.h": file not found
controls/menu.c: #include "config.h" is not a local include
dlls/advapi32/advapi.c: #include "config.h": file not found
First of all, I think they are bogus. Second, if I specify the
--cross-call-win32-win16 flag, I expect to see only the problems
I am asking for, no? Shouldn't we silence all other warnings, if
we ask for something in particular?
--
Dimi.
[View Less]
> 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 …
[View More]people are already using the headers.
True.
> 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 :)),
It not easy to mix different flavours of the Win32 headers
because of include problems.
The problem is that is you have since we include wine specific files like:
#include "wine/debug.h"
we need to have a include path like
-I${prefix}/include
However now since the Wine version of the standard Win32 header are in
${prefix}/include
we get them included as well if we do
-I${prefix}/include
So if we do for example
-I/opt/microsoft/windows/include
we get header include collisions.
Sure with GNU C on Linux (and presumably) on Windows we can fix that
by specifing a correct include order. However with Microsoft C++
we can't do it in a portable way.
With your suggestion above we can, so I like it. :-)
> 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...
[View Less]
Hi,
This OpenGL method is currently a stub, looking at the MSDN
documentation I can't see why this is the case given the fairly complete
GL implementation Wine has. Is it that we cannot handle layering
properly in X or something?
thanks -mike
--
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center
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 …
[View More]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. Más Útil Cada Día http://www.msn.es/intmap/
[View Less]
This patch series starts to look more like what it should be.
Previous bugs seem to have been fixed and dependencies between
winedos and other dlls have been reduced close to minimum.
However, I still find some things that I don't particularly like:
- The series is actually one big patch divided into
multiple files and not a series of incremental changes.
The first patch in series breaks DOS3Call and error reporting of
some functions and these are only fixed in later patches.
- Old …
[View More]int21 functions contain some obvious bugs that really should
be fixed at the same time the code is migrated to winedos.
- Move to winedos should not only migrate code but it should also
try to rewrite code so that it has better comments, it is more
readable and it uses simpler constructs. This patch series really
messes up already complicated code. Intendations are irregular and weird.
Many newlines are missing. Some internal functions use INT21_ prefixes
and some don't. Functions that were implemented as separate helper
functions are moved inside int21 main switch case. Three nested levels
of switches are used without even proper indentation. And that comment
about shooting people is tasteless and really doesn't belong to Wine.
I just don't find the quality of this patch acceptable. I don't
decide these things but my personal opinion is that I would rather
rewrite this patch series than see it accepted in its current state.
I wouldn't mind if Nog or someone else works on int21 migration
(that's why I haven't posted int21 patches already) but I don't see why
I ought to lower my quality requirements due to this fact.
--
Jukka Heinonen <http://www.iki.fi/jhei/>
[View Less]
Could cabinet be set to:
"cabinet" = "native,builtin"
automatically by wineinstall as long as it does not work the way expected?
Tapio
On Thursday 28 November 2002 12:59, Patrik Stridvall wrote:
> > I'm trying to install MS Office 2000 on wine-20021125.
> >
> > I get an error from Office installer:
> >
> > Internal error 2352. Please contact Product support.
> >
> > I found an advice to repair my cabinet.dll in Microsoft Support pages.
> >
&…
[View More]gt; > The file is in ~/c/windows/system, and it's readable. Does
> > anyone else have
> > problem with this?
>
> Well. It might be that since very recently, Wine has builtin
> stub implementation of cabinet.dll.
>
> Of course it shouldn't be used automatically if have a cabinet.dll,
> since I guess most people (including you) have a:
>
> [DllOverrides]
> ; default for all other dlls
> "*" = "native, builtin, so"
>
> entry in their config file.
>
> You can force cabinet to native with
> wine --dll cabinet=n
> though.
[View Less]
Vincent, Alexandre, and Dimi
Grrr, Im really starting to not like Linux's PPPoE support...
I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that …
[View More]they fix problems with my setup... so until next Wednesday I will probably just lurk on the lists
-Dustin
[View Less]
Apologies for needing some more hand-holding: from Alexander's advice I now
have the game linking and beginning to execute. It now gets stuck while
executing this piece of C++:
---------------------------------------------------------------------------
void tDirectDrawScreen::destroy()
{
DDSURFACEDESC ddsd;
memset(&ddsd,0,sizeof(DDSURFACEDESC));
ddsd.dwSize = sizeof(DDSURFACEDESC);
ddsd.dwFlags = DDSD_CAPS;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;
…
[View More]HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL);
// crashes here
...
}
---------------------------------------------------------------------------
This being the segfault that occurs:
---------------------------------------------------------------------------
#0 0x40c92c4c in ?? ()
#1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00,
dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc
<EnumDisplayModesCallbackThunk>) at ddraw/user.c:373
#2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8,
dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at
ddraw/thunks.c:348
#3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at
Source/tDirectDrawScreen.cpp:852
#4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:88
#5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668,
fullScreen=false, screenWidth=640, screenHeight=480) at
Source/tDirectDrawScreen.cpp:55
#6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at
Source/Main.cpp:289
#7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0,
lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322
#8 0x4062509c in __wine_exe_main () from
/home/mattbee/Work/Nemesis/LSNClient.exe
#9 0x400b3799 in start_process () at ../../scheduler/process.c:564
#10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at
../../scheduler/sysdeps.c:112
---------------------------------------------------------------------------
Any ideas why this might be happening?
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
[View Less]
Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit :
> re-reHi...
>
> This patch implements the 'GetRenderTarget' method for the IDirect3DDevice
> COM object. It is independant from all previously submitted patches (but to
> prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix).
>
> With this series of patch, the Boids demo from the DX6 SDK is now running
> (it's not working because we are lacking some D3D code, but at least it does
> not crash :-)…
[View More] ).
>
> Changelog:
> - implement GetRenderTarget
A bit too much work on your part I bet, as you forgot to attach the
patch ;-)
Vincent
[View Less]
Hi,
is there are known issue with the preempt patch for the kernel? When I
apply that patch, non-open-gl games doesn't run smooth, without the
patch they run nearly smooth (especially StarCraft & BaldursGate).
OpenGL games are alway fine.
matthias