Dan Kegel wrote:
Presumably more semi-intelligent futzing with the stubs will
get us by for a lot of apps, but I wonder: how soon are we
going to have to really implement side-by-side assemblies?
A good first step would be to write a simple test case that shows what
they do...
Mike
http://bugs.winehq.org/show_bug.cgi?id=5276 and its ilk are becoming
increasingly annoying. I marked two more bugs as being blocked
by this just now.
Presumably more semi-intelligent futzing with the stubs will
get us by for a lot of apps, but I wonder: how soon are we
going to have to really im
Alexandre Julliard wrote:
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
Type: Cleanup
Why:
The const qualifier is unnecessarily restrictive.
I intend to allocate and free such data on the heap in a future patch
(in addition to the current const data).
I still don't see any reason for thi
Alexandre Julliard wrote:
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
Note: A new file was started for this purpose: wined3d_types.h. This
is _not_ the same as the one in the wine include folder - that one
should be for types which appear in the interface of wined3d, and must
therefore be expo
James Hawkins wrote:
@@ -1456,6 +1456,9 @@ static void msi_dialog_update_pathedit(
prop = msi_dialog_dup_property( dialog, control->property, indirect );
path = msi_dup_property( dialog->package, prop );
+if (!path)
+path = prop;
+
SetWindowTextW( control->hwnd, pa
Alex Villacís Lasso wrote:
Dreamweaver still can't find the DLL without my patch, even with the
"start" command, as demonstrated in the previous trace. Did you mean
that my patch *should* have placed the check in ShellExecute? Does
cmd.exe from Windows XP use CreateProcess or ShellExecute?
Nick,
I just completed a major upgrade of my system -- x11 6.9.0 (from 6.8.2),
NVidia driver 9625 (from 8774), glibc 2.3.6 (from 2.3.5), gcc 3.4.6
(from 3.3.6), among many other package upgrades.
I built Wine 0.9.22, and it runs fine (including sol.exe, notepad.exe,
and efaxviewer.exe).
My
On 10/4/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
> Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read "with wrong permissions" :-)
Yes, very wrong from a security standpoint :P
Le mercredi 04 octobre 2006 à 21:14 +0100, Martin Owens a écrit :
> It's a very very bad idea, I don't understand why linux doesn't
> protect normal users corrupting the disk at byte level that just seems
> really bad for security.
Every distro does AFAIK. However if people mess with their user's
On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read "with wrong permissions" :-)
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote:
>
> I agree that we shouldn't write to the MBR, but I definitely think that we
> should get some legal guidance before we proceed with writing anything to a
> file (in this case), because
If it isn't a silly question, which part of the m
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
So this is very strange, because under Windows XP i have definitely 8.
Ok, from what app do you want this log?
Mirek
App shouldn't matter, the +d3d_caps log should be the same. But I'll
need the entire extension detection part, ie from the part whe
It's a very very bad idea, I don't understand why linux doesn't
protect normal users corrupting the disk at byte level that just seems
really bad for security.
On 10/4/06, Aaron Slunt <[EMAIL PROTECTED]> wrote:
Jesse Allen wrote:
> Guys, Wine programs can write to the MBR already with correct
>
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct
permissions...
http://bugs.winehq.org/show_bug.cgi?id=4672
I hope nobody needs to explain why that's a very bad idea...
On 10/4/06, Karsten Anderson <[EMAIL PROTECTED]> wrote:
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller a
* On Tue, 3 Oct 2006, Detlef Riekenberg wrote:
> * On Di, 2006-10-03 at 20:40 +0300, Saulius Krasuckas wrote:
> > Well, thanks. I'll change that, but is it wrong just because it
> > slightly increases code complexity for no direct benefit? I just want
> > to know for future.
>
> For the normal
"Benjamin Arai" <[EMAIL PROTECTED]> writes:
> + if (fAbbrev)
> +if (iFirstDay == 0)
> + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday +
> LOCALE_IFIRSTDAYOFWEEK - 1) % 7);
> +else
> + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) %
> 7);
> + else
> +
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
> Type: Cleanup
>
> Why:
> The const qualifier is unnecessarily restrictive.
> I intend to allocate and free such data on the heap in a future patch
> (in addition to the current const data).
I still don't see any reason for this. Please fix your code to
Robert Shearman <[EMAIL PROTECTED]> writes:
> This is useful for generated files such as *_i.c and *_p.c (when widl
> can generate them).
> diff --git a/Make.rules.in b/Make.rules.in
> index 9e7ec07..68544dc 100644
> --- a/Make.rules.in
> +++ b/Make.rules.in
> @@ -8,6 +8,7 @@ # MODULE : name
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
> Note: A new file was started for this purpose: wined3d_types.h. This
> is _not_ the same as the one in the wine include folder - that one
> should be for types which appear in the interface of wined3d, and must
> therefore be exposed to other dlls. This
Hi,
Right now I'm busy moving all GLX code over to winex11.drv. The
WGL_ARB_render_texture code was one of the pieces of code which I moved over
already. I haven't written the old code but it appeared more or less complete
in case GLX_ATI_render_texture is around. A few parts are implemented wh
Maybe someone from FSF could provide legal guidance on this issue.
http://www.fsf.org/about/contact.html
Hi,
On current git I see that "wglBindTexImageARB" isn't found on my
system (when running nvidia demos).
Quick look into dlls/winex11.drv/opengl.c reveals:
if (glxRequireExtension("GLX_ATI_render_texture") ||
glxRequireExtension("GLX_ARB_render_texture"))
register_extension(&
Hi,
Karsten Anderson wrote:
> why not just implement the write to MBR? figure out how the copy
> protector does it and just implement it. as long as you know what
> you're doing and where the O/S stores its stuff you should be alright.
> put a few warnings on the instaeller and whatnot that this
On Wednesday 04 October 2006 09:25, Karsten Anderson wrote:
> why not just implement the write to MBR?
The user running Wine more than likely won't have such write access to the
disk. Only root would be able to do that, and running Wine as root is far
from encouraged. Plus, fooling around with t
Quoting EA Durbin <[EMAIL PROTECTED]>:
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
They license the code for the copy protection detection from the likes
of macrovision.
--
Darragh
"
On Tue, 3 Oct 2006, Marcus Meissner wrote:
> Hi,
>
> Added dsound.dll and dsound.vxd and ddhelp.exe
> to the fake dlls.
>
> These are checked for by "Curse of Monkey Island"
> DirectX check.
[...]
> +11,,ddhelp.exe
> 11,,ddraw.dll
> +11,,dsound.dll
> +11,,dsound.vxd
[...]
I think we should not
On 3 oct. 06, at 08:09, Ken Thomases wrote:
The other really big chunk of VM (after Wine) is labeled as "STACK
GUARD". I believe the intent of STACK GUARD space is to generate
exceptions (EXC_BAD_ACCESS / SIGSEGV) if a stack grows beyond its
pre-allocated bounds. It's another 1.5GB! Thi
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller and whatnot that this might be
risky, and then let the use
> what keeps some nosy haxx0r from looking in the MBR (or some blocks
> later) if he wants to find out about the copy protection? if they store
> data like this unprotected (e.g. crypting them) then this is just
> security-by-obscurity (which is no security at all).
Copy protection IS security by o
On Wed, Oct 04, 2006 at 04:09:51PM +0100, Martin Owens wrote:
> Anyone techinicaly adept could find the MBR, it's the 1st sector on
> the disk, this isn't about boot records but the MBR which is in a
> known place. I recon you could use linux tools on your windows hard
> drive to retrieve it easy.
On 10/4/06, Jonathan Ernst <[EMAIL PROTECTED]> wrote:
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :[...]>>> I'm by no means an expert on copyright law or copy protection, but I> think that using any method other than writing directly to the MBR
> with those copy protection measures wo
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote:
> I should add that I just thought about this and realized that we
> _could_ always just encrypt the contents of the file as it is written
> and read, so that we can actually get somewhere, and not be exposing
> sensitive data at the same
So this is very strange, because under Windows XP i have definitely 8.
Ok, from what app do you want this log?
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some
Technically yes, but the difference is that VMware actually writes
_everything_ into that one file vs wine proposing to write just what is
written to the boot sector into a file..
The reason it is different, is because it is much more difficult (if not
impossible) to tell what is boot sector and
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :
[...]
>
>
> I'm by no means an expert on copyright law or copy protection, but I
> think that using any method other than writing directly to the MBR
> with those copy protection measures would be illegal because writing
> to a f
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some apps have big regression. I realy dont
know why, i am not expert in wine or directx, but now it is working.
The old drivers only had 4 GL_MAX_T
On Wed, 2006-10-04 at 12:23 +0100, Robert Shearman wrote:
> Pavel Roskin wrote:
> > GLUT32FILES = glut32
> > OPENGLFILES = opengl32 wined3d
> > XFILES = winex11.drv
> > -EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
> > +WIN32FILES = oleaut32
> > +EXTRADIRS = @GLU32FILES@ @GLUT32
On 10/3/06, Martin Owens <[EMAIL PROTECTED]> wrote:
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:> > I'm by no means an expert on copyright law or copy protection, but I think> > that using any method other than writing directly to the MBR with those copy
> > protection measures
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:
> I'm by no means an expert on copyright law or copy protection, but I think> that using any method other than writing directly to the MBR with those copy> protection measures would be illegal because writing to a file (registry,
> w
On Wed, Oct 04, 2006 at 11:26:49AM +0900, Byeong-Sik Jeon wrote:
> Changelog:
> Cleanup the updata_font_info().
>
> +static void add_nls_font_to_registry(
> +HKEY hkey,
> +const char *value_name,
> +const char *value_data,
> +BOOL is_force)
> +{
> +
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some apps have big regression. I realy dont
know why, i am not expert in wine or directx, but now it is working.
trace:d3d_caps:IWineD3DImpl_FillGLCaps GL_Extensions reported:
trace:d3d_caps:IW
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
--- directx.c.old 2006-10-03 22:36:25.0 +0200
+++ directx.c 2006-10-04 14:24:18.0 +0200
@@ -557,6 +558,7 @@
gl_info->supported[ARB_MULTISAMPLE] = TRUE;
} else if (strcmp(ThisExtn, "GL_ARB_multitext
OK, and now what about this patch? With this patch evrything is working
correctly if i am using nVidia BETA 9625 drivers (HL2 EO, GTA SA, 3DMark
2003), corectly means same like with old driver and wine 0.9.22.
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
And wha
Pavel Roskin wrote:
GLUT32FILES = glut32
OPENGLFILES = opengl32 wined3d
XFILES = winex11.drv
-EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
+WIN32FILES = oleaut32
+EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
Why?
--
Rob Shearman
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
There might be. GF4 might be a card we want to check. I do think it's
a bit dodgy though... you'll probably want
Sorry, there should be only greater then, not equal. So this i the right
version :)
Mirek
Mirek napsal(a):
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mire
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
Unfortunately there are many issues with latest nVidia drivers and
Windows apps i
On 04/10/06, Mirek <[EMAIL PROTECTED]> wrote:
Unfortunately there are many issues with latest nVidia drivers and
Windows apps in wine. In Half-Life 2 EO (characters brokes the game),
3DMark 2003 (first test with planes is very strange), GTA SA (almost
everywhere in game), but other apps such as F
50 matches
Mail list logo
