Most of the people here are probably smarter than to fall into this trap
but I recently had several customers who did. Most of the time openGL
just refuses to run but a couple of months ago RH did put out an update
to some of the X code that did cause the machine to crash with Wine if
you
Recently my customer replaced her version of Wine with the current
version. One of the programs running there, DeScribe, appears to quit
normally but doesn't terminate. It continues to be in the background
using no cpu time. To get rid of it requires killing the program with
System Monitor
After considerable digging the problems with sound in Alice were traced
to a bad software load. While digging another thing came to our
attention that may be of interest to others. When we put in the latest
fixes to FC6 Wine quit running. This was traced to the fact that the
latest fixes
In the past I have always used the demo version of the game Alice to
test Wine. Recently I loaded a Wine installation and found the game had
no sound. After considerable testing it appears that about a year ago a
change was made in Wine that killed the sound. Has anyone else had this
There is currently a bug in FC6 that affects Wine. If, with any Nvidia
driver from any source, a program attempts to use accelerated video and
the attached monitor uses digital feed the program will often crash the
user session. This has been reported and is not a problem in Wine but a
good
Francois Gouget wrote:
On Tue, 11 Jul 2006, gslink wrote:
The most common problem with Ndiswrapper is that it requires more than
a 4k stack. The result you are getting may be coming from a stack
overflow caused by a combination of Wine and Ndiswrapper.
The 4k stack issue you are talking
Dan Kegel wrote:
On 7/24/06, gslink [EMAIL PROTECTED] wrote:
What you say is correct but the result is the same. The combination of
NDISWRAPPER and any other program fails. In this case it is Wine. This
is not the fault of Wine in any way but it happens. It is a good idea
to keep
The most common problem with Ndiswrapper is that it requires more than a
4k stack. The result you are getting may be coming from a stack
overflow caused by a combination of Wine and Ndiswrapper. Compile and
install the native drivers for your lan card and see if that makes a
difference. The
There is only one other thing that really needs to be in the source for
this. There needs to be a SHORT description of exactly how this differs
from the Wine CVS tree. The description should also include any
interesting comments That would make tinkering much easier. I once had
Wine blow
As I see it, Fontforge was never the problem. The problem was that it
was necessary to read the code to find out that there even was such a
dependency. This was especially true of the Red Hat binaries. There
was no notice or documentation that they would use Fontforge. I didn't
find out
In almost every case we have found that distributions do not contain the
latest Sane backends. I suggest getting the source for both
sane-backends and xscanimage and compiling them.
The whole point of what I am proposing is a collaboration with RH so
that new features are in the distributed Wine. If they are willing to
undertake one of the tasks that Wine HQ is now doing then we should let
them. At least they are supposed to know RH so they should be capable
of the
Did you check out that flow control is handled correctly from the
Olivetti printer. I have had this happen in the past and in every case
I found that either I was using the wrong flow control or not taking it
into account.
Vincent Béron wrote:
Le jeu 20/10/2005 à 20:34, gslink a écrit :
[snip]
Let me explain the problem. I took your source from May and it compiled
correctly. When I looked at your source I found that you had supplied
some additional code in the form of three patches. Among the other
things
Vincent Béron wrote:
Le mer 19/10/2005 à 20:06, gslink a écrit :
If Wine is going to enter beta soon then someone ought to document the
procedure for compiling the source. If FC is used to attempt such a
compile and the instructions packaged with the source are followed the
result
This area can be a real problem under Wine. The high end scanners such
as the Minolta MS6000 simply aren't supported by SANE backend. If you
want to use one then you must write code for the backend. You can
usually get a basic TWAIN driver which is for Win. 98. These usually
run under
Yes! The problem is that there are a good many apis that VB can use
that are not common and are not implemented in Wine. All it takes is
one use of one of these and the thing won't work. Most special purpose
and complex programs fail. This is to be expected. As Wine develops
this problem
If Wine is going to enter beta soon then someone ought to document the
procedure for compiling the source. If FC is used to attempt such a
compile and the instructions packaged with the source are followed the
result will be a compile failure in fonts. This is in spite of
installing
I suspect this may not be in Wine at all. There is currently a problem
that shows up both in and out of Wine with the cursor vanishing
permanently until reboot on some games that block or change the cursor.
This appears to be a problem in FC but I have not had time to track it
down.
Mike Hearn wrote:
Eventually nobody should have to use winecfg for anything. Let's
spend our
time fixing the bugs and increasing automation rather than arguing about
the best way to represent a list of hacks in the UI :)
I think the reality is that winecfg is going to hang round for a
There were a number of update rpms recently posted for gcc. One way to
cause this problem is to omit loading one of them. This happened to me
and I believe that one of the updates was not posted with the others.
All the updates are there now. The easiest way to check for this
problem is to
There is only one problem with these documents. There aren't nearly
enough of them!
The user interface is what the user has to do to use the program. This
is not supported in Wine. You will find links from winehq to several
lists of things that run under Wine. When you attempt to use these
lists you will find that many if not most of the programs do not run as
is.
The user
Jonathan Wilson wrote:
Its highly likely that GCC and WINE are already infringing on some
software patent somewhere (since its well nigh impossible not to in the
current patent everything you can climate inside a number of big
companies)
What makes this particular borland patent any different?
The whole business of software patents is very likely to explode at any
time. There are several software patents on cds and dvds which are so
vague that it is impossible to tell exactly what is going on. The
licenses to use these patents allow the company issuing the patent to
control cd
Use the native Linux Reader 7 from the Adobe web site. Running Reader 7
under Wine isn't worth the trouble. Acrobat Professional is a different
matter. The latest Acrobat Professional that will work on Wine is 5.
Both 6 and 7 require dlls that must be supplied from Windows. Seven has
copy
IBM does very well know the existents of Wine (they even acknowledged
that by themselves lately), but may very well not support it, because of
inter-relation with MS. As of now (just a guess), they don't want to get
into more hot water right now
Would it be to the advantage of Microsoft to
But contacting MS should be made only after a decision (voting) of this
list.
gslink wrote:
IBM does very well know the existents of Wine (they even acknowledged
that by themselves lately), but may very well not support it, because
of inter-relation with MS. As of now (just a guess), they don't
I wonder if it isn't a little early to consider the entire issue of
commercial support. Most programs do not run under Wine without some
sort of setup and things written to XP standards don't run at all. The
project hasn't gotten to the 1.0 level yet. The project is coming along
very well
I wouldn't worry about anyone but Microsoft stealing Wine. In order to
develop Wine you must be an expert C++ programmer. That requires an
enormous amount of work and thieves are usually lazy.
A new teacher came to the master. I have developed some new techniques
that make teaching much
Andreas Mohr wrote:
Hi,
On Mon, May 09, 2005 at 07:19:31AM -0400, gslink wrote:
I wouldn't worry about anyone but Microsoft stealing Wine. In order to
develop Wine you must be an expert C++ programmer. That requires an
enormous amount of work and thieves are usually lazy.
Maybe you wouldn't
I recently took the list of applications from headquarters that are
listed as running properly and found that many of these are available
for little cost. I bought a few and tried to run them. Not a one ran
as is from the box. I was able to get all of them to run with some
trouble. One big
Paul van Schayck wrote:
On 5/9/05, gslink [EMAIL PROTECTED] wrote:
I recently took the list of applications from headquarters that are
listed as running properly and found that many of these are available
for little cost. I bought a few and tried to run them. Not a one ran
as is from the box. I
Paul Millar wrote:
On Monday 09 May 2005 16:11, you wrote:
Paul van Schayck wrote:
Where would this list be? As of now there is no list of applications
we try to keep working with every released snapshot. [...]
Go to the Wine HQ site and click on applications database.
I think Paul wanted to
The RH updates for FC3 include a new version of gcc. If you install
this it causes problems with things like the kernel and Wine. The Wine
CVS will not compile with the new gcc 4. I have not had time to find
out why.
I have noted for some time that the winsock in Odin, the OS/2 version of
Wine, seems to work better than the one in Wine. This might figure in
conformance testing and in Wine updates.
Here is something else to consider. With respect to property taxes, who
owns a piece of software and who is liable for the taxes on it? Some of
the current licenses may well make the software seller and not the buyer
liable in some states.
The other day I came across a wrapper for wireless lan drivers that uses
the XP driver and loads it into Linux. Driver interfaces in Windows are
fairly standard for a certain type of device. I suggest you look on the
web for sites that list drivers and see if something like this is
One of the Freecell versions in my test suite began to fail with the
September release. Freecell returns an out of memory error. The reason
appears to be that it thinks the bitmap is oversize. The actual cause
is a CreateCompatableBitmap with a width of 6291527. I could find no
other case
I notice that a problem has been detected with Fedora Core 2 but has
anyone checked Core 3? That is the one in directory 1.92.
If you feel that that will handle the problem without causing another
then please submit the patch. I suspect a flag in config is not
necessary but people who submit patches to something as complex as Wine
without fully understanding the problem usually cause a problem.
I find the following program to be an excellent test program for
anything that acts like Windows. The program is Vast and may be
downloaded from http://www-306.ibm.com/software/awdtools/smalltalk/.
The program you want is the 6.0.2 fixpack which is also a fully
operational evaluation version
It appears that a check needs to be made in ps.c. The method
PSDRV_WriteSetFont passes the parameter size. In some early Win 95
versions there was a bug that required that parameter to be negative and
some early windows programs make size negative. This produces garbage.
It appears that
43 matches
Mail list logo
