( I have posted a similiar question in wine-users,
don't flame me for doing so, just thinking about this
some more, perhaps it may be more a developer question
)
Ok, I have a windows app, that runs under wine fine -
not quite. This app has a form, with many text field
edit boxes on. Quite often t
On September 18, 2003 08:01 pm, Steven Edwards wrote:
> What do you guys think about a move to a common system
> for after wine 1.0?
I'd say let's get to 0.9 and worry about it then... :)
We are trying to use as many standard tools as possible,
headers, etc. so we are moving in the right direction
This is semi-offtopic but it would be nice if we could get WINE, ReactOS
and Mingw to use the same docbook format and tools. There are parts of the
WINE docs such as the regression test stuff that would be off use to us and
other stuff in mingw. What do you guys think about a move to a common sy
Francois Gouget <[EMAIL PROTECTED]> writes:
> Maybe you just compared the PostScript files? Our Makefile does not use
> print.dsl for generating the PostScript files which I think is a bug!
No I checked the pdf, all I could see was some spacing differences. I
don't think it's a big problem.
> So
On Mon, 15 Sep 2003, Alexandre Julliard wrote:
[...]
> print.dsl doesn't seem to have much effect on my machine so I guess we
> could remove it.
Maybe you just compared the PostScript files? Our Makefile does not use
print.dsl for generating the PostScript files which I think is a bug!
print.dsl
On Thu, 18 Sep 2003, Alexandre Julliard wrote:
> I'm not sure I agree with that. If we make the documentation available
> for download then we should have the FAQ there too, we shouldn't
> require people to go to WineHQ to get it.
I don't know, it maybe just me, for I never expect to see FAQs wi
Stephen Pedrosa Eilert <[EMAIL PROTECTED]> writes:
> Weird... how come Morrowind have started "working" all of a sudden? It
> crashed for me. I wasn't aware of any patches affecting the problem I was
> having with it (the original version, but now I have the two expansions
> available). Time to re
Eric Pouech <[EMAIL PROTECTED]> writes:
> Quite a bit of the initialisation code is still in ntdll.
> How do you see the final move:
> - all initialisation code in kernel32
> - part of it in ntdll, the rest in kernel32
There will of course be parts in ntdll and parts in kernel32, but
initializati
Alexandre Julliard wrote:
ChangeSet ID: 9365
CVSROOT:/home/winehq/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED] 2003/09/17 00:31:33
Modified files:
scheduler : thread.c process.c
loader : module.c
libs/wine : loader.c
dlls/ntdll :
Hi folks,
Here is a little script that generates a table detailing
the i18n status. It works by comparing the last updated
timestamp from CVS of the language file with the master file.
It generates a matrix like this (hopefully it's not wrapped):
Legend:
'.' -- translation appears to be uptoda
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> The fact that the FAQ is now SGML does not warant
> building it in all sorts of formats, and including
> it in the docs tarball. Just because we can, does
> not mean we should.
>
> In fact, theoretically we should move this over
> to the lostwages/
Hi,
thanks, disabling DGA did the trick. Lets hope does fix this bug soon. :-)
Philipp
On Thursday 18 September 2003 17:23, Roderick Colenbrander wrote:
> Hi,
>
> The problem you have is a bug in the dga code of the ati drivers. To
> workaround the problem set the option UseDGA to N in your conf
Sylvain Petreolle wrote:
After doing a 'wineserver -k', some wine processes arent stopped.
Using winedbg and doing a 'walk process' (which starts another
wineserver)
is currently unable to see the wine processes that were created before.
that's normal. winedbg is running (as a process) in the seco
Shachar Shemesh wrote:
Mike Hearn wrote:
This is very much like a problem I am having with InstallShield.
Something, somewhere, is trashing the heap data structures, which causes
a crash some time later, often yards away from the original bug. As far
as I know, there is no good way to spot this pr
[WinMM]
Drivers regedt no no
WaveMapper regedt no no msacm.drv
MidiMapper regedt no no midimap.drv
will need in the future a more robust configuration scheme, especially
if we want to get rid of the hacks to pair MM devices and dsound devices.
By to you mean a default value has to be computed b
Mike Hearn wrote:
This is very much like a problem I am having with InstallShield.
Something, somewhere, is trashing the heap data structures, which causes
a crash some time later, often yards away from the original bug. As far
as I know, there is no good way to spot this problem, it's just C/C++
Pavel Roskin wrote:
Hello!
I see two solutions. One is to link wine executable against kernel32.dll.
I don't think you can do that. As kernel32.dll requires ntdll, you would
create a real circular dependancy.
Another is to use the low-level function interlocked_cmpxchg_ptr(), which
is what
Hi,
The problem you have is a bug in the dga code of the ati drivers. To
workaround the problem set the option UseDGA to N in your config file. The strange
part is that dga only works for root users and that this problem also appears
for non-root users.
Roderick
> Hi,
>
> I'm using the wine CV
Did winecheck say you have a problem ?
You can try to use ttydrv, or :
from a TEXT console, set DISPLAY like this :
export DISPLAY=localhost:0
and try to run 'wine wcmd' or another text-only program from here.
or run
wine notepad.exe & > logfile.
you will be able to see what wine reports since y
Hi,
I'm using the wine CVS version, compiled from source. I just looked at these
URLs and will submit a bug report to bugzilla, after I've tried an older ATI
driver. I can't go back to text mode, I have to reboot to get my screen back
to life. If you need a process list, I can connect to my PC
You didnt give any info on wine configuration -
version, binary/source...
See http://www.winehq.org/site/docs/wine-user/config-graphics-driver
and http://www.winehq.org/site/docs/wine-user/bugs to troubleshoot your
install.
First try : see if you can go back to text mode with Ctrl-Alt-F1 and
look
On Wed, 17 Sep 2003, Robert Reif wrote:
> Adds volume and pan support to primary buffers.
> Adds more property set support.
Please include all the diffs into one file so it
can be easily reviewed. If you can also inline
that file, that'd be great:
http://www.winehq.org/site/sending_patches
Hi,
I recently installed Mandrake 9.1 and updated it to the newest packages .. I'm
using the ATI fglrx 3.2.5 driver for XFree 4.3.0 (I have a Hercules Radeon
9700) and playing 3D games like tuxracer works great. However, when I try to
start any program with wine my screen gets dark and goes int
Dimitrie O. Paun wrote:
+ Remove . from default library search path
This may break Winelib apps. Did you check that MinGW does not
search . for libs?
Yes, of course I checked. If any winelib apps break, then they are
broken and need fixing.
+ -lwine needs passed in -L paths
What do you mean
flyker wrote:
> After install version 20030911 i run very simply program compiled with
> wine and after it the system (RedHat 9.0) become very slow,
> it does not respond keyboard and mouse and it much use hard disk.
> I think it alloc memory in cycle.
> After some time the system kill wine.
> Inst
On September 18, 2003 07:13 am, Richard Cohen wrote:
> This is needed for winegcc to build wine itself
>
>+ Remove . from default library search path
This may break Winelib apps. Did you check that MinGW does not
search . for libs?
>+ -lwine needs passed in -L paths
What do you mean by t
On September 18, 2003 07:37 am, Richard Cohen wrote:
> +extern void fatal_error( const char *msg, ... )
> + __attribute__ ((__format__ (__printf__, 1, 2)));
> +extern void fatal_perror( const char *msg, ... )
> + __attribute__ ((__format__ (__printf__, 1, 2)));
> +extern void error( const char
On Wed, 2003-09-17 at 22:45, Dan Kegel wrote:
> Thanks for looking into it. This sounds like a job for valgrind;
> have you tried running wine under valgrind 1.9.6-wine before?
No. I've used valgrind before, but not the wine version.
> OK, I'll try installing IE. (Dumb question: what's the best
This is very much like a problem I am having with InstallShield.
Something, somewhere, is trashing the heap data structures, which causes
a crash some time later, often yards away from the original bug. As far
as I know, there is no good way to spot this problem, it's just C/C++
sucking maybe v
For Marcus Meissner,
Concerning the file dll/oleaut32/tmarshal.c, I have added a check for a
result function. Below, the modified function with (SUCCEEDED test). It
prevent a crash in my application.
I don't no if the test: if (hres)... is writted to be equivalent of :
if (SUCCEEDED(hres))...
??
Dmitry Timoshkov [mailto:[EMAIL PROTECTED] wrote:
> "ilmcuts" <[EMAIL PROTECTED]> wrote:
>
> > Check a Win9x version of shell32.dll; also check
> shdocvw.dll (ordinal 118)
> > and shdocvw401.dll. One of them exports the function by name on some Win9x
> > version. The correct name is "ShellDDEI
After install version 20030911 i run very simply program compiled with
wine and after it the system (RedHat 9.0) become very slow,
it does not respond keyboard and mouse and it much use hard disk.
I think it alloc memory in cycle.
After some time the system kill wine.
Installation witnout nptl.
Pr
"ilmcuts" <[EMAIL PROTECTED]> wrote:
> Check a Win9x version of shell32.dll; also check shdocvw.dll (ordinal 118)
> and shdocvw401.dll. One of them exports the function by name on some Win9x
> version. The correct name is "ShellDDEInit". I'm not sure where the true
> implementation is located,
33 matches
Mail list logo
