Steven Edwards schrieb:
> On Tue, Apr 29, 2008 at 10:44 AM, Paul Chitescu <[EMAIL PROTECTED]> wrote:
>> Windows doesn't do that - when my application tries to load a module that
>> links against a missing DLL then LoadLibrary simply fails without showing
>> any message. The "ignore it if LoadLib
Paul Chitescu schrieb:
On Tue, 29 Apr 2008, Peter Beutner wrote:
Steven Edwards schrieb:
On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards
<[EMAIL PROTECTED]> wrote:
On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> 2. You never clear that environment v
Steven Edwards schrieb:
> On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards <[EMAIL PROTECTED]> wrote:
>> On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>> > 2. You never clear that environment variable... what happens
>> > when an app just tests for the existence of a DLL
Rolf Kalbermatter schrieb:
> Peter Beutner wrote:
>
>> just tested again with current git and it worked with every gcc version
>> I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
>
> And what did you test there?
That safedisc 2.x works. Wine successfully passes the s
Peter Beutner schrieb:
> John Klehm schrieb:
>> On Dec 18, 2007 9:43 AM, Peter Beutner <[EMAIL PROTECTED]> wrote:
>>
>>> As I recall this is not the only version that causes problems. Plus certain
>>> compiler
>>> flags have an influence as well.
Scott Ritchie schrieb:
>
> Ughthis means that 4.2 for Ubuntu might NOT actually work, and that
> this is why System Shock 2 has been crashing at startup for me.
It usually didn't crash, just exits silently if the check fails, so this is
probably another issue. Anyway all this affects only sa
John Klehm schrieb:
> On Dec 18, 2007 9:43 AM, Peter Beutner <[EMAIL PROTECTED]> wrote:
>
>> As I recall this is not the only version that causes problems. Plus certain
>> compiler
>> flags have an influence as well. And as most distros ship gcc with a bunch
>>
Andrew Riedi schrieb:
> Sometimes Wine has optional features that users want to enable, but that
> require specific headers to compile. For bug reports, and the user IRC
> channel, it seemed a good idea to add an option to Wine to figure out
> what optional features have been compiled into Wine.
Juan Lang schrieb:
> 2. Mr. Focht's contributions are valuable for understanding what MS is
> up to from time to time, but he does use a disassembler, and that's
> not allowed from Wine contributors.
>
That's funny, where wine even includes its own disassembler. Or is
winedbg going to be removed
Tom Spear schrieb:
> Hopefully this will be the last try.
>
> Instead of just checking HKLM for uninstall entries, check HKCU as well.
>
> Converted all instances of entries[numentries-1].xxx to entry->xxx
> Fixed a bug with a trace.
> Ran the file thru kwrite to make SURE there are NO tabs!
> Do
Tom Spear schrieb:
> On 4/24/07, James Hawkins <[EMAIL PROTECTED]> wrote:
>> On 4/24/07, Tom Spear <[EMAIL PROTECTED]> wrote:
>> > This patch makes the wine uninstaller check HKCU for uninstall entries
>> > in addition to HKLM.
>> >
>>
>> +const int numrootkeys = 2;
>> +static const DWORD maxSubkey
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> AFAIK you get the DRVM_EXIT message only when winmm is unloading.
>> Alternatively you could do it in response to the DRV_CLOSE message which
>> winmm
>> sends just before it tries to unload the driver.
>>
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> ok that makes sense. Definitely something wrong in dsound.
>>
>> But I still think that ALSA_DestroyRingMessage should signal any message left
>> in the queue. Imo it just calls for trouble to expect that messages
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> But this only works if DSOUND_Stop and DSOUND_Release are called from
>> different threads, right?
> It is during shutdown, DSOUND has an internal timer/thread called the
> mixer, it calls DSOUND_Stop because we
Maarten Lankhorst schrieb:
> After trying to implement the alsa mixer I came across a problem: If
> winmm is unloading, a deadlock could occur if during unloading it's
> waiting for another thread.
>
> In winmm itself this isn't much of a problem: there aren't any threads.
>
> However, the driver
Maarten Lankhorst schrieb:
> This fixes an interesting deadlock with the alsa driver:
>
> DSOUND_Stop is called, message is added to thread queue.
> DSOUND_Release is called, message is added to thread queue.
>
> Both are fast messages, so second is added before first.
But this only works if DSO
Alexandre Julliard schrieb:
> "Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
>
>> "Peter Beutner" <[EMAIL PROTECTED]> wrote:
>>> @@ -148,6 +148,10 @@ LPWSTR WINAPI GetEnvironmentStringsW(void)
>>> */
>>> BOOL WINAPI FreeEnvi
Dmitry Timoshkov schrieb:
> "Peter Beutner" <[EMAIL PROTECTED]> wrote:
>
>> Make behaviour consistent with GetEnvironmentStringsA.
>> Prevents crash for confused applications which first call
>> GetEnvironmentStringsW and then want to free it with
>&g
Alexandre Julliard wrote:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> But as linux can't just switch on/off the protection for specific processes,
>> wine has to
>> emulate it by marking all readable memory as executable as well. And as all
>> this
Alexandre Julliard wrote:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> Why should this exception be visible to the application?
>> Plus if you make it visible, you can just forget this whole workaround idea,
>> because it won't work reliable anyways.
>
&
Alexandre Julliard wrote:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> Peter Beutner wrote:
>>> Before starting to make this whole noexecute override behaviour
>>> configurable,
>>> it first must work reliable. In its current form there is no gu
Peter Beutner wrote:
> Before starting to make this whole noexecute override behaviour configurable,
> it first must work reliable. In its current form there is no guarantee that
> the check_no_exec() function is actually called, because any other installed
> exception handler mig
Marcus Meissner schrieb:
> On Wed, Nov 15, 2006 at 06:09:40PM +, L. Rahyen wrote:
>>> So for fixing some _broken_ applications this patch unconditionally
>>> disables nx protection for every application running under wine. Seems like
>>> a bad tradeoff imo. (Though I don't know how widespread t
Alexandre Julliard schrieb:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> Alexandre Julliard schrieb:
>>> Peter Beutner <[EMAIL PROTECTED]> writes:
>>>
>>>> Besides i think it's a bad idea to blindly mark pages executable like this:
L. Rahyen schrieb:
>> So for fixing some _broken_ applications this patch unconditionally
>> disables nx protection for every application running under wine. Seems like
>> a bad tradeoff imo. (Though I don't know how widespread these kind of
>> broken applications are. But there are definitly appli
Alexandre Julliard schrieb:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> Besides i think it's a bad idea to blindly mark pages executable like this:
>>
>> "hey, we successfully catched an attempted buffer overflow attack, thanks
>> for NX. But
Marcus Meissner schrieb:
> On Wed, Nov 15, 2006 at 05:58:44PM +0100, Peter Beutner wrote:
>> Mike McCormack schrieb:
>>> ---
>>>
>>> This should fix bug #6622.
>> The application in question doesn't crash because it needs an executable
>> st
Mike McCormack schrieb:
> ---
>
> This should fix bug #6622.
The application in question doesn't crash because it needs an executable stack,
but because the
PE image header of the exe is totally broken, no section is marked as
executable there at all.
Wine does exactly what it should do here(sa
Marcus Meissner schrieb:
> On Mon, Nov 13, 2006 at 08:54:33AM +0100, Peter Beutner wrote:
>> Putting code in the .data section means it will be mapped RW only, causing
>> segfaults when trying to execute it (at least on NX-capable systems).
>>
>> As a quick workaround
Joseph Garvin schrieb:
> Aaron Slunt wrote:
>>> Wine is still beta software, it has never been officially released,
>>> therefore you have to expect these sorts of things.
>
> I think that misses the point. Users expect software to improve between
> releases, not totally break. It's pretty obvious
Hi
Ge van Geldorp wrote:
>
> If there is genuine interest to make this work I could put up a few mock
> webpages to get a better idea of how it would work.
>
maybe it is worth looking at patchwork?
---
PatchWork is a web-based patch tracking system designed to facilitate the
c
Chris schrieb:
> It might be possible to guesstimate the available memory:
> http://delphi3d.net/articles/viewarticle.php?article=texman.htm
>> quoting from the article:
>> ---
>> The implementation of the glAreTexturesResident() function, which is
>> so critical for this technique, has not
Vijay Kiran Kamuju schrieb:
> May be using we can use the internals of lspci and pciutils.
> So that we can calculate the VGA memory on the fly.
>
> On 7/13/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
>> > I'd say it needs a framebuffer device which I do not have
>>
>> Use the PCI variant ;-).
Mike McCormack wrote:
Peter Beutner wrote:
I thought they started auditing their code and removing any "dirty"
parts?
And according to their website this process is nearly done.
Unfortunately, the fallout of their audit process has been that many
trusted developers left the proj
Mike McCormack wrote:
Christian Gmeiner wrote:
Partially implement SetupDiGetClassDevsExA. This patch bases on
reactos setupapi.dll.
Don't be suprised if your patch isn't accepted. ReactOS is considered a
dirty reverse engineering project by many, and Alexandre has rejected
patches using th
Molle Bestefich wrote:
Peter Beutner wrote:
Because it is the defacto standard to store settings
under ~/..
Only for stuff that's thought to be generally uninteresting.
well, speaking of system.reg, user.reg and dosdevices/, I think they
are "generally uninteresting".
And if
James Hawkins schrieb:
On 6/3/06, Stephen Clark <[EMAIL PROTECTED]> wrote:
>
>"Tabs are not forbidden but discouraged. A tab is defined as 8
>characters and the usual amount of indentation is 4 characters."
>
>
A tab is not defined as 8 spaces - it is defined as go to the next TAB
STOP! The tab
James Hawkins schrieb:
We do have a consensus about tabs vs. spaces. To quote the page I
sent you in the last message:
"Tabs are not forbidden but discouraged. A tab is defined as 8
characters and the usual amount of indentation is 4 characters."
More and more this is being followed, but we wo
James Hawkins schrieb:
On 6/2/06, Aneurin Price <[EMAIL PROTECTED]> wrote:
How about setting a standard that will be used in the repository, and
providing the indent commands to set it that way, then indenting *every
file* in the repository to that standard. Then every developer can use
indent
Vitaliy Margolen schrieb:
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote:
There is precious little "Why" in the comments of a lot of projects - Why
does this function exist, why would I call it, why does it return what it
does, etc.
BS comments like those within the function don't help, ob
Louis. Lenders schrieb:
Hi, i just upgraded to fedora core 5 (from fedora 3)
In my old system i had about 20 wine-versions (back to april 2004) installed which was great for tracking down regressions.
Trying to compile older wineversions now on my new installation fails with various errors (like
Karsten Elfenbein schrieb:
I wonder if the d3d9 code requires those changes as well.
nope
Alexandre Julliard schrieb:
> Your mistake is to assume that the app will handle the error in a sane
> way. That's extremely unlikely, especially for things like bad
> pointers since the app obviously didn't expect to be passing bad
> pointers. If the app really wants to handle that sort of error i
Hi
Andreas Mohr schrieb:
> Hi,
> Can you mention an example of Windows popping up an error message "function
> foo baz called with invalid parameter ..., what do you want me to do?".
> See? Me neither...
heh, the message will more likely looks like
"Failed to initialize {Direct3D/DirectDraw/OpenGL
Alexandre Julliard schrieb:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>> Or look at it from the view of a user developing a winelib application. I'm
>> sure
>> he will very much appreciate it when wine does a better parameter checking
>> than MS
&
Hi
Andreas Mohr schrieb:
> On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote:
>> Imo a library is supposed to validate given parameters as much as possible
>> and
>> rather return an error to the caller than to crash.
> We're not a library.We're a ver
Francois Gouget schrieb:
> * or the application does not pass a NULL here because it would cause
> it to crash on Windows. But if we merely return an error the application
> will merrily go on, only to crash or report that DirectX does not work a
> while later. By then the source of the problem wi
H. Verbeet schrieb:
> On 07/03/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>> This doesn't really make sense to me - the point of unspecified behavior
>> if a parameter is NULL would be to speed up the function under contract
>> with the caller. If you're already doing the check, why not handle it
Hi
> I'll look at this, the whole palette code is a bit messy. My suspicion is
> that
> IDirectDrawPaletteImpl_SetEntries / IWineD3DPaletteImpl_SetEntries doesn't
> update all surfaces that use a palette.
That's indeed the reason. Simple fix is to set the rendertarget usage also for
ddraw offs
Stefan Dösinger schrieb:
> Hi,
> I've brought my DirectDraw over WineD3D patch in a form where I want to show
> it to the public for review. I've uploaded it to
> http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below
> the game list).
nice work :).
I just looked a bit int
Uwe Bonnes schrieb:
> Hallo,
>
> as stated by some bug entries, the msvcrt implementation of strtod()
> understands 'd' and 'D' in addition to 'e' and 'E'. I have stumbled apon
> places, where this is needed. The gnu implementation
> doesn't understand 'd' and 'D', so we need out own implemenation
Roderick Colenbrander schrieb:
> On Monday 20 February 2006 16:05, Roderick Colenbrander wrote:
>> On Monday 20 February 2006 13:12, Daniel Skorka wrote:
>>> Hi,
>>>
>>> wine-0.9.8 has a regression with the Max Payne demo. The demo worked
>>> fine in 0.9.7, however the following is broken in 0.9.8:
Uwe Bonnes schrieb:
>>>>>> "Peter" == Peter Beutner <[EMAIL PROTECTED]> writes:
>
>
> Peter> Which means that '7.8912654773d210' is the same as
> Peter> '7.8912654773e210'.
>
> Running the test with native m
Uwe Bonnes schrieb:
>> "Louis" == Louis Lenders <[EMAIL PROTECTED]> writes:
>
> Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
> Louis> atof. Is there a difference between linux' atof and msvcrt's one?
> Louis> Even following simple program (from msdn) yields
Walt Ogburn schrieb:
On Mon, 2 Jan 2006, Marcus Meissner wrote:
Hi,
requesting comments...
This patch reduces the attack vector on metafiles.
I originally wanted to filter only SETABORTPROC,
but there are a lot of things that might be used
to inject code.
Comments?
Would it not be bett
Michael Jung schrieb:
On Friday 16 December 2005 15:41, Peter Beutner wrote:
Don't get me wrong I still think it is perfectly valid that wine is doing
that sort of hack to get existing windows applications working but you
really shouldn't advertise it as a solution to platform indepe
Dmitry Timoshkov schrieb:
"Peter Beutner" <[EMAIL PROTECTED]> wrote:
Why? Wine is effectively just a different toolkit, like QT or GTK
(albeit much larger) that give applications a Windows, KDE and Gnome
look respectively. Take Notepad for example - with some slight
modific
Michael Jung schrieb:
On Friday 16 December 2005 12:54, Peter Beutner wrote:
Let's just look at the problem with the memory layout. Wine relies on the
possibility to load certain codes at fixed addresses as this is how it
works under windows. Linux choose exact the opposite direction, i.e
James Liggett schrieb:
I really fear that this will end up with vendors loudly advertising linux support and
proudly putting linux stickers on their products where everything you find inside are just
the same windows .exe files and a readme stating that these will work fine with wine.
Which at
Michael Jung schrieb:
On Friday 16 December 2005 10:49, Peter Beutner wrote:
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff
wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn
Robert Shearman schrieb:
Peter Beutner wrote:
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising
linux support and proudly putting linux stickers on their products
where everything you find inside are just
Scott Ritchie schrieb:
On Tue, 2005-12-13 at 22:33 -0800, Dan Kegel wrote:
I used to hate the term ISV (Independent Software Vendor) since
it sounded so acronymy compared to 'developer', but it's
very commonly used in the industry to refer to outfits which
are trying to write and sell off-the-s
Molle Bestefich schrieb:
> The patch is fine and all, but if I'm right and there's a lot of
people using OS drivers that doesn't support the features needed (thus
making performance worse), this patch should be optional and not
replace the current working stuff..
as far as I understood it this p
Vitaliy Margolen schrieb:
> Sunday, December 11, 2005, 11:23:18 AM, Peter Beutner wrote:
>>The name suggests it's more about signal handling than a place to throw every
>>arch
>>dependent code in it ;)
>>But that's not the point.
>>I just thought it
Vitaliy Margolen schrieb:
> Sunday, December 11, 2005, 10:36:39 AM, Peter Beutner wrote:
>
>>Vitaliy Margolen schrieb:
>>
>>>Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote:
>>>
>>>
>>>>Vitaliy Margolen schrieb:
>>>>
Vitaliy Margolen schrieb:
> Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote:
>
>>Vitaliy Margolen schrieb:
>>
>>>ChangeLog:
>>>ntdll: Program could modify Dr* registers in segv_handler too.
>>>
>>
>>Doesn't every exception h
Vitaliy Margolen schrieb:
> ChangeLog:
> ntdll: Program could modify Dr* registers in segv_handler too.
>
Doesn't every exception handler could modify these registers?
So probably it would be better to put this check into RtlRaiseException?
Lionel Ulmer schrieb:
> On Mon, Dec 05, 2005 at 10:22:23PM +0100, Peter Beutner wrote:
>
>>Isn't indirect rendering always unaccelerated, i.e. done in software?
>
>
> Nope. Indirect means only that all your OpenGL commands are encapsuled into
> GLX commands a
Lionel Ulmer schrieb:
> On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote:
>>This patch seems similar to glSDL where it wraps SDL's 2d API to
>>OpenGL. The good thing about this it can provide acceleration and not
>>require root like DGA. The bad thing with this idea is that it can't
>>b
keep wine-devel list cc'ed.
James Trotter schrieb:
> On 11/29/05, Peter Beutner <[EMAIL PROTECTED]> wrote:
>>
>>I think we should rather get rid of including
>>/usr/include/X11/Intrinsic.h.
>>The code in x11drv which include this header doesn't even
James Trotter schrieb:
> I also encountered another quirk, and needed to install libxt-dev, because
> the header file /usr/include/X11/Intrinsic.h was missing. The Wine package
> should probably depend on libxt-dev.
I think we should rather get rid of including /usr/include/X11/Intrinsic.h.
The c
L. Lenders schrieb:
> Hi, first the good news: the Doom3 demo is just
> running with current cvs! See screenshot. Wine is
> really growing mature, great work develolpers. I also
> own this game, and after applying a no-cd patch tried
> to run it. However it crashes after saying
> err:opengl:X11DRV_
[EMAIL PROTECTED] schrieb:
> So is the conclusion that users need to set up a special new user with
> super restrictive rights to protect the system from bugs in wine?! My
> confidence in wine has just taken a knock.
It's the other way around.
This never would have been possible with a normal use
Hans Leidekker schrieb:
> On Friday 18 November 2005 02:05, Juan Lang wrote:
>
>>Someone proposed a hack where the loader would know that these DLLs are
>>dummies based on a wine-specific flag in the header.
>
> Why a dummy? Why not ship a full PE DLL with a flag saying it's a built-in?
> That wa
Raphael schrieb:
> On Thursday 17 November 2005 19:17, Lionel Ulmer wrote:
>>>Thanks for the hint. :)
>>>So something like the attached patch would be ok?
>>
>>Well, it looks OK for me so you can submit it.
>
> For me too
Patch sent. Thanks for your answers. :)
Hi
There is yet another issue preventing SeriousSam from working.
It fails to load opengl32.dll because before loading the dll it makes sure it
can find it
via SearchPath().The problem is that SearchPath doesn't know about the builtin
dlls
provided by wine, so it fails to find them and SeriousSa
Raphael schrieb:
> You can provide a similar behavior with opengl:
>
> from
> http://rzaix12.rrz.uni-hamburg.de/doc_link/en_US/a_doc_lib/libs/openglrf/glXGetFBConfigAttrib.htm
>
>
> GLX_CONFIG_CAVEAT This attribute defines any problems that the GLX FBConfig
> may have:
>
> GLX_NONE
> No cav
Lionel Ulmer schrieb:
> On Wed, Nov 16, 2005 at 03:21:29PM +0100, Peter Beutner wrote:
>
>>At the moment wine always set the PFD_GENERIC_ACCELERATED flag in
>>X11DRV_DescribePixelFormat.
>>SeriousSam uses this flag to determine if the pixelformat is hardware
>>acc
At the moment wine always set the PFD_GENERIC_ACCELERATED flag in
X11DRV_DescribePixelFormat.
SeriousSam uses this flag to determine if the pixelformat is hardware
accelerated.
If the flag is set it is interpreted as _no_ hardware acceleration available.
Unfortunately MSDN isn't really clear ab
Tyler Nielsen schrieb:
> Ivan Leo Puoti wrote:
> Yeah, the safedisc patch didn't seem to help the issue at all. I really
> hope this isn't debugger checks failing, but I still wonder why a
> seemingly valid command (movaps) is returning a privileged instruction
> exception.
google says:
movaps wi
Robert Shearman schrieb:
> [EMAIL PROTECTED] wrote:
>
>> It seems to be that WinRAR crashes after calling:
>> ImageList_Create(16,16,ILC_COLOR32|ILC_MASK,256,2048)
>> to create the list of icons for ListView control. Wine translates
>> this ImageList_Create to CreateBitmapIndirect 36864x16 and the
Mike McCormack schrieb:
> Peter Beutner wrote:
>> And it's not like -fomit-frame-pointer is such a high-risky
>> optimization flag.
>> Instead it is in general safe to use for 90% of applications out there
>
> If it fails for 10% of applications out there, then
Mike McCormack schrieb:
> zhilla wrote:
>> http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are
>> safe cflags, and it worked until couple days ago, then something is
>> definetly wrong, right?
>
> This is the wrong type of question for wine-devel, and better asked in
> Gentoo foru
julien schrieb:
> Hello!
> Different games do not restore resolution when exiting. I tried to
> modify wine a bit and came to several problems:
> - I used destroy_whole_window api as a point to restore resolution.
> However I am not sure it is not the best place and it does not help in
> some cases
by Linus, then ported to x86_64 by Andi Kleen
see [PATCH] x86_64: Some fixes for single step handling
commit: be61bff789fe44bfb6d9282d8f7eccc860bdcfb6
But it was never applied to the ia32 emulation code which breaks again some
copy-protection schemes under wine when running on x86_64.
Signed
Jesse Allen schrieb:
> On 10/23/05, Peter Beutner <[EMAIL PROTECTED]> wrote:
>>hmm it appearently is a kernel/ptrace issue as Marcus Meissner supposed.
>>I just tested it on x86 and it works fine, while on x86_64 it doesnt work.
>>I will dig a bit further if tim
Alexandre Julliard schrieb:
> Peter Beutner <[EMAIL PROTECTED]> writes:
>
>
>>- as wineserver doesn't detach from the process it will get the next SIGTRAP
>>signal and
>> appearently it seems to ignore that signal
>>- [as nobody cares about the SIGTR
Marcus Meissner schrieb:
> On Sun, Oct 23, 2005 at 08:33:40PM +0200, Peter Beutner wrote:
>
>>Hi
>>I've been trying to get an older game(Heart Of Darkness) to work with wine.
>>Appearently the game uses some kind of copy-protection(securom i suppose)
>>which
Hi
I've been trying to get an older game(Heart Of Darkness) to work with wine.
Appearently the game uses some kind of copy-protection(securom i suppose) which
let wine
abort with the following error: "Trace/breakpoint trap".
After some debugging sessions I managed to reproduce the problem.
See the
Alexandre Julliard schrieb:
Peter Beutner <[EMAIL PROTECTED]> writes:
Any reasons given?
Stability is the obvious reason. And also of course the fact that we
have most of the code we need in ntdll already and none of it in
wineserver.
Yupp most of the code maybe already in ntdll.
B
Ivan Leo Puoti schrieb:
Peter Beutner wrote:
Why implement ntoskrnl as a seperate process plus inventing a new IPC
protocol to talk to it? As you said: "ntoskrnl for windows _is_ what
wineserver for wine.". So why not implement the needed ntoskrnl stuff
into wineserver?
Great
Vitaliy Margolen schrieb:
We need ntoskrnl to run some subset of drivers on wine. Notably cd protection
drivers. They are not a hardware drivers, but a means to access something that
is not accessible from user space. So in a sense ntoskrnl is just a process to
run those drivers in, and send/rece
92 matches
Mail list logo
