n LIST_ENTRY( ptr, struct process_dll, entry );
> 2. change debugger.c:160 to
> if (exe_module && exe_module->file &&
> 3. inspect list_head()?
> 4. ignore it?
Ignore it, the process will always have a module at that point.
--
Alexandre Julliard
julli...@winehq.org
> to bleed. It all depends on how much code we're talking
> about, and how many people we expect to be able to
> write DOS testcases.
If there are really so many DOS test cases that it becomes a problem,
then we can consider adding more infrastructure for it. I don't see that
h
x27;s a bit wasteful to import shell32 just to copy an icon.
--
Alexandre Julliard
julli...@winehq.org
abOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top);
That doesn't make sense. What are you trying to compute here?
--
Alexandre Julliard
julli...@winehq.org
Vitaliy Margolen writes:
> Alexandre Julliard wrote:
>> Vitaliy writes:
>>
>>> + /* Get non-client size */
>>> + if (!psInfo->isModeless)
>>> + {
>>> +RECT rc1;
>>> +
>>> +GetWindowRect(hwndDlg, &rc);
>
purpose of submitting the patch is to ask people if
> i'm along the right lines. anything seriously objectionable, etc.
> etc.
You can't do that stuff on the client side. You either have to do all
pipe I/O in the server, or add named pipe support in the kernel. The
latter is ha
he wineserver being
the equivalent of kernel space. You can't do this stuff in user space
(hint: concurrency).
--
Alexandre Julliard
julli...@winehq.org
ld probably use QueryPerformanceCounter as it already uses the
correct frequency.
--
Alexandre Julliard
julli...@winehq.org
sterPropertySchema(PCWSTR path)
> +{
> +FIXME("stub\n");
> +
> +return E_NOTIMPL;
> +}
I don't think you need a new file for this. If someday there's a lot of
code in there it can be split off to a separate file then.
--
Alexandre Julliard
julli...@winehq.org
Francois Gouget writes:
> So my question is: should this function be removed? Or should I simply
> send a patch calling it from x11drv_main.c:process_detach(), enclosed
> with the appropriate SONAME_LIBXRANDR?
You can remove it, it doesn't do anything useful.
--
Alexandre
x = x * ModeInfo->CharWidth;
> + y = y * ModeInfo->CharHeight;
> + /* translate & copy char into display buffer */
> + for (ih = 0; ih < ModeInfo->CharHeight; ih = ih+1)
Please cut down on the number of comments, there's no need to explain
what each line of code is doing, that's adding more noise than
information.
--
Alexandre Julliard
julli...@winehq.org
W(long ptr long)
> For 32bit yes but if it will work for 64bit I have no clue. I don't
> remember to have seen any Win64 fix patch that touched the spec file too
> so I would have to defer the answer to this question to Alexandre.
It's fine for 64-bit too.
--
Alexandre Julliard
julli...@winehq.org
r (or better ask him to submit the patch himself). And please fix
your mail setup, all your patches are wrapped.
--
Alexandre Julliard
julli...@winehq.org
Peter Urbanec writes:
> This patch will save and restore the colours when adding a masked image
> to ImageList.
What's the point of restoring the colors in a DC that gets deleted right
away?
--
Alexandre Julliard
julli...@winehq.org
_ACP, 0, CredentialW->TargetName,
> -1, NULL, 0, NULL, NULL);
> + WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName,
> -1, CredentialA->TargetName, string_len, NULL, NULL);
It doesn't make sense to use the output size as buffer size. You need to
pass the real size of the buffer.
--
Alexandre Julliard
julli...@winehq.org
R_EXCEPTIONS */\n");
>> print_proxy( "\n");
>> }
>
> I think a better solution to this would be to use proxy_filter as the
> expression in the RpcExcept statements.
>
> Alexandre, what do you think?
We could do that, though it wouldn't help wi
irectory() function too? In which case I suspect that
> LookupIconIdFromDirectory16() would be its implementation...
>
> Unfortunately I have no information about what 16bit dlls are supposed
> to export...
It's apparently not exported from 16-bit user.exe, so it can b
;t want to have any sort of warning or message box
getting in the way.
--
Alexandre Julliard
julli...@winehq.org
Buffer += sizeof(ULONG_PTR);
> +*(ULONG *)Buffer = (ULONG)(ULONG_PTR)psa->pvData;
> +Buffer += sizeof(ULONG);
Wouldn't this break if the pointer happens to be 4Gb-aligned?
--
Alexandre Julliard
julli...@winehq.org
f.dll -T ../../.. -p
d3dxof_test.exe.so d3dxof.c && touch d3dxof.ok
d3dxof.c:113: Test failed: IDirectXFileEnumObject_GetNextDataObject: 88760362
wine: Unhandled page fault on read access to 0x3839c385 at address 0x6016fd1e
(thread 0009), starting debugger...
--
Alexandre Julliard
julli...@winehq.org
instead of simply throwing
out a warning and proceeding.
--
Alexandre Julliard
julli...@winehq.org
Rob Shearman writes:
> 2009/2/9 Alexandre Julliard :
>> Rob Shearman writes:
>>
>>> @@ -874,8 +874,8 @@ unsigned char * WINAPI LPSAFEARRAY_UserMarshal(ULONG
>>> *pFlags, unsigned char *Buf
>>>
>>> *(ULONG *)Buffer
are using, or better file a bug with that
info.
--
Alexandre Julliard
julli...@winehq.org
warnings, so it doesn't add any
user-friendliness at all, just the opposite.
--
Alexandre Julliard
julli...@winehq.org
Vitaliy Margolen writes:
> Alexandre Julliard wrote:
>> Again, please demonstrate the exact sequence that leads to an actual
>> problem, not just vague hearsay of people reporting problems that may or
>> may not have anything to do with this.
>>
> Will th
Marcus Meissner writes:
> Hi,
>
> This fixes CID 883, 882, 881, 880, 879, 878, 877,
> which are all basically missing strarray_free(arr)s.
winegcc is a short-lived program, there's no reason to care about memory
leaks.
--
Alexandre Julliard
julli...@winehq.org
Michael Stefaniuc writes:
> Alexandre Julliard wrote:
>> Marcus Meissner writes:
>>
>>> This fixes CID 883, 882, 881, 880, 879, 878, 877,
>>> which are all basically missing strarray_free(arr)s.
>>
>> winegcc is a short-lived program, there'
AMETER)
make: *** [info.ok] Error 1
--
Alexandre Julliard
julli...@winehq.org
Gecko install workaround and have the test force the install
in all cases, it's not useful to run the tests without Gecko anyway.
--
Alexandre Julliard
julli...@winehq.org
ystem object for handle %p not found.\n", handle);
> +return;
> +}
That shouldn't happen, it's an internal function and the caller is
supposed to pass a valid handle.
--
Alexandre Julliard
julli...@winehq.org
ted
> prefix.
No, a warning that will get drowned in a bunch of other fixmes is not
useful.
What we should really do is properly support installing as root,
i.e. having stuff go into a global prefix and being available to all
users.
--
Alexandre Julliard
julli...@winehq.org
Austin English writes:
> On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard
> wrote:
>> No, a warning that will get drowned in a bunch of other fixmes is not
>> useful.
>
> We could make it a popup warning, again, only on first run.
No, warning message boxes are jus
e $HOME would not be
> owned by you, but I've been assuming we want Wine to function in those
> cases (otherwise, we'd have added this test when we added the original
> ownership test, right?).
No we don't want Wine to function in those cases, and it is part of the
ownership test already.
--
Alexandre Julliard
julli...@winehq.org
ISPLAY_TYPE, 0, NULL,
> + name, len);
> +TRACE_(chain)("issued to %s\n", debugstr_w(name));
> +CryptMemFree(name);
> +}
You probably don't want to do all this work unless tracing is enabled.
--
Alexandre Julliard
julli...@winehq.org
d is that the 64-bit loader should be able to forward
automatically to the 32-bit one when encountering a 32-bit app.
--
Alexandre Julliard
julli...@winehq.org
ts, of which a
huge majority always succeeds. Having a single failure among 10,000
tests means that the test failed, and it's something bad that should be
taken care of. Showing that as a 99.99% success would be very misleading.
--
Alexandre Julliard
julli...@winehq.org
t
> enough code to detect i386 vs amd64 and then execs either wine32 or wine64?
sure, that would be possible. I don't know yet how it will be done, but
that's a minor implementation detail.
--
Alexandre Julliard
julli...@winehq.org
zeof(OFSTRUCT) ||
> - broken(test.cBytes == 40), /* win95 */
> + broken(test.cBytes == 34) /* winME */ ||
> + broken(test.cBytes == 40) /* win95 */ ||
> + broken(test.cBytes == 48), /* some win95 */
My guess is that this depends on the length of the filename, not on
rgs, &ret );
The correct fix for these things is to move them to a 16-bit file that
doesn't get compiled at all for Win64. It doesn't make sense to call
WOWCallback16 in 64-bit mode.
--
Alexandre Julliard
julli...@winehq.org
Alistair Leslie-Hughes writes:
> Hi,
>
> Changelog:
> urlmon: Corrected tests
Please write a better description. "Corrected tests" applies to every
test commit.
--
Alexandre Julliard
julli...@winehq.org
Marcus Meissner writes:
> CID 119, 188, resubmit with working patch from earlier round.
>
> I guess we could also just let it crash if this happens, but
> I am not feeling comfortable.
These are internal functions, it doesn't make sense to call them with
NULL.
--
Alexand
the
meantime we can certainly block these reports and concentrate on the
more meaningful failures.
--
Alexandre Julliard
julli...@winehq.org
y drop the typedef as well, I
> don't think it adds anything useful.
SRGB_FALSE and SRGB_TRUE aren't very good names either for an enum with
4 values...
--
Alexandre Julliard
julli...@winehq.org
; rewrite if I rememeber correctly. I don't remember if it was due to
> maintenance issues or because of some technical issue.
It was removed because it's not worth the trouble. There are essentially
no Unix libraries that are guaranteed to be binary compatible with the
Windows versi
#x27;t it a bug that we don't let it have it?
There's no guarantee that using the private version would help. In some
cases it does, in other cases it makes things worse. So defaulting to
builtin is preferable, this way at least when it doesn't work we have a
chance of fi
MAKELCID(LANG_ENGLISH, SUBLANG_DEFAULT),
> +NORM_IGNORECASE, ptr, 6, szDomain, 6) == 2)
You need to check that the next char is a valid terminator
(probably '=', not sure if other values are possible). Also using
strncmpiW would make the code more readable.
--
Alexandre Julliard
julli...@winehq.org
verwhelming popularity of the app,
> it's probably worth it for us to hold our noses and do that. No?
No. Find a better way.
For instance, investigate the possibility of checking version
resources.
--
Alexandre Julliard
julli...@winehq.org
Dan Kegel writes:
> On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard
> wrote:
>> No. Find a better way.
>>
>> For instance, investigate the possibility of checking version
>> resources.
>
> Which version resources are you thinking of?
The version of the
tm.wDayOfWeek = i;
> +break;
> +}
> +}
> +ptr += 5;
> +tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10);
> +ptr = ptr2+1;
You should handle the various possible parsing errors, not just assume
that you have a well-formatted string.
--
Alexandre Julliard
julli...@winehq.org
e, Version=1.0.1.2, Culture=neutral,
PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=16a3fcd171e93a8d"
make[2]: *** [asmenum.ok] Error 3
--
Alexandre Julliard
julli...@winehq.org
;);
> +return 0x0;
> +}
> +id_last++;
> +id->id = MAKELONG(id_last, magic);
> +id->data = data;
> +list_add_head(&clientids,&id->entry);
Using an array index would be cleaner than having to search through the
list everytime you use an id.
--
Alexandre Julliard
julli...@winehq.org
debugger isn't hard to do in faultrep, plus you most likely want to
do it differently from what kernel32 does.
--
Alexandre Julliard
julli...@winehq.org
"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
"Vincent Povirk" writes:
> +ILFree(This->pidl);
> +This->pidl = ILClone(pidl);
> +if (This->pidl)
> +return S_OK;
> +else
> +return E_OUTOFMEMORY;
You should check for success before you free the previous pidl.
--
Alexandre Julliard
julli...@winehq.org
Rein Klazes writes:
> Also in Get/SetMenuInfo set last error if called with invalid parameters.
Please use the appropriate function pointers in the test so that it
still runs on older platforms.
--
Alexandre Julliard
julli...@winehq.org
re broken too.
Saying 1.0.1 is too broken to be supported is silly, it was working just
fine 6 months ago, and it is still working fine for many apps.
--
Alexandre Julliard
julli...@winehq.org
if 1.0.1 doesn't work, then trying the tip is a good idea, but
that doesn't mean that everybody should do that. There are regressions
in the tip, and there's no reason to push users to upgrade unless they
clearly have trouble with 1.0.1.
--
Alexandre Julliard
julli...@winehq.org
if we decide that they are
useless after 6 months (and no, the answer is not to make more frequent
stable releases; even if we did one every 3 months we'd still have to
support the old ones).
--
Alexandre Julliard
julli...@winehq.org
en run the test, it
doesn't make any difference whether it's imported statically or
dynamically.
--
Alexandre Julliard
julli...@winehq.org
MEMORY, uRetLen *
> sizeof(WCHAR));
That's just hiding the bug. The string shouldn't be converted at all if
we failed to retrieve it.
--
Alexandre Julliard
julli...@winehq.org
t; + idx = ntext;
> + while (*idx) {
> + if(!isprintW(*idx))
> + *idx = space;
> + idx++;
This would need some test cases with various invalid chars to confirm
that isprintW is the right check to use.
--
Alexandre Julliard
julli...@winehq.org
Paul Vriens writes:
> But why suddenly? I hate it when something like that happens.
For the winehq.org builds that's most likely because the Debian updates
brought in a new MinGW.
--
Alexandre Julliard
julli...@winehq.org
Austin English writes:
> AJ's recent work in this area caused a warning on non-Linux OS's,
> where this function is not used.
That's on purpose, the function is supposed to be used on other
platforms too.
--
Alexandre Julliard
julli...@winehq.org
hat you are
trying to avoid obviously apply just as well to your proxy process.
--
Alexandre Julliard
julli...@winehq.org
to encourage
someone else to do it (hint hint).
--
Alexandre Julliard
julli...@winehq.org
; can always be done later, yes?
No, in many cases efficiency needs to be taken into account in the
design phase. You can't just add it later.
--
Alexandre Julliard
julli...@winehq.org
Luke Kenneth Casson Leighton writes:
> On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard
> wrote:
>> Luke Kenneth Casson Leighton writes:
>>
>>> so - what do people think? would you agree that a user-space pipe
>>> "proxy" is an effective soluti
ich
> existing code in wineserver utilises the existing mechanisms to which
> you refer?
Look at the ioctl support.
--
Alexandre Julliard
julli...@winehq.org
0037bc28) at
../../../wine64/tools/widl/widl.c:632
(gdb) p type
$1 = (type_t *) 0x10000
(gdb) p *decl_spec
$2 = {type = 0x1, attrs = 0x0, stgclass = STG_NONE}
(gdb)
--
Alexandre Julliard
julli...@winehq.org
NT_MAX);
--
Alexandre Julliard
julli...@winehq.org
Jeremy White writes:
> +rc = GetLocaleInfoA(LOCALE_USER_DEFAULT, LOCALE_IPAPERSIZE, paper,
> sizeof(paper));
> +if (rc > 0)
> +switch (atoi(paper))
You should use LOCALE_RETURN_NUMBER.
--
Alexandre Julliard
julli...@winehq.org
> +
> +What works:
Please put that sort of information as comments in the relevant source
files. It's never updated if it's a separate README.
--
Alexandre Julliard
julli...@winehq.org
: Only 1 simultaneous render target supported,
skipping MRT test
make[2]: *** [visual.ok] Error 51
--
Alexandre Julliard
julli...@winehq.org
t; return DMT_PE;
> }
>
> +#if defined(_IMAGEHLP_SOURCE_) || !defined(_IMAGEHLP64)
It doesn't make sense to test for these defines in the source. You
probably want #ifndef _WIN64.
--
Alexandre Julliard
julli...@winehq.org
#x27;t have an entry point, it cannot be executed
>
> Did I miss some memo?
Running those directly is not supported. Not that it would be of any use
anyway, but if you really want to, you can start it with 'wine winevdm
winhelp.exe'.
--
Alexandre Julliard
julli...@winehq.org
in16 tests with this infrastructure
> (lightly extended, if needed)?
No, it's not possible. We don't have any way of building 16-bit code
with gcc. All 16-bit stuff in Wine is actually 32-bit code, with
functions explicitly suffixed with '16' etc. You can't possibly build
real 16-bit apps this way.
--
Alexandre Julliard
julli...@winehq.org
so
fixing them only involves making them less strict. That's not something
users care about.
You could certainly make the argument that failing tests should block
the release, but that doesn't imply that succeeding tests justify a
release all by themselves.
--
Alexandre Julliard
julli...@winehq.org
f
other issues that need some more time to mature, like the OpenGL memory
thing. It seems we could reasonably start the release process 3 months
from now. Of course that would put code freeze right in the middle of
the Summer of Code...
--
Alexandre Julliard
julli...@winehq.org
to radiobuttons too.
>
> Changelog:
> - Button should lose highlighting on focus loss
It doesn't seem right to do this in two separate steps and repaint the
button twice. This would need a test case.
--
Alexandre Julliard
julli...@winehq.org
);
It seems to me you are just hiding the problem. If we have a pidl we
shouldn't access the path directly.
--
Alexandre Julliard
julli...@winehq.org
es not initialize the bitmap
make: *** [bitmap.ok] Error 10
--
Alexandre Julliard
julli...@winehq.org
t it can't be made a requirement for release unless we want it to take
another 3 years... For release I think it's enough to have tests pass on
Wine and on at least one Windows box.
--
Alexandre Julliard
julli...@winehq.org
Paul Vriens writes:
> But that's also the same logic we are using in winetest (function
> running_on_visible_desktop). So that's broken too?
Yes, that's broken.
--
Alexandre Julliard
julli...@winehq.org
Folks,
There won't be any commits next week, as I'll be skiing...
Release 1.1.18 should be on schedule two weeks from today, unless you
send so many patches next week that I can't catch up (hint hint).
See you all in a week!
--
Alexandre Julliard
julli...@winehq.org
names to QueryDosDevice
> 8/10 kernel32: Implement support in QueryDosDevice for unique volume names
> 9/10 server: Fix error when opening directory r/o with O_DIRECT
> 10/10 kernel32/tests: More tests of CreateFile on unique volume id
All that stuff should be done in mountmgr, not in
t;next = NULL;
> -next_section = &first_section->next;
> +next_section = &first_section;
This cannot be right. What happens to the original first_section then?
--
Alexandre Julliard
julli...@winehq.org
h? Thanks,
Serial data and ioctls are forwarded straight to the kernel, so you'd
need to put the loopback driver in the kernel, not in Wine.
--
Alexandre Julliard
julli...@winehq.org
> for details.
The specific implementation may not be a good idea, but the principle is
correct, we should get that info from fontconfig. Users shouldn't have
to configure anti-aliasing in two different places.
--
Alexandre Julliard
julli...@winehq.org
lue)
GDI_ERROR is clearly not a valid buffer size, and must be checked
for. Please write test cases like Dmitry suggested.
--
Alexandre Julliard
julli...@winehq.org
ntSink;
Please pick better names for your variables. Hungarian notation is not a
good idea in general, but incorrect Hungarian prefixes are even worse,
these are not pointers.
--
Alexandre Julliard
julli...@winehq.org
depage 950. Try us ing a Unicode string
> instead
You have an old libwine somewhere in your library path.
--
Alexandre Julliard
julli...@winehq.org
metrics for it */
> else if(GetGlyphOutlineW(hdc, str[idx], GGO_GLYPH_INDEX | GGO_METRICS,
> &gm, 0, NULL, &identity) == GDI_ERROR)
> return FALSE;
>
> This is guaranteed to work as by MSN description.
No, you don't handle GDI_ERROR correctly.
--
Alexandre Julliard
julli...@winehq.org
s that appear
before the first section header (if any). With your patch it will simply
be dropped (and leaked). A better patch would be to only create the
first section as needed, when we encounter either a section header or a
stand-alone key.
--
Alexandre Julliard
julli...@winehq.org
l16(long ptr long)
You can't do that, 16-bit code can be disabled on i386 too.
--
Alexandre Julliard
julli...@winehq.org
; LPDWORD cBytes);
> static DWORD ParseAclStringFlags(LPCWSTR* StringAcl);
>
> +typedef VOID (*FN_PROGRESS) ( LPWSTR pObjectName, DWORD Status,
> + OUT PPROG_INVOKE_SETTING pInvokeSetting, PVOID Args, BOOL SecuritySet);
> +
Please put this in the appropriate header.
--
Alexandre Julliard
julli...@winehq.org
>if (height < 0) height = -height;
> @@ -3977,7 +3979,7 @@ INT CDECL X11DRV_SetDIBits( X11DRV_PDEVICE *physDev,
> HBITMAP hbitmap, UINT start
> default: break;
>}
>
> - descr.bits = bits;
> + descr.bits = (BYTE *)bits + widthBytes * (tmpheig
r)
> +
> +#define _S6_un u
> +#define _S6_u8 Byte
> +#ifndef USE_WS_PREFIX
> +#define s6_addr_S6_un._S6_u8
> +#else
> +#define WS_s6_addr _S6_un._S6_u8
> +#endif
> +
> +#define s6_bytes u.Byte
> +#define s6_words u.Word
This doesn't seem
/10 fixed this.
I don't see why you'd need O_DIRECT.
> 3. Linux requires the I/O buffer for special files (/dev/..) to be
> aligned on 512 byte boundary to get the correct data. #4/10 corrects
> that problem for both reading and writing.
That's really ugly.
--
Alexandre Julliard
julli...@winehq.org
s spot on and that it's ok to apply
>> it. Probably Alexandre will know.
>
> So, what do you think about this patch Alexandre?
It's not correct, we need to reserve high memory on FreeBSD too, we
don't want dlls to end up there.
--
Alexandre Julliard
julli...@winehq.org
Henri Verbeet writes:
> diff --git a/dlls/bcrypt/bcrypt.spec b/dlls/bcrypt/bcrypt.spec
> new file mode 100644
> index 000..e69de29
Please add stubs for the exported functions.
--
Alexandre Julliard
julli...@winehq.org
1 - 100 of 5806 matches
Mail list logo
