I'm having a strange behavior trying to build Wine on my machine at work
(which is a modified RH7.3 machine):
First of all, if I attempt to do a standard CVS checkout followed by a
make depend, the make depend failes with a "dlls - no such directory"
error, even though it exists.
Changing SHEL
Vincent Béron wrote:
What's the output of rpm -q -f /usr/include/GL/gl.h and gl.ext?
Mine's XFree86-devel-4.2.0-72, and I don't have any problem compiling
Wine with OpenGL.
My GL headers are from the CVS pull of DRI, so they aren't owned by any
package.
Sylvain Petreolle wrote:
whats your videocard and your drivers model/version ?
xdpyinfo and glxinfo attached.
Basicly a pull of the DRI CVS.
name of display::0.0
version number:11.0
vendor string:The XFree86 Project, Inc
vendor release number:4020
XFree86 version: 4.2.0
ma
Uwe Bonnes wrote:
Often for such problems a "make distclean", .configure , make depend and
make sequence helps.
Bye
Not this time. Same result.
Ever since upgrading to RH8.0, I've been getting the following errors
when building Wine - even with a fresh CVS pull:
device.o: In function `DrawPrimitiveI':
/usr/src/wine/dlls/d3d8/device.c:392: undefined reference to
`glMultiTexCoord2f'/usr/src/wine/dlls/d3d8/device.c:416: undefined
referenc
I have an old, nasty application that uses the Paradox database engine.
This app attempts to lock the database files using LockFile.
Now, it USED to work under Wine. It no longer does. The program coughs
up an error "No access to directory", and stderr shows a bunch of
"LockFile not supported i
I am continually amazed at how well Wine emulates Windows - for example,
my recent experiences show Wine has the whole "Just re-install it, it
will fix it" thing down pat! 8^>
To recap the story thus far - Several months ago, I was able to play
Halflife- Opposing force all the way through under
Lionel Ulmer wrote:
'> This begs the question:
> Does the Linux implementation of pthread really work anyway?
Considering that about 2 months ago, I was able to play HalfLife
Opposing Force all the way through under Wine, I doubt the pthread
emulation is a problem.
By the way, what driver
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
Since I can no longer get OpenGL textures to work under Wine, I'd like
to try to get the DirectX emulation working. However, when I configure
an app to use DirectX, I get a "You have selected a mode your graphics
card does not support" message.
Since the color depth and resolution are the same
Lionel Ulmer wrote:
Out of curiosity after the DoubleBuffered thread Does this fix your
problem too ?
No, I was running DesktopDoubleBuffered = Y already.
Chris Thielen wrote:
I do believe there are OpenGL regressions. I have a single processor
system with a working OpenGL, yet OGL games under Wine have texture
issues they did not have previously. I'm not entirely sure it's wine, as
I've updated my Mesa/X/modules many times.
You are in the same
Dan Kegel wrote:
Please verify that booting with just one CPU active
doesn't fix the problem. e.g. at lilo prompt, do something like
linux nosmp
It could be that Wine doesn't support SMP yet.
- Dan
First thing I tried, and with no change, so I don't think it's a SMP
issue. Furthermore, my
I'd asked this before, but received no response, so I'll ask it again.
Does anybody have any suggestions on where to start debugging textures
being wrong under OpenGL apps under Wine? Specifically, I am trying to
get HalfLife-Blue Shift to run, but all the "static" textures (walls,
floors, etc.
There seems to be a strange problem related to the serial port.
Specifically, when running Delorme AAA MapNGo 4.0, and attempting to use
GPS navigation, it is unable to communicate with the GPS device.
On stderr Wine is printing out
RtlNtStatusToDOSerr - unable to map 0102
This only happens
Andreas Mohr wrote:
What a weak and useless suggestion, this will run out of characters in
no time at all ;-)
Better use Chinese characters !
Bah! You are still weak! Better to use Klingon - I do beleive they've
reserve some Unicode space for them!
Eric Pouech wrote:
does rm have such an option ? rm doesn't, so I don't see any reason for
Actually, rm DOES have such an option:
-i, --interactive
prompt before any removal
AND certain distros (RedHat for example) alias rm to "rm -i" by default.
Also, I stated that the com
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root
(that is,
just before wine starts anything). This piece of code should only be
explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have
Well, a cvs up -C and rebuild, and things are find here at home. I'll
have to see what is up with my machine at work Monday...
Dimitrie O. Paun wrote:
The algorithm has been: start a new series when Alexandre has committed
the previous one. So, for example, because I've started the Z-series
last night, that means that Alexandre already committed the X-series.
So the only outstanding patch not committed to CVS is Z0. I d
For those of us who are a little behind on the patches, would it be
possible to get a roll-up patch of all diffs from the CVS MAIN branch?
Also, what is the status of CVS vs. the patches - what patches have been
applied?
Dimitrie O. Paun wrote:
On October 19, 2002 11:34 am, David D. Hagood wrote:
>Second, when I do the "Along the way", the program cores out.
This one's tricky. Can you please retest (it will still crash),
and send me the log, after applying thing patch:
The patch is not
I'm getting some strange textures on HalfLife, Opposing Force, and Blue
Shift: Sample screen shots are here:
http://sktc.net/~wowbagger/ba_hazard1.png
http://sktc.net/~wowbagger/ba_hazard10001.png
Specifically, any static texture is screwed up. Dynamic textures, like
water or "people" are O
Applied and tested listview patches through U5 - The road type column in
the directions window is back (good), but the system still dies on the
Along the way (bad), with the same assertion failure as the previous report.
I've just applied/built/installed/tested the U series patches, and I
have 2 regressions in the AAA MapNGo program:
First, the first column of the directions window (which shows the type
of road) is missing.
Second, when I do the "Along the way", the program cores out.
The log, and a screen cap
Dimitrie O. Paun wrote:
>
> I guess the problem with the main screen is that the listview
> to the left mangles long items when drawing them, just like in
> the attached picture, right? If so, you haven't tried the latest
> patches... ;) Can you please confirm it's OK now?
>
I can confirm the lis
Dimitrie O. Paun wrote:
> On October 15, 2002 10:04 pm, David D. Hagood wrote:
>
> >What can I do to help on this? Would posting a debug message dump
> >showing the list items being inserted be of use?
>
>
> Yes, please send me a trace of:
> --debugmsg +listview
&
Since the work on the listview rewrite has started, the listview has
regressed big time. Running Delorme's AAA MapNGo V4.0, the "Along the
way" window HAS-A listview into which are inserted the items found.
This used to work in the old code, but now nothing is shown. I know the
items themselve
My old motherboard died, and so I upgraded from a single P3 to a dual P3
system. I went to run HalfLife, which had been running beautifully under
Wine, and now all the wall textures are screwed up. There is nothing of
the proper textures in them - it's not like the colors are screwed up,
more
I have the misfortune of needing to use Windows based DSP compilers for
a project I am working on. Fortunately, they run under Wine just fine.
So, the actual makefile is executed by a native GNU/Linux make, but the
compile and assemble parts are Windows programs running under Wine
(using Linux
Dmitry Timoshkov wrote:
> "Chris Morgan" <[EMAIL PROTECTED]> wrote:
>>I have a .com application that is calling out to dos int21 4Bh to load and
>>execute a program.
>
> If that is what Windows really does, then your approach is certainly right.
Would it not be better (at least under Linux)
Andreas Mohr wrote:
> Add to that the fact that CUPS gets rather completely rid of the useful
> Unix filter machanism, and you really start to wonder whether CUPS really
> is better than say lpd+printtool. Quite the other way around or so...
Actually, I do beleive that CUPS does use a filter me
I've been having trouble with my RH7.2 LPRng based printing, so I
decided I'd try installing CUPS. After fighting for hours to get this
so-called easier printing system installed and working, I finally got to
where I could print from Linux apps. Now, however, Wine steadfastly
refuses to bring
Gads. I knew better than that. Sorry, diff -u attached.
Changelog:
ADPCM nybble processing order was incorrect.
? console/Makefile
? controls/Makefile
? files/Makefile
? graphics/Makefile
? graphics/enhmetafiledrv/Makefile
? graphics/metafiledrv/Makefile
? graphics/win16drv/Makefile
? graphics/
Gerhard W. Gruber wrote:
> Does anybody know what the \??\ stands for and wether the '1' for the
I cannot answer the second part, but the \??\ is Windows NT's answer to
/ - it is the root of the filesystem that is visible from within the NT
kernel. Various device files, and mounted file system
Andreas Mohr wrote:
> On Thu, Feb 14, 2002 at 06:17:56PM -0600, David D. Hagood wrote:
>
> My newly submitted patch "implement "App Paths" support" might just be
> what you need...
> (disclaimer: I did *not* implement it for you ! :-)
>
>
I would ne
The problems with adding the code directly to the Wine config path are:
1) We package the tools along with the project - that way, if the tools
are updated for a giving build, they will always be available with that
build. I've done too much code archeology where I couldn't build a
release bec
[EMAIL PROTECTED] wrote:
> Pity you couldn't use some other environment variable. The entire unix
Yes, but make must also be able to find the tools, hence they are in the
path (I am using Linux's binfmt_misc with the appropriate settings so
that the programs are directly executable).
> compi
Due to circumstances beyond my control, I have an embedded system that I
am developing that uses Windows based compilers. Unfortunately, WinNT
bluescreens too much for me to be able to work, so I have ported the
project to using Gnu Make, with the compilers being executed via Wine.
The problem
Is anybody working on support for playing ADPCM wave files under Wine?
If not, I'd like to take a crack at it.
I have an app that I use (Delorme's AAA MapNGo 4.0) that uses ADPCM wave
files to contain spoken information on attractions. I know that Wine can
access my sound system to play normal
(hope I don't set off a flame war like last time I posted to the list... ;^)
I'd like to suggest that rather than using the " ;" as a null statement,
Wine should either use "{}" or
{
}
My reasons are as follows:
1) I get suspicious if I see a naked semicolon on a line. I wonder if
so
I hadn't tried setting an explicit override for shlwapi in the
DLLoverrides. Silly me, it never occurred to me that I could ADD MY OWN
DLLs. However, I noticed that shlwapi is not in the default
configuration for Wine. Perhaps somebody who isn't an Anonymous Coward
as far as the CVS server goe
I've tried to install several programs under Wine (the most recent being
Delorme's AAA MapNGo V6.0) and I consistently get this error:
err:win32:fixup_imports No implementation for
shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef
err:win32:fixup_imports No implementa
One thing I'd like to see some consideration given
to is a way to cache the parsing of the fonts in the wineserver (or something
similar). I have a lot of X fonts on my system, and several of them are
not recognized by Wine's font parser. Result: Wine has to rescan the fonts
every time it start
44 matches
Mail list logo
