On 01/15/2013 01:08 PM, Piotr Caban wrote:
On 1/15/13 7:59 PM, Michael Ost wrote:
On 01/15/2013 03:39 AM, Piotr Caban wrote:
The crash is caused by incomplete FlsFree implementation. There's a
comment in it's code that says what needs to be added:
/* FIXME: add equivalent of ThreadZ
On 01/15/2013 03:39 AM, Piotr Caban wrote:
On 01/15/13 00:32, Michael Ost wrote:
Here's a link to a zip file that includes the prebuilt .exe and .dll
windows binaries that crash in wine. Plus the code.
https://dl.dropbox.com/u/97386125/msvcrt-dll-problem.zip
The crash is caused by incom
On 01/12/2013 05:21 PM, Dan Kegel wrote:
The library in question is using static vc runtime linkage, so _getptd()
is linked in
That's somewhat worrisome. So you have multiple instances
of the C runtime library active in the same app?
Maybe you're not unloading that dll gracefully enough.
Mig
On 1/13/13 1:17 PM, Marcus Meissner wrote:
On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote:
Hi list,
Does anyone know why _getptd() calls would return zero on a DLL that
has been reloaded? Does something happen to the TLS used by _getptd?
At Muse Research we have been struggling
wrong with the values
in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't
for Wine...? Or maybe Wine doesn't reinitialize them the same way when
the DLL is reloaded?
Any hints, thoughts? clues? Thanks!
-- Michael Ost
mes down to the WS_DLGFRAME|WS_THICKFRAME
flags. If they are both present then the window is not visible. Turn on
or the other off in the example and the window shows up.
The second window must have a parent and have the WS_OVERLAPPED style as
well."
Hope that helps.
-- Michael Ost
Muse Research and Development
x27;m having trouble making my way through the
wineserver code, so any tips or pointers would be appreciated!
Thank you,
Michael Ost
Muse Research, Inc.
in
normal operation which confuses GDB. I can send along that patch if you
are interested.
Of course, if you are trying to debug a straight windows application
then all of this is irrelevant! But if you are doing winelib, then these
tricks can help.
-- Michael Ost
On 02/16/2012 11:57 AM, Alexandre Julliard wrote:
prefix (besides, there shouldn't be any reason to run wineboot by hand).
We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not
"kill") all wine apps from a hardware button press. Is there a preferred
way?
Than
t can't be found
since it isn't installed so the loader gives up.
$ wineboot
wine: cannot find L"C:\\windows\\system32\\wineboot.exe"
If it used wine64 instead, it would work.
There must be a reason that wine64 is starting 32bit apps, but I haven't
been able to glean anything from the web.
Thanks for any info,
-- Michael Ost
On 12/23/2011 09:56 PM, Ken Thomases wrote:
On Dec 23, 2011, at 3:10 PM, Michael Ost wrote:
This all makes sense, and pulls the code together for me. Thanks!
You're welcome.
I assume this is a recent development, because I was successfully using gdb
with our last wine version -
On 12/22/11 8:20 PM, Ken Thomases wrote:
On Dec 22, 2011, at 8:14 PM, Vitaliy Margolen wrote:
On 12/22/2011 04:45 PM, Michael Ost wrote:
I'm seeing a SEGV crash when running any wine program with wine 1.3.24 in
gdb but not when running without the debugger. The crash is happening
wine. Could that be an issue?
Hopefully someone out there knows the answer to this readily.
Thanks for your time!
-- Michael Ost
t through the system.
Otherwise I'll submit as soon as I can.
Cheers,
Michael Ost
--- wine-1.1.7/dlls/kernel32/file.c.RPM 2011-11-02 14:04:34.0 -0700
+++ wine-1.1.7/dlls/kernel32/file.c 2011-11-02 14:06:42.0 -0700
@@ -2476,8 +2476,29 @@
{
/* Now look for the file */
Dear list, sorry for the accidental posting! Gah! I hit a premature
ctrl+enter! ... Michael Ost
On 08/22/2011 09:16 AM, Michael Ost wrote:
Louis,
I wonder if the patch referred to here is relevant for the device
Louis,
I wonder if the patch referred to here is relevant for the device
detection we need for the ilok...? I'm kinda shooting in the dark,
without much background, but the message jumped out at me.
- mo
On 08/22/2011 08:06 AM, wine-devel-requ...@winehq.org wrote:
Message: 3
Date: Mon, 22 A
Alexandre Julliard wrote:
Michael Ost writes:
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can launch it with a script that
contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
During develop
Alexandre Julliard wrote:
Michael Ost writes:
The first step would probably be to explain why you need to have an app
with the same name as an existing builtin.
Right, ok.
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can laun
Alexandre Julliard wrote:
Michael Ost writes:
I agree. And that's what your patch does, right? Would you like to
submit it to the wine-patches list? I think the case for it is strong,
especially since (1) you found that it fixes a behavior change in
WINEDLLPATH from November 2006 --- arg
Hin-Tak Leung wrote:
--- On Mon, 25/1/10, Michael Ost wrote:
Alexandre Julliard wrote:
Not necessarily, the behavior could probably be
tweaked, feel free to
suggest changes. You can't require users to set
WINEDLLPATH for normal
usage though, including running from the build tr
Ben Klein wrote:
2010/1/26 Michael Ost :
Alexandre Julliard wrote:
I think it makes more sense to require, as Hin-Tak Leung's patch does, that
a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how
LD_LIBRARY_PATH works for ld and PATH works in bash --- so it'
Alexandre Julliard wrote:
Michael Ost writes:
I think it makes more sense to require, as Hin-Tak Leung's patch does,
that a user put /usr/lib/wine in WINEDLLPATH if they use
WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works
in bash --- so it's expected behavior.
Alexandre Julliard wrote:
Michael Ost writes:
Is this on purpose? It doesn't seem right at first glance. I would
assume that WINEDLLPATH would take precedence. Otherwise what purpose
would it serve?
It serves as an extra path where dlls can be found, but dlls from the
current ru
006 .
--- On Mon, 25/1/10, Michael Ost wrote:
Hi,
I am wanting to direct wine to launch a specific APP.exe.so program
by using WINEDLLPATH during the development of APP.exe.
Unfortunately (and undocumented-ely if you know what I mean)
WINEDLLPATH is superseded by /usr/lib/wine. So if
/usr
first glance. I would
assume that WINEDLLPATH would take precedence. Otherwise what purpose
would it serve?
Thanks for tips or background,
Michael Ost
Muse Research, Inc.
Michael Ost wrote:
The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on .\\c: in
mountmgr.sys doesn't work. The call returns incorrect values that change
at random intervals.
List,
Never mind this one. It turns out that the bug happened due to another
patch to Wine in our source
rnl.com/arc-ioctlbuf.html) says that SystemBuffer should
be where the data is put. Indeed, when I change to SystemBuffer the user
call to DeviceIoControl gets the right values back.
Am I on the right track?
Thanks, Michael Ost
PS: here's a proposed patch...
--- wine-1.1.7/dlls/mountmgr.sys/device.c.
James Hawkins wrote:
> On Thu, Dec 18, 2008 at 12:31 PM, Michael Ost wrote:
>> wine-devel-requ...@winehq.org wrote:
>>> Date: Tue, 16 Dec 2008 13:52:00 +0100 From: "Hoehle, Joerg-Cyril"
>>> Subject: winecfg volume serial
>>> number To: Message-
wine-devel-requ...@winehq.org wrote:
> Date: Tue, 16 Dec 2008 13:52:00 +0100 From: "Hoehle, Joerg-Cyril"
> Subject: winecfg volume serial
> number To: Message-ID:
> <47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de>
> Content-Type: text/plain;charset="iso-8859-1"
>
> Hi,
Maarten Lankhorst wrote:
> Hi Michael,
>
> Michael Ost schreef:
>> Hi list,
>>
>> Every once in a while my boss asks me about 64 bit wine. And today was
>> the day. So what's the status?
>>
>> From my understanding there are two parts to the q
Hi list,
Every once in a while my boss asks me about 64 bit wine. And today was
the day. So what's the status?
From my understanding there are two parts to the question. First, is
anyone using a 64 bit build of Wine? How successfully? Does it pass the
internal wine tests?
And second, is ther
Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
>> When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses
>> __TRY no longer links. It complains that RtlUnwind cannot be found. I
>> can see that RtlUnwind was added to wine/
Rob Shearman wrote:
> 2008/11/6 Michael Ost <[EMAIL PROTECTED]>:
>> Hi all,
>>
>> When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses
>> __TRY no longer links. It complains that RtlUnwind cannot be found. I
>> can see that RtlUnwind was
Hi all,
When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses
__TRY no longer links. It complains that RtlUnwind cannot be found. I
can see that RtlUnwind was added to wine/exception.h, but I am not sure
how to fix it.
I tried adding -lntdll and -lwine to the link command line
Hi,
Is there a way for wineg++ to catch windows exceptions and handle them
as g++ does --- cleaning up stack variables, etc?
My C++ winelib app, built with wineg++, is loading Windows DLLs. I want
to catch windows exceptions from functions that I call from those DLLs.
I need to do some cleanup
Dmitry Timoshkov wrote:
> Michael Ost <[EMAIL PROTECTED]> wrote:
>
>> We are seeing a problem in Metacity where a fullscreen window obscures a
>> second created window that has a particular style: WS_DLGFRAME |
>> WS_THICKFRAME.
>>
>> When window A is
We are seeing a problem in Metacity where a fullscreen window obscures a
second created window that has a particular style: WS_DLGFRAME |
WS_THICKFRAME.
When window A is created fullscreen (WS_POPUP, size matches screen res)
and window B is created as an "owned window"
(WS_DLGFRAME|WS_THICKFRA
"Dan Kegel" <[EMAIL PROTECTED]> wrote:
> http://www.thaibrother.com/blog/?p=1047
> is a fairly thin article about malware in wine;
> it's worth mentioning only because it shows
> the issue is getting discussed more.
As Wine gains functionality --- supporting Windows services, binary
drivers, regi
I know there is some discussion of what should be put in the kernel
module, so I am asking for advice on what to implement... ie. just
handles, everything wineserver does, etc.
The first question is:
Why do you want to do that and what specifically do
you want to achieve?
A smal
for as, and "-m elf_i386" for
ld. But with all the nested calls of wineg++ and winebuild I can't
figure out how to get those options passed in everywhere they are needed.
Any hints? Cheers... Michael Ost
Michael Ost wrote:
Message: 7
Date: Mon, 23 Oct 2006 14:51:34 +0200
From: Helmar Spangenberg <[EMAIL PROTECTED]>
Subject: Starting a Linux application from a Windows application
To: wine-devel@winehq.org
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
As of wine-0.9.16 my winelib app now prints this message at startup:
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address
space, please report
Quick googling finds an old closed bug about this here:
http://bugs.winehq.org/show_bug.cgi?id=2062
Is this important? Is there any more in
wxwidgets 2.6.2 and back to
wine 0.9.2 --- so it's not a recent problem. I am also running FC4 with
Gnome in case that matters.
Thanks for any tips (ouch!)... mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
Does boost::threads + wine threads == happiness?
I would like to use boost threads in my winelib application, but they
need to coexist with threads created using the windows APIs by 3rd party
plugin DLLs. I built a test app that uses the two and they appear to
share both a CRITICAL_SECTION and a b
On Wed, 2006-04-19 at 21:46 +0200, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> >> to add SIGQUIT to the various signal masks in ntdll. But a small
> >
> > Well the signal works without patching ntdll. So I guess that's covered
&g
On Wed, 2006-04-19 at 20:39 +0200, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> > I'll try SIGQUIT, knowing that Wine itself has no intentions of using it
> > any time soon.
> >
> > As far as clean up goes, all I want to do
On Wed, 2006-04-19 at 11:06 +0200, Alexandre Julliard wrote:
> You can certainly use SIGQUIT, but if you are defining your own
> mechanism, using signals is probably not the best choice. Cleaning up
> properly on a signal is pretty hard to do right, and even harder in
> Wine since we use signals fo
ooks too user level and wine-devel is
for Wine coders. I'd appreciate any help with the protocol of all
this...
=======
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
On Thu, 2006-02-23 at 09:30 -0500, Kuba Ober wrote:
> On Monday 20 February 2006 19:34, Michael Ost wrote:
> > We are interested in getting the new Guitar Rig 2 USB foot controller
> > supported in Linux/Wine. It's described here:
> >
> > http://www.nat
.. mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
While you're playing with wine's default registry, could you create a
registry entry for https? It can be just the same as the http rule, e.g.
HKEY_CLASSES_ROOT/https/shell/open/command = winebrowser %1 (or whatever
the http rule ends up being.
I have an app that assumes that entry exists and it
On Wed, 2006-01-25 at 11:13 -0800, Juan Lang wrote:
> I'm not the decider here, really. Alexandre is. While I'd like to see my
> recent patch get in because it removes a lot of unnecessary junk from
> ifenum.c and improves the situation for most people, it's not the end of
> the story. Wine's po
On Wed, 2006-01-25 at 10:42 -0800, Juan Lang wrote:
> > > Although I don't like the idea of predefined limits :) I'll probably
> >
> > Me neither, which is why I used that prominent macro
> > MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or
> > 100?) ethernet interfaces? How
On Tue, 2006-01-24 at 21:44 -0800, Juan Lang wrote:
> > Right. if_nameindex does not return eth0 if I boot up without an
> > ethernet connection. Maybe this is a system dependent thing?
> > I am running on a RH8 based system.
>
> Or a libc thing? I'm running on FC2.
>
> > The if_nameindex code l
On Tue, 2006-01-24 at 22:27 +0100, Eric Pouech wrote:
> Michael Ost wrote:
> > BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't
> > terminate properly. But I'll get to that later.
> you mean (about MYAPP ARGS) when run in eclipse (that it does wor
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote:
> Michael Ost wrote:
> > A while back I posted a question about how to get debugging working with
> > eclipse in fedora 4. I am having some success, so if anyone else out
> > there is interested here's how it is set u
> Hi Michael,
>
>> When you boot a linux box without an ethernet connection, and eth0
>> configuration fails, GetAdaptersInfo does not return MAC address info
>> for eth0.
>> The problem seems to be that enumerateInterfaces (in
>> dlls/iphlpapi/ifenum.c) doesn't create a record for eth0, becau
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote:
> you could (not tested) alternatively:
> - set winegdb --gdb as the name for executing gdb
> - not reset the AeDebug key
> - set the executable to be the real exec (+ .so extension if run from
> the build tree)
> that should work also
> you wo
A while back I posted a question about how to get debugging working with
eclipse in fedora 4. I am having some success, so if anyone else out
there is interested here's how it is set up.
In regedit:
* disabled auto winedbg by renaming AeDebug
I changed HKEY_LOCAL_MACHINE/Software/Microso
I am looking for some expert advice in how to handle unloading
"implicitly loaded DLLs". I have found two issues.
(1) The first is a crash that happens in dlls/ntdll/loader.c
MODULE_FlushModrefs. wine_unload_dll() is called for such a DLL, but
SectionHandle is NULL so the call crashes.
My solut
Does anyone know how to set up Eclipse to debug winelib applications?
I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the
"Debug" window. After Eclipse says "Launching..." there is an error that
says "Process terminated."
After reviewing the winelib debug docs, I found that
> is it possible to link Win32 Wine libraries (*.dll.so) with a Linux
> application. Suppose we have a simple Linux gcc program main.cc
>
> #include
> int main(int argc, char** argv)
> {
> AVIFileInit();
> }
>
> which utilizes Win32 library features. When I try to compile it and
> link I do no
> John Smith wrote:
Before y'all take this too seriously, consider the email address and the
name. "John Smith" at an anonymous hotmail account smells like a troll
to me.
>From my point of view, Wine is a godsend and the amount of work going
into it is fabulous. We at Muse Research depend on your
On Wed, 2005-10-12 at 07:08, Alexandre Julliard wrote:
> The problem is that they resolve to the same symbols in the
> dll. Something like this should fix it:
That did it! Thanks... mo
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
> You shouldn't need to export them, you can still link to the library
> directly at the Unix level, a Winelib dll is still an ELF library.
You are right, and using winegcc helped alot. I can link, but ... then
the program crashes when it runs
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> > I started down this path with some success and then realized that, gulp,
> > I would have to create a spec file for my libraries. Hundreds of C++
> > functions in
Vitaliy wrote on Oct 6:
> I think this is the way it might look like. It's a hack and not the
> real solution.
I tested out your patch from Oct 6 on my CreateFile() ReadFile() test
program and it worked. Just thought you might like to know... mo
With the advent of 20050930 wine can no longer load the shared libraries
used by my winelib app. Are there any docs or descriptions about how to
deal with this change?
I have an app that gets built into, say, ./app/app.exe.so. It uses a
shared library, say ./lib/liblib.so, that uses win32 APIs. To
On Wed, 2005-10-05 at 20:05, Dmitry Timoshkov wrote:
> "Michael Ost" <[EMAIL PROTECTED]> wrote:
>
> > Does this patch look dangerous in any way to those of you who know your
> > way around this code? It's done in NtCreateFile after a bunch of
> > non-
On Mon, 2005-10-03 at 21:08, Dmitry Timoshkov wrote:
> "Michael Ost" <[EMAIL PROTECTED]> wrote:
> > My "solution" (polite term) was to force GENERIC_READ|GENERIC_WRITE
> > access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE.
>
>
On Tue, 2005-10-04 at 04:38, Vincent Béron wrote:
> I posted the RH7.3 & RH8 to sf.net. I intended to make them available
> once all distributions would be compiled/uploaded, but since there's
> demand for them, go to
Thanks! That's a great help. ... mo
On Mon, 2005-10-03 at 21:08, Dmitry Timoshkov wrote:
> > But I did notice that FILE_ALL_ACCESS is a different value in Wine and
> > my VC98 headers from DevStudio 6. In Wine it is:
> > (STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x1ff)
> > In VC98:
> > (STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x3ff)
> > Is
On Mon, 2005-10-03 at 14:31, Bill Medland wrote:
> So what is the status of getting RedHat RPMS again? Are you
> having any luck, Michael?
>
> I am going to be needing RedHat RPMS for Wine very soon, for
> testing purposes. I'd be quite willing to help out but it would
> suit me best if you
On Mon, 2005-10-03 at 12:14, Dan Kegel wrote:
> On 03 Oct 2005 11:20:16 -0700, Michael Ost <[EMAIL PROTECTED]> wrote:
> > Any suggestions for how to handle a difference in file access and
> > sharing handling between Wine (20050830) and WinXP? A program
> > demonstrat
Any suggestions for how to handle a difference in file access and
sharing handling between Wine (20050830) and WinXP? A program
demonstrating the problem is attached below.
A 3rd party installer program for a VST plugin is calling CreateFile
with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_
Can someone who understands wine build issues review this RPM spec file
for me, please?
The RPMs for Redhat 8 are getting pretty long in the tooth on the Wine
downloads page... dating back to May 24. I wanted to build a source RPM
to work with, so I modified the 20050524 spec file for 20050830.
On Wed, 2005-09-21 at 00:57, Uwe Bonnes wrote:
> Our IOCTL handling is a mess.
Seems like it has only been needed and implemented for CDs, so far.
> I had a patch that splitted out IOCTL code handling to separate, loadable
> dlls, but the patch went by unnoticed. Look for Mail from around July 10
On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote:
> Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote:
> > Should I put my code in CDROM_DeviceIoControl? Or handle it in
> > NtDeviceIoControlFile? Should I pass all other IoControlCodes except
> > IOCTL_DISK_DRI
Any suggestions for a good "wineish" way to implement an IOCTL_ call for
an IDE disk?
My winelib app is hosting a Windows DLL that is making an
IOCTL_DISK_DRIVE_GET_GEOMETRY call on an IDE hard disk. ntdll/file.c
NtDeviceIoControlFile is passing this off to ntdll/cdrom.c
CDROM_DeviceIoControl and
On Wed, 2005-04-27 at 10:30, Robert Shearman wrote:
> Michael Ost wrote:
>
> >We have an installer program (for the Native Instruments Komplete VST
> >plugin package) that fails to run because NtAccessCheck is stubbed out
> >--- that's our best guess at this poi
uld I take the FIXME("returns fake
SECURITY_DESCRIPTOR") in GetFileSecurity.
Thanks... mo
===========
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
On Fri, 2005-03-18 at 03:30, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> > With the emulation mode set to "winxp" I can only TlsAlloc 64 indexes,
> > even though the MSDN docs say there should be at least 20 million.
> >
With the emulation mode set to "winxp" I can only TlsAlloc 64 indexes,
even though the MSDN docs say there should be at least 20 million.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/thread_local_storage.asp
Has anyone done any work on this? Any workaround/hackaro
On Wed, 2005-03-16 at 00:32, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> > Wine reports that apps have 2GB of VM in GlobalMemoryStatus, but they
> > actually only have 1GB. Isn't that a Wine bug?
>
> Not really, you do have 2GB of VM
On Tue, 2005-03-15 at 15:55, Uwe Bonnes
(bon_at_elektron.ikp.physik.tu-darmstadt.de) wrote:
> The definition of the task is clear:
> Have a way to tell the kernel to not mmap memory above 0x7fff
> However the implementation is unclear to me:
> - Should this be a new syscall?
> - Or should we se
On Tue, 2005-03-15 at 11:12, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-03-15 at 01:09, Alexandre Julliard wrote:
> > > That's a kernel limitation. If you hack the kernel to start allocating
> > > from low
On Tue, 2005-03-15 at 01:09, Alexandre Julliard wrote:
> Michael Ost <[EMAIL PROTECTED]> writes:
> > will stop at 1,022,976k (1GB) on any wine machine. In winxp it goes up
> > to 2GB, as it ought to.
>
> That's a kernel limitation. If you hack the kernel
On Mon, 2005-03-14 at 20:13, you wrote:
> > * VirtualLock does nothing in Wine
> VirtualLock does nothing in win95,98,ME as well :)
>
> I bet the correct behaviour for wine is to do anything in VirtualLock
> only if you set windows version to NT/2000/XP. Did you do it?
Good point. But the setting
On Mon, 2005-03-14 at 13:16, Raphael wrote:
> seems we have a bug report about that problem (behavior differences)
> http://bugs.winehq.org/show_bug.cgi?id=890
I guess I am adding VirtualLock and VirtualAlloc to the list of APIs
that don't work the same in Wine vs Windows. Bug #890 is about
Virtu
There are major differences in the handling of virtual memory in Wine vs
WinXP that are causing problems for my winelib application. Can someone
provide background and/or workarounds for these issues?
As near as I can tell the main differences are:
* VirtualLock does nothing in Wine
* Wine makes n
On Fri, 2005-01-28 at 12:58, Eric Pouech wrote:
> IMO, the cleanest way would be to add an option (like the --command in gdb)
> which would execute commands out of a file (almost everything is in place,
> you
> just need to pass the name of the file in the call to parser() in winedbg.c).
> Then
On Fri, 2005-01-28 at 12:13, Eric Pouech wrote:
> Michael Ost a Ãcrit :
> > In order to help track down sporadic runtime crashes in our testing
> > process, I have turned on winedbg --auto when wine handles exceptions
> > via the AeDebug registry entry.
> don't us
Is there a way to have winedbg --auto do a backtrace of all the threads
in an app at exception time?
In order to help track down sporadic runtime crashes in our testing
process, I have turned on winedbg --auto when wine handles exceptions
via the AeDebug registry entry.
This is working pretty we
On Tue, 2005-01-25 at 23:58, Rein Klazes wrote:
> On 25 Jan 2005 14:22:40 -0800, you wrote:
>
>
> > > I'm quite certain that many programs use that function for extremely time
> > > critical code
> > > (games, anyone??), and that thus the Windows function is equally highly
> > > optimized,
> >
ing, we are hosed!
The application is an embedded audio plugin player. The audio is
processed with SCHED_FIFO and needs to be as deterministic and fast as
possible.
I hope this fix/change doesn't jeopardize our product's use of Wine...
mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
On Fri, 2004-11-19 at 03:22, Mike McCormack wrote:
> Michael Ost wrote:
>
> > (1) The wine bug (I think) is that riched32.dll is registering the wrong
> > window class name. Here's a suggested patch:
>
> RICHEDIT_CLASS20A is provided by riched20.dll, not riche
I'm re'ing my own post, but I think there's a combination of (1) a wine
bug and (2) user error at work here.
(1) The wine bug (I think) is that riched32.dll is registering the wrong
window class name. Here's a suggested patch:
[EMAIL PROTECTED] dlls]# diff -Naur richedit/richedit.c
richedit.MUSE/
bad class name "RichEdit20A"
// on the console
CreateWindow(TOOLTIP_CLASS, ...)
// no complaint
}
Any help would be appreciated... mo
===========
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
Our Menlo Park, CA based startup is looking for someone with strong Wine
skills to help us support VST plugins in a Wine environment. Plugin
compatibility issues need to be tracked down and solved, either by
patching Wine or our hosting environment.
Deep experience in Wine configuration and develo
Great, thanks! And it looks like gdb 5.2.1 has no problem with stabs
format, or with mixed dwarf and stabs formats.
So, has anyone looked into adapting, say, kdbg, to run winedbg commands?
Cheers (you made my day!) ... mo
On Fri, 2003-09-19 at 10:09, Eric Pouech wrote:
> Michael Ost wr
1 - 100 of 101 matches
Mail list logo
