On Tue, Feb 24, 2009 at 12:49 AM, Dan Kegel wrote:
> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
> is an interesting report; all the malware he tried ran
> to at least some extent on wine.
>
> One interesting bit of advice he gives at the end is
>
Hello Dan,
Maybe run the game in a Virtual Desktop?
Tom
On Tue, Feb 24, 2009 at 1:57 PM, Dan Kegel wrote:
>
> Wow. I just tried LOTRBFME2 :-) and it's impressive.
> Only problem so far is that it doesn't restore video resolution on exit.
> Otherwise it's the coolest game of the sort I've ever
On Sun, Feb 1, 2009 at 12:33 PM, Vít Hrachový wrote:
> Hi Dan
> from top of my head -
>
> Heroes of Might and Magic III
> Wizardry 8
> Lord of the Rings: Battle for Middle-Earth 2
>
> all have free demo downloads and don't require net.
Wow. I just tried LOTRBFME2 :-) and it's impressive.
Only pr
On Mon, Feb 23, 2009 at 4:06 PM, Dan Kegel wrote:
> "Do not set the file association for Windows executables with Wine.
> This would enable running Windows executables in Wine by simply double
> clicking them."
>
> Yes, this will require a modicum of consensus. We might decide
> to st
I think at best it should be up to the distribution to decide to
enable additional security features, which is where most common users
will get Wine from. Maybe display a warning on the download page?
(Gah, Reply to all, sorry Marcel.)
JL
On Tue, Feb 24, 2009 at 3:14 AM, Marcel Partap wrote:
>>
> What about having to mark the exe as +x before Wine will load it? That's
> easilly doable frame any sane filemanager and provides a good level of
> safety.. and Wine already does a good job of making sure installed programs
> get +x.
Wow it actually does, never noticed that up to now :O
The prob
On Monday 23 February 2009 4:28:27 pm Zachary Goldberg wrote:
> I interpret bug-for-bug compatibility to be more than just emulating
> the API bugs so apps run. Its about emulating the experience for
> users to be as close to expectations (set by Windows) as possible.
Can't say I agree with that.
On Monday 23 February 2009 3:58:10 pm Zachary Goldberg wrote:
> I disagree on this point. Is malware via Wine on Linux really a
> problem commonly affecting users? What happened to replicated
> Window's behavior bug for bug? User X might ask: double clicking an
> exe works in Windows why shouldn
2009/2/23 Ben Klein :
> 2009/2/24 Zachary Goldberg :
>> 2009/2/23 Dan Kegel :
>>> Ben Klein wrote:
> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
>
> "Do not set the file association for Windows executables with Wine.
> This would en
On Mon, Feb 23, 2009 at 5:58 PM, Zachary Goldberg wrote:
> 2009/2/23 Dan Kegel :
>> Ben Klein wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
"Do not set the file association for Windows executables with Wine.
This would ena
2009/2/24 Zachary Goldberg :
> 2009/2/23 Dan Kegel :
>> Ben Klein wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
"Do not set the file association for Windows executables with Wine.
This would enable running Windows executabl
On Mon, Feb 23, 2009 at 4:00 PM, Ben Klein wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
"Do not set the file association for Windows executables with Wine.
This would enable running Windows executables in Wine by simply do
2009/2/24 Dan Kegel :
> Ben Klein wrote:
>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
>>>
>>> "Do not set the file association for Windows executables with Wine.
>>> This would enable running Windows executables in Wine by simply double
>>> clic
2009/2/23 Dan Kegel :
> Ben Klein wrote:
>>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
>>>
>>> "Do not set the file association for Windows executables with Wine.
>>> This would enable running Windows executables in Wine by simply double
>>> clic
Ben Klein wrote:
>> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
>>
>> "Do not set the file association for Windows executables with Wine.
>> This would enable running Windows executables in Wine by simply double
>> clicking them."
>>
>> I saw a pat
2009/2/24 Dan Kegel :
> http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
> is an interesting report; all the malware he tried ran
> to at least some extent on wine.
>
> One interesting bit of advice he gives at the end is
>
> "Do not set the file associa
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/
is an interesting report; all the malware he tried ran
to at least some extent on wine.
One interesting bit of advice he gives at the end is
"Do not set the file association for Windows executables with
"Jérôme Gardou" writes:
> Alexandre Julliard a écrit :
>> You certainly don't want to add exports to kernel32 for that. Launching
>> the debugger isn't hard to do in faultrep, plus you most likely want to
>> do it differently from what kernel32 does.
>>
> Is this one too hackish for you ?
Yes
On Mon, Feb 23, 2009 at 6:15 AM, Paul Vriens wrote:
> The reason you see this is because next to a normal LoadLibrary we also use
> the
> .NET variant. On some boxes gdiplus.dll cannot be found through LoadLibrary
> but
> will trough LoadLibraryShim. As winetest now thinks the library is there i
On Mo, 2009-02-23 at 13:38 +0100, Paul Vriens wrote:
> >
> Is .NET installed (any version)?
My w2k test box has the popup about the missing gdiplus and
dotnet is installed.
>From the dllinfo:
gdiplus load error 1359
http://test.winehq.org/data/79cc4163fa4867ce0b28ce83111dc6bc18d3df15/2000_dr-a
Alexandre Julliard a écrit :
"Jérôme Gardou" writes:
Well, launching winedbg instead of printing incomplete information is,
IMHO, the best way to make something useful, and, as you said it,
kernel32 is always builtin, as ntdll, and faultrep is too close of the
system internals to be a tot
"Jérôme Gardou" writes:
> Well, launching winedbg instead of printing incomplete information is,
> IMHO, the best way to make something useful, and, as you said it,
> kernel32 is always builtin, as ntdll, and faultrep is too close of the
> system internals to be a totally winapiesque dll. Afte
2009/2/23 Paul Vriens :
> Nicolas Le Cam wrote:
>>
>> 2009/2/23 Paul Vriens :
>>>
>>> Nicolas Le Cam wrote:
2009/2/23 Francois Gouget :
>
> On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
>
>> This avoid a messagebox in regression tests on systems that don't have
>> GdiPlus
Mikołaj Zalewski a écrit :
>
> Jérôme Gardou pisze:
>> Let's rephrase it : most bug reporters expect the console log to be
>> useful for developers willing to fix their problem :-)
> Maybe I should have made it clear - I think that your patch, even in
> the first version, was a step forward :).
Jérôme Gardou pisze:
> Let's rephrase it : most bug reporters expect the console log to be
> useful for developers willing to fix their problem :-)
Maybe I should have made it clear - I think that your patch, even in
the first version, was a step forward :).
As for the second patch, Alexandre
On Monday 23 February 2009 8:39:22 am Erich Hoover wrote:
> My suggestion (maybe this wasn't clear) was to normally
> output the diagnostic information to the console, but if the console is not
> available (if wine was launched from a desktop icon, for example) then to
> pop up with a dialog.
That
On Sun, Feb 22, 2009 at 7:44 PM, Ben Klein wrote:
> ...
> #include and use isatty() would be the correct way to do
> it. But is a dialog box that only appears when not being run from a
> terminal really such a good idea?
>
Does wine have a global handle to a file descriptor that can be used in
Hi,
I had a look at this patch and here are some comments.
The case of the filenames in the dsp and dsw files may not match the
case of the filenames on the filesystem. So you need to ajsut the names
before you put them in the makefile. I believe search_from() can be used
for that.
I see that
On Mon, Feb 23, 2009 at 6:38 AM, Paul Vriens wrote:
> Nicolas Le Cam wrote:
>> 2009/2/23 Paul Vriens :
>>> Nicolas Le Cam wrote:
2009/2/23 Francois Gouget :
> On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
>
>> This avoid a messagebox in regression tests on systems that don't have
>>>
Yup, reworked and resent.
-aric
James Mckenzie wrote:
> Alexandre Julliard wrote on Feb 23:
>> Aric Stewart writes:
>>
>>> +/* If i understand this correctly at most a process should generate
>>> + * only a handful of these... But in case I am wrong */
>>> +if (id_last == 65535)
>>
Alexandre Julliard wrote on Feb 23:
>
>Aric Stewart writes:
>
>> +/* If i understand this correctly at most a process should generate
>> + * only a handful of these... But in case I am wrong */
>> +if (id_last == 65535)
>> +{
>> +ERR("TfClientIds generated exceeds USHORT
sure, i'll do that and resend :)
thanks for your feedback.
2009/2/23 Paul Vriens
>
> Hi,
>
> Could you turn that skip() into a win_skip()? Usually it's a good idea to
> do a
> SetLastError(0xdeadbeef or something like that) before calling the
> function,
> especially because you are relying on t
2009/2/22 Austin English :
> diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c
> index b8ddba8..7360f66 100644
> --- a/dlls/ole32/compobj.c
> +++ b/dlls/ole32/compobj.c
> @@ -2007,7 +2007,7 @@ HRESULT WINAPI CoRegisterClassObject(
> * Use the address of the chain node as the cookie since
I still don't see what the harm is in having support for .so's. I mean even
if it brings partial compatibility to the dlls vs so's isn't it worth it?
That is more than we have right now in Wine. What was the last version to
have the built in support? I'd like to see if I can't update it, and port i
2009/2/23 Paul Vriens :
> Is .NET installed (any version)?
>
> --
> Cheers,
>
> Paul.
>
Can't remember. I will check and report back this evening.
Nicolas Le Cam
Nicolas Le Cam wrote:
> 2009/2/23 Paul Vriens :
>> Nicolas Le Cam wrote:
>>> 2009/2/23 Francois Gouget :
On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
> This avoid a messagebox in regression tests on systems that don't have
> GdiPlus.
This seems wrong because winetest.exe is alr
2009/2/23 Paul Vriens :
> Nicolas Le Cam wrote:
>> 2009/2/23 Francois Gouget :
>>> On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
>>>
This avoid a messagebox in regression tests on systems that don't have
GdiPlus.
>>>
>>> This seems wrong because winetest.exe is already supposed to check for
Aric Stewart writes:
> +/* If i understand this correctly at most a process should generate
> + * only a handful of these... But in case I am wrong */
> +if (id_last == 65535)
> +{
> +ERR("TfClientIds generated exceeds USHORT limit\n");
> +return 0x0;
> +}
> +
Nicolas Le Cam wrote:
> 2009/2/23 Francois Gouget :
>> On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
>>
>>> This avoid a messagebox in regression tests on systems that don't have
>>> GdiPlus.
>>
>> This seems wrong because winetest.exe is already supposed to check for
>> missing dlls. If I remember co
2009/2/23 Francois Gouget :
> On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
>
>> This avoid a messagebox in regression tests on systems that don't have
>> GdiPlus.
>
>
> This seems wrong because winetest.exe is already supposed to check for
> missing dlls. If I remember correctly this was done explici
On Sun, 22 Feb 2009, Nicolas Le Cam wrote:
> This avoid a messagebox in regression tests on systems that don't have
> GdiPlus.
This seems wrong because winetest.exe is already supposed to check for
missing dlls. If I remember correctly this was done explicitely so that
individual tests would
Mikołaj Zalewski a écrit :
I've written a dialog about a crash some time ago to add to winedbg
(http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html).
It's probably time to ask what is the status of this patch?
If this patch gets accepted (Alexandre seemed to like the previo
FWIW, I think the right way to fix this would be to use a handle table
like for shaders.
2009/2/22 Austin English :
> --
> -Austin
>
Ignore this patch please.
--
-Austin
On Mon, Feb 23, 2009 at 1:58 AM, Henri Verbeet wrote:
> 2009/2/23 Austin English :
>> +STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD
45 matches
Mail list logo
