Is there a specific reason for implementing this function anymore? The
resource savings don't seem worth the new potential for bugs. If all
of them were simply returning FALSE then what would be the loss?
thanks -mike
video-recording sorted at this stage :/
On 10/2/07, James Hawkins <[EMAIL PROTECTED]> wrote:
> On 10/2/07, Mike Hearn <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > If you're on the wineconf mailing list, you already received all the
> > details for this w
Hello,
If you're on the wineconf mailing list, you already received all the
details for this weekend. If you weren't planning on coming, but are
near Zurich and want to tag along anyway, feel free! We'll be on the
5th floor of Freigutstrasse 12:
http://maps.google.com/maps?q=freigutstrasse+12,zur
Yes, it's true! The moment you've all been waiting for!
On 6th/7th October, once more Wine hackers from around the world will
meet to eat, drink, make merry, and discuss the finer details of
reimplementing the Windows API. This year it's Googles turn to host
it, and it'll be at the engineering of
Hi David,
Sounds great! To submit those files, you need to make a patch ... git
can do this but I don't remember the exact command to use (depends on
your setup also). Or you can do it the old fashioned way using diff
directly. Feel free to ask if you'd like more guidance with this.
Once you hav
On Thu, 19 Oct 2006 06:28:28 -0600, Vitaliy Margolen wrote:
> Please don't. Kernel32 is the source of all core functionality. As well
> as winex11drv, user32 and gdi32. No this will generate more broken bug
> reports.
Kernel mainly calls into ntdll these days so you see a lot of wrapper API
calls
Yep, I've done this before but it was an evil, awful hack and I don't have
the patch anymore (probably just as well) :)
The way I did it was just to redirect the first created window, but again,
it was hacky. Hopefully you can find a better way.
On Thu, 19 Oct 2006 00:04:39 +0200, Detlef Rieken
On Mon, 23 Oct 2006 11:59:57 -0400, Sujata Doshi wrote:
> I know I could manually single step via winedbg but I would like to
> automate this process.
WineDbg just uses the debugger APIs like any other app. So you could write
your own program that uses the debugger APIs to do this.
thanks -mike
I usually do a +msgbox,+ole,+olerelay trace to get a basic idea of what's
going on here, moving up to +relay if necessary. If it's Visual Basic
stuff most likely you can see what's going on by monitoring OLE Automation.
Good luck!
-mike
On Wed, 06 Sep 2006 04:25:02 -0700, Damjan Jovanovic wrote:
> I've submitted a test and patch to wine-patches 7
> times now, and received very little feedback, which
> I've always followed.
It may be just that Alexandre is a bit overloaded ... have you tried
chasing him in IRC about it? Vitaliys f
On 8/15/06, James Liggett <[EMAIL PROTECTED]> wrote:
Just FYI--I figured out what was wrong with my X test app. I just needed
to set some size hints on the window, and now the size is perfect when
the window docks. Now I've got my test app, a GNOME program, and some
wine apps all peacefully coexi
On 8/9/06, James Liggett <[EMAIL PROTECTED]> wrote:
way to handle it. What we need to do is get the extended style of the
window, but this seems to involve a bunch of wineserver calls that I'm
not familiar with. Can you help me out on that? Thanks!
You can always stick some needed field in the
On 8/9/06, James Liggett <[EMAIL PROTECTED]> wrote:
Actually, I don't think it has to do with synchronization--I think it
has to do with window mapping.
Ah awesome, good work! I know when I looked at this originally it
seemed you could set a flag that told the embedder whether it was
already ma
On 8/7/06, James Liggett <[EMAIL PROTECTED]> wrote:
Turns out you're right, Mike. If I add a small (2 ms) sleep after the
dock event is sent, things work perfectly. :) But, this really strikes
me as a hack that doesn't stand a chance of getting into Wine. Is there
a better way to slow down the ex
On Sun, 06 Aug 2006 20:10:19 -0700, James Liggett wrote:
> so I suspect that this has something to do with stack problem
More likely it's a speed issue - logging slows the code down a lot which
could "fix" a race condition. X is sort of susceptible to this kind of
thing it seems.
On Sat, 05 Aug 2006 10:32:15 +0200, Alexandre Julliard wrote:
> Still, doing that stuff in APCs is a step in the right direction, you
> just need to make sure you can safely run these APCs from the SIGUSR1
> handler.
How is the thread to interrupt to be selected? I really am not seeing
what's wron
On Thu, 03 Aug 2006 02:08:26 -0500, Thomas Kho wrote:
> APCs are queued per-thread, so I made minimal changes to add a per-process
> APC queue. Of course, this implementation suffers from the limitation that the
> remote process must go into an interuptible wait for the operation to succeed;
> an o
On 8/3/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
The goal is to get rid of the service thread; the service thread was
just there as a placeholder. Once it's gone, signals are appropriate.
The realtime signal is just there as a placeholder until we figure out
how to squeze this down into SIGUSR1 a
On Tue, 01 Aug 2006 20:41:54 -0500, Thomas Kho wrote:
> This is an implementation of CreateRemoteThread and RtlCreateUserThread for
> remote processes that re-introduces a service thread for each process and uses
> a signal to flag pending operations. Operations are guarded by a global mutex
> for
On Thu, 27 Jul 2006 15:05:12 -0700, Chris wrote:
> It does. You don't really have to change anything.
I thought the user would have to change the limit in their startup scripts
or the like? That isn't going to work, we need it to be fully automatic
with no configuration changes needed.
> RLIMIT_
On Thu, 27 Jul 2006 02:18:49 -0700, Chris wrote:
> Or if you still don't want something like that merged in, I'd like to alert
> the author of that patch that it doesn't require root privs to work. It just
> needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).
Thanks for the heads up. I'll let Ale
On 7/16/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
Cloning a new thread is not going to help with this at all, since it still uses
the
Win32 context of the original thread, so it only makes things worse.
What then is the solution? A service thread? I think it'd be OK to
have the hijacke
On 7/16/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
I'd rather not take the chance of doing anything that messes with the
poor thread we're hijacking.Hmm... http://lwn.net/Articles/7577/ makes
me think that converting a linux thread to a win32 thread might
require initializing the thread's TLS a
[forgot to hit "reply to all" instead of just reply ...]
On 7/15/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
The right thing to do would be to promote the linux thread to
be a win32 thread, but as a temporary stopgap, Thomas
had the linux thread just do CreateThread and exit, hoping
that the newly
Heya,
First of all 'mad propz' to you for tackling this. I have no strong
opinion on whether this approach of hijacking a thread is better than
having a service thread, that's Alexandres call. But a few comments on the
way you've done things here:
I don't think there's any reason to use Linux spe
On Thu, 13 Jul 2006 08:06:56 -0500, Jeremy White wrote:
> But I have to confess that git makes my head hurt.
> That just could be because this old dog can't learn this
> trick.
Doubtful, it's always made my head hurt too and I was playing with arch,
svk and similar tools years ago :) I think it's
On Fri, 07 Jul 2006 00:24:49 -0700, Dan Kegel wrote:
> http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
> on exit from a VB6 app due to a _CheckNotSysLevel() error.
> What typically causes these - are they a bug in the windows
> program? And is there a good reference from understanding
> the
That's great, thanks!
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote:
> So, uh, metacity people, under what circumstances would metacity be
> likely to put a window that had sent the proper _NET_WM_STATE_ADD
> message for _NET_WM_STATE_FULLSCREEN behind panels?
Run metacity from the command line so you can se
On 6/27/06, Steven Edwards <[EMAIL PROTECTED]> wrote:
I don't think they are wrong about feeling that the site just seems to
totally ignore OS X. I guess the FreeBSD and Solaris guys feel the
same way reading over recent discussions. Alexandre does not treat
patches from anyone as a second class
On Mon, 26 Jun 2006 08:27:10 +1000, Troy Rollo wrote:
> On Friday 23 June 2006 22:50, Mike Hearn wrote:
>> A very specific legal interpretation that would require the
>> company behind Thinstall to want to hurt the Wine project be careful,
>> none of us are lawyers
On Mon, 26 Jun 2006 04:08:30 -0400, William Knop wrote:
> Oh... Sorry about that. I suppose I did come off a bit critical.
I think your email was OK, but wine-devel gets a constant stream of Mac
users/developers telling us how many Mac users want Wine, how they would
be a big benefit to the projec
On Sun, 25 Jun 2006 02:34:24 +0100, Martin Owen wrote:
> which if we could get our hands on the source code would at least give
> us more information about how this security works and may even allow us
> to work around it perminently with in wine.
The goal is not to work around it, the goal is to
Heya Pauli,
A review is enclosed. To submit a patch please send it to
the wine-patches list, where it'll enter Alexandres queue for review.
Firstly I'm kind of surprised this doesn't require the XCursor extension.
Handling the case of a solid alpha channel by converting it to a mask is
fine but y
On Sat, 24 Jun 2006 15:22:42 +0100, ivanleo wrote:
> Safedisc 2 and above are not supported.
Is the reason why not on the Wiki? Would be cool to get it there if not.
> To run a safedisc protected game, you must run winecfg and
> set the drive type of your cdrom drive to "cdrom" in the drives tab
On Sat, 24 Jun 2006 11:47:51 +0200, Olaf Schmidt wrote:
> Do you handle the OLE-BSTR-stuff directly in wine, or do you
> give that jobs to other Libs in the system (the 0.9.12er winelib-
> update has also changed some dependencies (Gtk, libc* and
> others)?
BSTR (Basic String) is a Microsoft spec
On Sat, 24 Jun 2006 02:15:09 -0700, James Hawkins wrote:
> Ah, didn't know about that tool. You learn something new every day.
Perhaps it should be mentioned in the developer quickstart.
thanks -mike
On Fri, 23 Jun 2006 14:13:18 +0200, Jaap Stolk wrote:
> 200145:Backtrace:
Hmm seems like you are seeing a mixed debugger/app trace there ... gotta
be careful of that!
On Thu, 22 Jun 2006 15:58:58 -0700, James Hawkins wrote:
> The imports for current dlls concerning advapi32 are fine; no need to
> change to delay import. I understand where you're going with moving
> factoring out registration, it's just that advapi32 is not the place.
> I'm not sure where else y
Hiya Jonathon,
I wouldn't worry too much about the negative reactions there, which is a
shame. As Molle has pointed out he is not really a Wine developer. I am
and I'd say that it's totally fine to post such a job advert here, I'm
sure there are people here who would like to find a good job with t
On Tue, 20 Jun 2006 19:32:11 -0600, Vitaliy Margolen wrote:
> Basically you are _stealing_ developers from the project. Because with your
> closed source project such developer will be prohibited from participating in
> the Wine project.
A very specific legal interpretation that would require the
On Tue, 20 Jun 2006 12:49:25 +0200, Jan-Espen Pettersen wrote:
> Can a win32 program expect that it has write access to the memory
> pointed to by the return value of LoadResource with module 0x0040?
> Should LoadResource in some cases copy the memory and return a writeable
> copy of the resour
On Fri, 16 Jun 2006 11:52:37 -0400, Steven Edwards wrote:
> Like the parent said, some installers don't ship with it, they expect
> the OS to have it. Office 2007 only runs on XP and higher and it
> expects the dll to already be there.
So we find some free application that contains it and install
On Fri, 16 Jun 2006 18:24:34 +0900, Dmitry Timoshkov wrote:
> Hello,
>
> this patch works for me with Internet Explorer and Diablo II demo.
I think for full IE support we need more; if you start IE, set it to
fullscreen then quit and restart it the window will now be created
unmanaged. Or at leas
On Fri, 16 Jun 2006 03:56:04 -0400, Steven Edwards wrote:
> What do you mean? I looked at this before and even if we are to use
> libgdiplus we need some way to wrap it in a way the Windows app
> expects.
Why? GDI+ is distributed with applications, so we can put off implementing
it for some time y
On Fri, 16 Jun 2006 08:54:04 -0400, Ulrich Czekalla wrote:
> That's why I like the idea of using COM. All the infrastructure is already
> there. For now we can implement the trash shell object inside shell32 and
> if someone wants to write a OS/X version all they need to do is override a
> registry
On 6/16/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
It's a little harder than that. I experimented with doing this before
and it is necessary to apply that same attribute to all of the functions
exported from libwine and libunicode.
We're already forcing all exported symbols in those librari
On 6/15/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
No, we only want the internal functions to be hidden.
Right, so we set default visibility to hidden then change WINAPI and
WINAPIV to include __attribute__((visibility(default))). That way only
WINAPI declarations are exported.
thanks -
On Thu, 15 Jun 2006 17:28:12 +0200, Alexandre Julliard wrote:
> No, that's only hiding them. It's not a bad thing to do in a second
> step for functions that really need to be global
Can't this be done automatically by winegcc passing
-ffunction-visibility=hidden or somesuch?
thanks -mike
On Thu, 15 Jun 2006 11:04:41 +0200, Alexandre Julliard wrote:
> The existing code should work fine, and yours will return 0 for a 4Gb
> box... It sounds like the problem is in GlobalMemoryStatusEx.
IIRC this API has a quirk w.r.t large memory handling. I remember doing
something to this code a few
Yes this problem with the lack of child windows is most troublesome.
I wonder if there is another way to solve this though. By using
COMPOSITE to redirect the window heirarcy of the embedded window to a
pixmap we can proxy events and copy the pixmap to simulate window
embedding, without actually
On 6/14/06, Jacek Caban <[EMAIL PROTECTED]> wrote:
See http://www.winehq.org/?issue=285#MSHTML%20Update. I'd really like to
use Linux Gecko, but it's impossible because we'd need XEmbed embedder
support that's impossible to implement in Wine (perhaps if we added what
we need to XEmbed spec?). Tha
On 6/14/06, Jacek Caban <[EMAIL PROTECTED]> wrote:
Last week Wine Gecko was mentioned a few times on this mailing list and
I can see that there is no understanding of it. It's not really
surprising as it's a big mess ATM. We can still use Mozilla ActiveX
control (but that needs to be removed) or
On Tue, 13 Jun 2006 16:22:17 +0200, Alexandre Julliard wrote:
> Wine will handle that error properly, but here it sounds like fst (or
> more likely Gtk) has replaced the Wine error handler with its own, so
> Wine doesn't get a chance to handle it.
Yes, that's the GTK+ error handler. Benjamin, this
On Wed, 14 Jun 2006 12:37:21 +0200, Andreas Bierfert wrote:
> What I can offer would be this: add a meta package wine-suite which will
> install all wine
> packages and change the summary of wine so it:
> a) points to the wine-* subpackages so everyone knows they exist
> b) tell them that there is
There seems to be another issue here ... you removed the rpath code with a
link to two bugs that don't seem to indicate that was causing the problem.
Now I appreciate that given RPMs are not relocatable it makes no
difference to your users but I am concerned that a problem apparently
unconnected t
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote:
> Well from a wine perspective I see that this makes sense, but if you take a
> look
> at all the dependencies it is another story...
This is a problem with RPM and not with Wine. If RPM/yum had the concept
of optional dependencies like
Hmm, Wine Doors looks pretty cool. At least, it seems to have a nice UI.
Though I question how much preset "profiles" can achieve these days ...
we're getting closer to not needing them all the time. Maybe if the
profiles can do things like install native MSI/DCOM/MDAC/InternetExplorer
etc it migh
On Sun, 11 Jun 2006 20:26:11 -0700, Chris wrote:
> Aren't icons already created on the global heap? They're created with
> GlobalAlloc16, and (optionally) added to a link list of shared icons.
No, this is a confusing Win32ism. The "global heap" is not actually
global, it's process-local. There *
On Sat, 10 Jun 2006 16:35:45 -0700, Chris wrote:
> Originally GeoShell would show no icon on the taskbar and print
> a lot of fixme messages about it being unsupported. With this patch it now
> (always) shows the Wine glass icon for programs, with no such fixme messages.
Well I guess this is a
On Sat, 10 Jun 2006 21:37:01 -0500, Carl Fongheiser wrote:
> Bad, bad idea. In Windows programming, you *never* call LoadLibrary from
> DllMain. Inside of DllMain, you can't call anything which uses the loader
> lock, because the loader lock is already taken out. As best as I read the
> Wine cod
On Sun, 11 Jun 2006 11:09:10 +0200, Andreas Bierfert wrote:
> Yes it is (ok more like 11 but ok). For me it works for the programs it should
> work on...
We had this problem with Debian, where people didn't install the "utils"
package and apps broke mysteriously. Unless you have a lot of experienc
On Tue, 06 Jun 2006 22:43:27 -0700, Dan Kegel wrote:
> Mike, what was that you were saying about
> there not being any wine hackers who fixed
> problems all around the wine tree anymore?
I consider myself joyfully corrected! :) Go Qingdao!
On Tue, 06 Jun 2006 13:55:15 -0400, Jason Green wrote:
> FYI - I just added a bunch to this page to get us started:
>
> http://wiki.winehq.org/DirectX-Shaders
That's awesome, exactly the sort of thing I was looking for. This sort of
high level overview is very useful for new hackers! :)
thanks -
On 6/6/06, EA Durbin <[EMAIL PROTECTED]> wrote:
I've decided to concentrate my efforts in another area, so I won't be
looking at msi any longer. I admit I 'm no C expert, I'm a web developer by
trade. Though I started to look at the C code to get away from php/perl/ruby
and get aquainted with the
On Tue, 06 Jun 2006 12:36:07 +0100, Mike Hearn wrote:
> Right now we don't set the registry key saying we have IE installed, even
> though many of the DLLs the app probably needs are there and functioning
> correctly. I think the plan is to add this reg key after the last of
>
On Tue, 06 Jun 2006 03:27:52 +, NikNot wrote:
> Indeed! This is something that I found infuriating since I first
> used wine. What possible reason would there be to make this
> a "hidden" directory? From whom exactly should it be hidden
> and why?
Historical reasons. I'm switching this thread
On Mon, 05 Jun 2006 10:23:45 +0200, Jaap Stolk wrote:
> Thanks. but it doesn't seem to fool autocad. I tried:
> WINEDEBUG=+server wine setup.exe > ~/mywinelog.txt
> but it still logs to stout and my system can't keep up with the scrolling.
> Is there a way to watch just the registry read/write ?
Y
On Mon, 05 Jun 2006 10:14:50 -0600, Vitaliy Margolen wrote:
> So until you show us some code that verifies what you are talking about,
> please stay away from the e-mail clinet.
He has done exactly that though not in a form we can put in the test
suite, and he is not "flaming" anybody. I think you
On Sun, 04 Jun 2006 20:43:17 +0200, Jaap Stolk wrote:
> The autocad installer indicated that I needed internet explorer 6.0,
> so I installed that using winetools. (can wine fake internet explorer,
> so i don't need to install the real thing?)
Mostly yes, but that area of code is still being worke
On Sun, 04 Jun 2006 02:51:31 +0200, Alexander Nicolaysen Sørnes wrote:
> This is fixed in Stefan's ddraw patchset.
Awesome :) I look forward to it being merged.
thanks -mike
On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote:
> > This is an elaborate scheme with linked lists in each shader - is that
> > really necessary?
> > I'm very confused after reading the code (but maybe that's just me :)
>
> If we link the programs together every time the Set__Shader() is cal
On 6/5/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
It depends whether it's in a convenient form. For a 100-byte COM file,
it is probably already in its most convenient form.
If, like Rob, you are an i386 ninja master who wields a disassembler
as most of us wield a knife and fork then yes may
On 6/5/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> I'd rather we got out of the habit of doing this seeing as I think git can
> deal with binaries better than cvs can.
There is no point in storing the binaries in the *source* tree, besides
tiny .com file which shows the bug shouldn't take
Lords of Magic works perfectly EXCEPT that rendering is corrupted when it
is using DirectX "fast blitting"; they provide a software emulated
workaround for some truly ancient cards (Matrox Mystique anyone?) and the
game works well in this mode. But it should work properly in DirectX
accelerated mod
On 6/3/06, Mikołaj Zalewski <[EMAIL PROTECTED]> wrote:
OK, I won't insist on aggregation :). As for apartments I've thought
that something like that:
HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED);
/* working with objects with ThreadingModel Both */
if (SUCCEEDED(res)) CoUninitialize();
On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote:
> You can embed a trivial DOS executable as data in the .c file
I'd rather we got out of the habit of doing this seeing as I think git can
deal with binaries better than cvs can.
thanks -mike
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote:
> Are there any problems with using OpenAL for such a purpose?
Probably not, it depends on the exact level of abstraction OpenAL gives.
But it begs the question - why?
thanks -mike
On Sat, 03 Jun 2006 09:43:04 +0200, Alexandre Julliard wrote:
> If it's a solution that can be expanded later on to cover the other
> cases, yes, but not if it's a dead-end.
When this was discussed before the idea of bringing back the service
thread was raised. I still think we should do this, ass
On Thu, 01 Jun 2006 21:51:20 -0500, EA Durbin wrote:
> I don't know how I would run this on windows.
You don't have to, you just need to run it against a native MSI.
As to how to convert your findings into a test case, I guess that may be
trickier. There is some fundamental behavior here that is
On Fri, 02 Jun 2006 20:16:25 +0200, Mikolaj Zalewski wrote:
> Of course when we use COM aggregation instead of a factory pattern we
> will have all the interfaces visible under one CLSID so we will be able
> to construct a IWineTrash directly with the main object hidden behind
> the scene.
Argh
On Sat, 03 Jun 2006 12:03:21 +1000, Jeff Latimer wrote:
> We seem to have a policy of not accepting comments in exisiting code.
We do? I seem to recall having comment patches accepted before. Albiet a
long time ago.
> If I add comments to existing code that clear up a mystery I have found
> th
On Fri, 02 Jun 2006 08:03:46 -0500, Jeremy White wrote:
> And I think I would agree that the Wine server is commented
> about right; it is, imho, a beautiful piece of code.
+1 to that. I reckon I didn't really grok in that deep-down-in-your-soul
way what "good coding style" is until I took time t
On Fri, 02 Jun 2006 12:33:03 +0100, Robert Shearman wrote:
> The lack of comments in your email is more horrifying.
Haha :)
Maybe we should have a new janitorial task "comment code", or maybe
Alexandre should reject patches that don't have enough comments?
The problem I think is that because MSD
On 6/1/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
What about the device node symlink? It's needed for the games alot and
it's the number one thing I get asked for help for now. We don't have
an easy way to detect it, although HAL should be able fix it.
Right well that's us being borked somewher
On 6/1/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
Yes, I'm afraid we'll have to do that by default, there are too many
broken binaries out there.
I think we've only seen a couple of such reports so far given
that the exec bit was never enforced before now it wouldn't be
surprising i
The location CD drives are mounted changes between systems, this patch is
essentially specific to yours. Wine already supports HAL, which should
solve this in a more correct manner (though we have reports it doesn't
work for some games!), so how comes that's not enough?
thanks -mike
On Wed, 31 May 2006 07:26:37 +0200, Pavel Troller wrote:
> The machines are running very similar kernels. Both are hardened with
> exec-shield, but even disabling it on a 64bit by
> 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with
> exec-shield enabled (and doesn't p
On 6/1/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> It's possible to see on wiki the "trust points" positions ? :)
> And on each WWN, see the variations (seems the famous kde buzz) :)
The commit logs contain the time of the change and the time of the
commit, so you could use that to buil
On Wed, 31 May 2006 14:57:06 +0200, Hans Leidekker wrote:
> At the same time we should think of exciting new possibilities that an open
> source implementation of the Windows API brings to the table.
At past WineConfs the possibility of reaching out to Windows developers
was raised, by making it
WoW Has a all chain of checks that go up all the way to rootkit reveler
to make sure the user is not aided by an automatic system, Given the
player an advantage other players do not have. The Memory layout checks
is for making sure the program is not loaded by a Debugger of sorts. Or
that core Dl
On 5/30/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
I can't believe that writing a good test case showing the bug and adding
it to the Wine test harness is such hard thing to do for a good Windows
developer who already knows what he expects from a particular Win32 API.
But most developers w
Interesting.. if MacOSX has a similar memory layout as linux, maybe we
could get Blizzard to include a workaround that is only active when it
sees that it's running under wine/cedega.
Well if you can get the email address of a WoW developer then maybe we
can track down where the problem in WoW i
On Tue, 30 May 2006 16:08:42 +0200, Tomas Carnecky wrote:
> Since WoW also runs on MacOSX, how does the memory layout on MacOSX
> differ from NT and Linux?
I have no idea, but the MacOS and Windows versions of WoW will be
different; probably the bug is only in the Windows specific parts of the
co
On Tue, 30 May 2006 07:14:07 -0700, Dan Kegel wrote:
> Go ahead and retarget those to 1.0, then, please.
OK. I need to talk to Tony, I seem to have lost my bugzilla privs at some
point (probably changing email address).
> I agree that Sun's Java runtime is probably something we should support for
On Mon, 29 May 2006 23:47:26 -0700, Jim White wrote:
> But I do know I set up Darwine because of the antagonistic
> and dismissive tone here when I tried to discuss Darwin & Mac OS X
> development ideas.
I have yet to see anybody give Emmanuel and the other Darwine developers
anything but respect.
Got a reply from somebody who would rather remain anonymous:
-
This may be just me, but the learning curve is probably much more
steep for a "general purpose" hacker than for a particular dll. I have
some apps I'd like to get wor
On Mon, 29 May 2006 21:01:46 -0700, Dan Kegel wrote:
> I suspect a few of these are stale, and a bunch others are missing,
> but I like the idea of using bugzilla to track our progress to 1.0.
Hmm, maybe. Bugzilla lists have a tendency to come and go though as people
nominate their bugs and as the
On 5/30/06, n0dalus <[EMAIL PROTECTED]> wrote:
It would be really great if someone could document the patch and
explain what exactly is stopping WoW from working (as well as which
changes would cause problems for other programs).
It's a bug in WoW itself, it relies upon the exact way NT maps me
As the Summer Of Code begins and new blood joins us all at once,
I thought it'd be a good time to open a discussion on how we are doing as
a project.
Questions to consider:
* Is Wine improving or is the regression rate matching the improvement
rate?
* Are we producing a quality product, fr
1 - 100 of 1566 matches
Mail list logo
