--- Segin <[EMAIL PROTECTED]> wrote:
> There is one reason, inarguable (if you reply to
> this you have a IQ of
> 0) as to why WineTools is useless: Most of the
> WineTools 'magic' is in
> it's ~/.wine/config file, which Wine no longer
> uses/acknoleges, thefore,
> WineTools is utterly useless a
Tomas Carnecky wrote:
Huw D M Davies wrote:
On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote:
Ah right, glDrawBuffer alters the rendering state, that's bad. We
should presumably be calling glXSwapBuffers here (but only in the
GLXPixmap case).
Which of course won't work either.
There is one reason, inarguable (if you reply to this you have a IQ of
0) as to why WineTools is useless: Most of the WineTools 'magic' is in
it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore,
WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
[EMAIL PROTECTED] wrote:
Hi Karl,
I would love it if people would get involved, a few good coders can have
SVN/trac access I'll work on opening up to the public soon.
pygtk/pyxml/wine hackers/shell scripters very welcome.
Maybe I can help with bash scripting (very good skill) I kn
Monday, March 27, 2006, 3:17:12 PM, Tom Spear (Dustin Booker, Dustin Navea)
wrote:
> Tony Lambregts wrote:
>> Alexandre Julliard wrote:
>>> Module: wine
>>> Branch: refs/heads/master
>>> Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
>>> URL:
>>> http://source.winehq.org/git/?p=wine.git;a=co
Hi Karl,
> I would love it if people would get involved, a few good coders can have
> SVN/trac access I'll work on opening up to the public soon.
>
> pygtk/pyxml/wine hackers/shell scripters very welcome.
Maybe I can help with bash scripting (very good skill) I know
nothing about pyth
Tony Lambregts wrote:
Alexandre Julliard wrote:
Module: wine
Branch: refs/heads/master
Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
URL:
http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
Author: Alexandre Julliard <[EMAIL PROTECTED]>
Date:
Alexandre Julliard wrote:
Module: wine
Branch: refs/heads/master
Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
URL:
http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f
Author: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Mon Mar 27 22:43:03 2006
Robert van Herk wrote:
sorry for my bad english i am not feeling well and it is affecting my
corrdination, i can't walk right or type correctly. i can barely see
the monitor, it's that bad.
Don't worry, probably it's just a virus.
Regards,
Robert
yeah, i think i got the karma-sutra or
sorry for my bad english i am not feeling well and it is affecting my
corrdination, i can't walk right or type correctly. i can barely see
the monitor, it's that bad.
Don't worry, probably it's just a virus.
Regards,
Robert
> maybe if we put in a md5sum database of viruses and refuse to run those
> that are viruses?
You mean worms? Viruses modify existing files and thus it's pointless to
check whole-file checksums. Signature checking has significant runtime
impact (say a second just to get one .exe checked), so it's
Jason Green wrote:
On 3/27/06, Segin <[EMAIL PROTECTED]> wrote:
Due to the current state of Wine, plus it's archjitechure, Even if a
virus was found, it is much easier to remove.
If the virus is a memory-resident kind, you can do pkill -9 wine as root
or your user and shut down il
On 3/27/06, Segin <[EMAIL PROTECTED]> wrote:
> Due to the current state of Wine, plus it's archjitechure, Even if a
> virus was found, it is much easier to remove.
>
> If the virus is a memory-resident kind, you can do pkill -9 wine as root
> or your user and shut down ile essentially killing said
Philip V. Neves wrote:
On the website there is an article that talks about homogenious
populations being a threat to society and to the computer industry.
Although I accept the fact that this is mostly true I believe that is
a good argument for creating the Linux OS and other OS's not for
cre
> So theoretically a virus could spread just as
> easily through a wine system as well as a Windows
> system. That virus could spread even if the
> security in Linux is in place. The wine
> installation could be affected and we have to
> reinstall the wine directory.
Take a look at this. It's
On the website there is an article that talks about homogenious
populations being a threat to society and to the computer industry.
Although I accept the fact that this is mostly true I believe that is a
good argument for creating the Linux OS and other OS's not for creating
wine. With the wine
At 2006-03-24 22:26 -0500, Segin wrote:
I was thinking about running Wine on Interix (the POSIX layer of
Microsoft's Services for Unix). There are a few apparent unknows:
Would Wine load the .dll.so's? Since Interix uses PE for it's native
format (running on Windows, duh), Would Wine load the
Huw D M Davies wrote:
> On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote:
>> Ah right, glDrawBuffer alters the rendering state, that's bad. We
>> should presumably be calling glXSwapBuffers here (but only in the
>> GLXPixmap case).
>
> Which of course won't work either.
>
> We need
Petr Tesarik <[EMAIL PROTECTED]> writes:
> That means that Windows XP creates a new thread in the given process
> and breaks it at DbgBreak().
>
> Does this mean that we may avoid sending SIGTRAP altogether?
Creating a new thread is probably even harder, but yes we can
certainly avoid SIGTRAP. On
On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote:
> Ah right, glDrawBuffer alters the rendering state, that's bad. We
> should presumably be calling glXSwapBuffers here (but only in the
> GLXPixmap case).
Which of course won't work either.
We need to find out what happens to the re
Tomas Carnecky wrote:
I don't know if it even runs.. I mean, if it works correctly.
http://dbservice.com/tom/LinuxTest.exe
It creates LinuxTest.log in the same directory as the executable, and
prints out whether pbuffers are supported and which drawbuffers are
activated..
tom
Well, I ra
On Mon, Mar 27, 2006 at 05:32:12PM +0200, Tomas Carnecky wrote:
> Huw D M Davies wrote:
> > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote:
> >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
> >> And I don't think PBuffers or Pixmaps can be stereo, so is th
--- Begin Message ---
Dne 03/27/06 v 17:16:50 (+0200), Alexandre Julliard napsal(a):
> The thing is that all of this is necessary because you want to handle
> a SIGTRAP sent with kill(). But obviously no Windows application is
> going to send us a SIGTRAP; the only way this will happen is when we
>
Tomas Carnecky wrote:
I have written a test for windows (to test whether wglMakeCurrent
changes the drawbuffer or not), but nobody of my friends has a graphics
card that supportd pbuffers.
tom
I have a GF FX5700. Does that support pbuffers? If so, I'll run the
test
Tom
Dne 03/27/06 v 08:13:23 (-0700), Vitaliy Margolen napsal(a):
> >There is no other way to detect a hardware breakpoint than to look
> >at DR6. Additionally, since the bits would get stuck for all
> >subsequent SIGTRAPs, we need to clear them.
>
> [skip]
>
> Please don't forget here tha
Huw D M Davies wrote:
> On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote:
>> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
>> And I don't think PBuffers or Pixmaps can be stereo, so is there any
>> special reason to use GL_FRONT_LEFT ? Or is it because the sp
Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a):
> Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote:
>
> > Hi,
>
> > this patch fixes a bug in get_thread_context(). Currently, this
> > routine assumes that all registers except debug registers are saved in
> thread->>context if
Petr Tesarik <[EMAIL PROTECTED]> writes:
> Oh, I forgot to mention another thing. I didn't start all this for
> nothing. I made my changes to raise_trap_exception() to make an
> existing application (Kindler Lexikon) work.
Sure, I'm not saying you did this for no reason. I just have the
feeling
Dne 03/27/06 v 16:49:13 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > In my opinion, the solution is reasonable because if any application
> > is really interested in the DR6 register (i.e. it is a debugger), it
> > will clear the status register (DR6) any
Monday, March 27, 2006, 7:58:38 AM, Petr Tesarik wrote:
> Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
>> Petr Tesarik <[EMAIL PROTECTED]> writes:
>>
>> > No, Windows need not do things like that, because the Windows kernel
>> > knows very well, whether it got INT1 or INT3... Som
Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote:
> Hi,
> this patch fixes a bug in get_thread_context(). Currently, this
> routine assumes that all registers except debug registers are saved in
thread->>context if it exists. However, it does not include FPU
> registers.
> IMO, we shou
Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > No, Windows need not do things like that, because the Windows kernel
> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do
> > not give us that information reliably.
>
Petr Tesarik <[EMAIL PROTECTED]> writes:
> In my opinion, the solution is reasonable because if any application
> is really interested in the DR6 register (i.e. it is a debugger), it
> will clear the status register (DR6) anyway, since the processor never
> clears the bits and unless you clear the
Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > No, Windows need not do things like that, because the Windows kernel
> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do
> > not give us that information reliably.
>
On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote:
> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
> And I don't think PBuffers or Pixmaps can be stereo, so is there any
> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so?
See man glXCre
Petr Tesarik <[EMAIL PROTECTED]> writes:
> 2. The x86 spec states that a single-step interrupt (INT 1) is
>generated if the TF bit was set when the execution of the
>instruction BEGAN. This means that if the instruction changes the
>TF bit (e.g. popf), there is an INT 1, but the TF bi
Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins:
> * Add initial tests for RunSetupCommand.
> dlls/advpack/tests/install.c | 106
>
Hi.
Your tests used a fixed Path, resulting to failure on:
- win95, win98 and winme (c:\windows\system
Hi,
I've just submitted a patch that handles the FPU state in signal
handlers. However, the FPU_sig() macro is only defined for Linux, so
other architectures won't benefit from that patch.
I doubt that i387 FPU state is left untouched by the kernel on other
architectures, but I have no access to
On 3/27/06, Pavel Troller <[EMAIL PROTECTED]> wrote:
> Hi!
> I would like to report a regression made by commits issued 2006/03/23 at the
> evening. Just now I don't have bisecting environment available, I've just made
> a simple CVS regression testing and found the above commit (it modifies
> mu
39 matches
Mail list logo
