Alexandre Julliard wrote:
Zephiris <[EMAIL PROTECTED]> writes:
Specifically, this appears to conflict with, say, when
InterlockedExchange is actually defined later in the source file. Even
if 'extern inline' is replaced by 'static inline', that's a
problem. For that particular case, for instanc
Hi,
I expect if any ofyou are interested you've already talked to Stefan
about the code drop from Parallels he is reviewing. I did a build of
the drop with Mingw and was able to build everything except ddraw.dll.
If anyone is interested in the binary and makefiles, I've forwarded
the information o
Hi all,
On Thursday 28 June 2007 18:35:57 Stefan Leichter wrote:
[...]
> > Does anybody feel up to fixing MingW so we will have a new winetest
> > executable soon? No new one since June 12 on
> > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ .
>
> Hello Paul,
>
> the patches are already i
Andrew Talbot wrote:
Hi,
In ole32/ifs.c:RemoveMemoryLocation(), should the parameter be a LPVOID *,
or should it be just a LPVOID (or LPCVOID, to be more precise)? I want to
constify it, but I'm uncertain if its current depth of indirection is
correct.
Yes, it should be LPVOID instead of LP
Is that possible in Windows or is this a hack to work around a missing
credentials cache?
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developerhttp://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
Andrew Talbot wrote:
-static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc);
+static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc);
static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc);
static ULONGWINAPI OLEFontImpl_AddRef(IFont* iface);
Even if the
Am Montag, 2. Juli 2007 17:46 schrieb Stefan Dösinger:
Do not apply this patch yet, it has some problems. Patch 5 should still apply
though
Hi,
In ole32/ifs.c:RemoveMemoryLocation(), should the parameter be a LPVOID *,
or should it be just a LPVOID (or LPCVOID, to be more precise)? I want to
constify it, but I'm uncertain if its current depth of indirection is
correct.
Thanks,
--
Andy.
On 7/2/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"James Hawkins" <[EMAIL PROTECTED]> writes:
> @@ -341,10 +341,15 @@ UINT WINAPI MsiSourceListGetInfoW( LPCWS
> }
> else if (strcmpW(INSTALLPROPERTY_PACKAGENAMEW, szProperty)==0)
> {
> +*pcchValue = *pcchValue * sizeo
Stefan Dösinger <[EMAIL PROTECTED]> writes:
> Updates the comment why the shader comment is needed - tests showed that the
> shaders have to have a minimal size on windows.
If the comment is only needed for size then you could use some padding
instead of the actual string. If the string is neede
James Hawkins wrote:
On 7/2/07, Paul Vriens <[EMAIL PROTECTED]> wrote:
Hi,
I've added some tests for OpenServiceA. Some of them crash on Wine,
but I've
opted to let them in (inside an if(0) though). The crashes happen
because we
assume that when a handle is not NULL it's correct.
The poli
On 7/2/07, Paul Vriens <[EMAIL PROTECTED]> wrote:
Hi,
I've added some tests for OpenServiceA. Some of them crash on Wine, but I've
opted to let them in (inside an if(0) though). The crashes happen because we
assume that when a handle is not NULL it's correct.
The policy for crashing tests is
Zephiris <[EMAIL PROTECTED]> writes:
> Specifically, this appears to conflict with, say, when
> InterlockedExchange is actually defined later in the source file. Even
> if 'extern inline' is replaced by 'static inline', that's a
> problem. For that particular case, for instance, I tried to work
>
I haven't seen this addressed and couldn't get an answer out of anyone
on IRC.
GCC defines 'extern inline' very differently from other compilers and C99.
inline isn't actually guaranteed to inline (obviously), but 'extern
inline' on GCC never defines a global function. References to the
functio
On 7/2/07, Tom Wickline <[EMAIL PROTECTED]> wrote:
On 7/1/07, Jeremy Newman <[EMAIL PROTECTED]> wrote:
> Alexander Nicolaysen Sørnes wrote:
> > Currently the Screenshots link on the WineHQ site points to a page with 9
> > screenshots and some links, while there are 3992 screenshots in the AppDB.
"Evan Stade" <[EMAIL PROTECTED]> writes:
> @@ -838,6 +838,65 @@ BOOL WINAPI PolyDraw(HDC hdc, const POIN
> }
> GDI_ReleaseObj( hdc );
>
> +if( PATH_IsPathOpen( dc->path ) ){
> +lastmove.x = orig_pos.x = dc->CursPosX;
> +lastmove.y = orig_pos.y = dc->CursPosY;
Acces
"Damjan Jovanovic" <[EMAIL PROTECTED]> writes:
> The text/plain MIME type is exactly the same as CF_TEXT - both have
> \r\n line endings so calling X11DRV_XDND_UnixToDos is wrong.
It would probably be better to make X11DRV_XDND_UnixToDos cope with
both formats, that should be easy.
--
Alexandre
"James Hawkins" <[EMAIL PROTECTED]> writes:
> @@ -341,10 +341,15 @@ UINT WINAPI MsiSourceListGetInfoW( LPCWS
> }
> else if (strcmpW(INSTALLPROPERTY_PACKAGENAMEW, szProperty)==0)
> {
> +*pcchValue = *pcchValue * sizeof(WCHAR);
> rc = RegQueryValueExW(sourcekey, INSTA
Strange, Calysto should have caught the use of x(malloc|realloc).
Either a bug in Calysto, or I misinterpreted the traces (I did a very
sloppy job analyzing them). Thx for the feedback, I'll try to allocate
more time for the analysis of the next run.
On 7/2/07, Alexandre Julliard <[EMAIL PROTECTE
On 7/1/07, Jeremy Newman <[EMAIL PROTECTED]> wrote:
Alexander Nicolaysen Sørnes wrote:
> Currently the Screenshots link on the WineHQ site points to a page with 9
> screenshots and some links, while there are 3992 screenshots in the AppDB.
> Would anyone object to me changing the link to point to
"Domagoj Babic" <[EMAIL PROTECTED]> writes:
> Possible NULL-ptr deref (vc796):
> @/work/benchmarks/SOURCES/wine-0.9.39/tools/makedep.c:196
> + Ptr p xmalloc-ed (makedep.c:187) dereferenced. Note that although
> xmalloc checks pointer (util.c:31), report(R_FATAL, "msg") does not
> exit, but only re
OK. Focus just on the server for starters. See you in a month...
On 7/2/07, Domagoj Babic <[EMAIL PROTECTED]> wrote:
Dan,
My front-end (LLVM) refused to cooperate - I can't compile server and dlls
into the LLVM intermediate form.
I will try again when I update to the new LLVM version in about
Dan,
My front-end (LLVM) refused to cooperate - I can't compile server and dlls
into the LLVM intermediate form.
I will try again when I update to the new LLVM version in about a month.
Regards,
--
Domagoj Babic
http://www.domagoj.info/
http://www.calysto.org/
On 7/1/0
23 matches
Mail list logo
