Juan Lang a écrit :
I just ran across an evil little bug in the
WINSPOOL_GetPrinter_2 function. It looks like this
type of bug could be hiding in other API functions
too. It causes a segmentation fault because of an
unaligned access on Solaris (sparc).
Yikes. That's a bad one. The trouble is
Eric Pouech wrote:
could you be more precise on the crash:
- where does it take place ?
OK, I've included the full backtrace below.
- are you running native msvcrt or builtin ?
Seems like the process has neither loaded.
- does IE6 installer use msvcrt at all ?
I don't think so. In any case, there'
> I just ran across an evil little bug in the
> WINSPOOL_GetPrinter_2 function. It looks like this
> type of bug could be hiding in other API functions
> too. It causes a segmentation fault because of an
> unaligned access on Solaris (sparc).
Yikes. That's a bad one. The trouble is MS loves
t
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I must be missing something, but I thought regular strings can not
> contain embedded nulls, so we can have a simple rule: don't store
> terminating nulls for simple strings, but store them for multi-strings.
>
> Aha -- you mean that if we follow t
On Fri, Oct 22, 2004 at 02:59:45PM -0700, Alexandre Julliard wrote:
>
> It's pretty much supported already. This doesn't really solve the
> problem of getting rid of the terminating null (except if you want to
> require always specifying the null explicitly, but that's not
> backwards compatible).
On Fri, 22 Oct 2004, Alexandre Julliard wrote:
[...]
They could, but that will require some changes to the .spec.c code,
right now the calling convention is based on the type specified in the
spec file, so pascal register functions have to be WINAPI.
No problem. When/if this happens, let me know (i
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes:
> Ok, so if I put back the IUnknowns, are you happy if the AddRefs in the d3dx
> calls AddRef on the WineD3D version?
I don't really understand why you'd need that.
> The problem I was trying to avoid was someone doing an addref for the
> wine
>No, you really should extend IUnknown, it's going to be massively
>confusing otherwise.
Ok, so if I put back the IUnknowns, are you happy if the AddRefs in the d3dx
calls AddRef on the WineD3D version?
>Please do proper reference counting, it doesn't cost anything, and
>someday we might need it.
I think the idea is that we should move the functionality of wineconf into winecfg so
winecfg should be able to autodetect and import the configurations from existing
windows installs. Wineconf hasn't been well maintained lately so maybe now is a good
time to encourage people to implement that
> I will create this list if there is enough interest
> in it.
I'd be interested in reading this, but really, I'm all
for simply seeing the Appdb updated. I understand you
guys are busy, but it's been about a month+, and I'm
still waiting on confirmation for my submitted app. ;)
Thanks!
Hiji
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes:
> Well I have an interface, it just doesnt extend IUnknown. Aside from that it
> is identical to any other com interface - I dont want to export all the
> functions provided. Is it 100% required to extend IUnknown (and would this
> mechanism not
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> What about supporting regular C escaping rules? It would be pretty
> consistent with the file format, and frankly I'd expect that to
> be supported (speaking as a Unix user). As for processing overhead,
> I'd be surprised if it shows on the radar.
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > - it doesn't add a break statement to the default
> > case (some compilers warn on this)
>
> I seriously doubt that, what compiler does this for
> you?
MSVC at certain warning levels IIRC. But my memory is
suspect.
> > -WCHAR szBuil
>> I have changed the design so only the Direct3D<8/9> ones
extend
>> IUnknown, and so there is no reference counting of the IWineD3D
>> objects.
>I don't think that's a good idea. If you are using COM interfaces then
>you need to use them the COM way, this means IWineD3D should derive
>from IUnkn
Juan Lang <[EMAIL PROTECTED]> writes:
> The following is a better patch, I think, in that
> - it doesn't add a break statement to the default case
> (some compilers warn on this)
I seriously doubt that, what compiler does this for you? It's much
better practice to always add break to all cases,
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes:
> I have changed the design so only the Direct3D<8/9> ones extend
> IUnknown, and so there is no reference counting of the IWineD3D
> objects.
I don't think that's a good idea. If you are using COM interfaces then
you need to use them the COM w
Ge van Geldorp <[EMAIL PROTECTED]> writes:
> Did this patch: http://www.winehq.org/hypermail/wine-patches/2004/09/0446.html
> fall through the cracks or is it not acceptable?
I think a lookup table would be more elegant (and faster...)
--
Alexandre Julliard
[EMAIL PROTECTED]
Mike McCormack a écrit :
Hi Eric,
The following patch causes the IE6 installer to crash. Thanks to Rob
for figuring out which patch caused the problem very quickly :)
Mike
Log message:
Eric Pouech <[EMAIL PROTECTED]>
- msvcrt: the file descriptors are now inherited between parent/child
Francois Gouget <[EMAIL PROTECTED]> writes:
> Yesterday's winapi_check path warns about 32 bit -register functions
> that are implemented by stdcall functions, but not about 16 bit
> -register functions implemented by stdcall functions. The reason is
> that for the latter the calling convention is
I just ran across an evil little bug in the WINSPOOL_GetPrinter_2 function.
It looks like this type of bug could be hiding in other API functions too.
It causes a segmentation fault because of an unaligned access on Solaris
(sparc).
This function packs a PRINTER_INFO_2 structure and all of its
var
Le ven 22/10/2004 à 14:31, Sascha Hanse a écrit :
> >
> >> I just tried to install the recent Wine-tarball (20041019) on my
> >> OpenBSD 3.6. First I had to remove kthread.c:275: the RFTHREAD flag.
> >> Then the'make depend && make' worked properly but the make install
> >> first fails with:
> >>
>
>
>> I just tried to install the recent Wine-tarball (20041019) on my
>> OpenBSD 3.6. First I had to remove kthread.c:275: the RFTHREAD flag.
>> Then the'make depend && make' worked properly but the make install
>> first fails with:
>>
>> /usr/bin/install -c serialui.dll.so
>> /usr/local/lib/wine
Well, i aplied the changes raphael suggested and although i dont
understand what they do they work :D
@David Welch
Yeah, already found that out, but thx anyway, i think i understand it a
bit better now :)
/Me moving on for validateshaders... lets see what that gets :D
Cheers
Nikolas
Hi Eric,
The following patch causes the IE6 installer to crash. Thanks to Rob
for figuring out which patch caused the problem very quickly :)
Mike
Log message:
Eric Pouech <[EMAIL PROTECTED]>
- msvcrt: the file descriptors are now inherited between parent/child
processes
Le ven 22/10/2004 à 11:26, Ivan Leo Puoti a écrit :
> I've written an app that calls a modal message box, if the uType parameter
> passed to MessageBox is MB_TASKMODAL or MB_SYSTEMMODAL a fixme is printed, but
> if it's MB_APPLMODA wine doesn't print a fixme.
> Is the attached fix correct (It works
I've written an app that calls a modal message box, if the uType parameter
passed to MessageBox is MB_TASKMODAL or MB_SYSTEMMODAL a fixme is printed, but
if it's MB_APPLMODA wine doesn't print a fixme.
Is the attached fix correct (It works for me)?
Ivan.
I've posted about this before, but never really tied things
up in a neat package, so:
Here's a document that describes how to
use Microsoft C++ Toolkit on Linux to build
Windows programs:
http://www.kegel.com/wine/cl-howto.html
I hope that helps a few people. I certainly find
it convenient when
I'm trying to buid wine-10192004. I've installed fontforge-10142004. The wine build
fails here:
fontforge -script ../fonts/genttf.ff wine_marlett.sfd
Copyright (c) 2000-2004 by George Williams.
Executable based on sources from 10:52 14-Oct-2004.
FontForge used to be named PfaEdit.
make[1]: *** [w
On Mon, Oct 18, 2004 at 05:29:29PM -0700, Alexandre Julliard wrote:
> Do you actually have an app that depends on this? I agree that in
> theory we should preserve the data exactly, but this means giving up
> on an easily editable registry format, so it should be done only if
> something really ne
29 matches
Mail list logo
