Jerome Leclanche wrote:
> Austin English <austinenglish at gmail.com> wrote:
>> Anyone opposed to removing that keyword?
>
> +1 on removing it.
> It would be nice to have a bugzilla filter to replace it, too.
>
> Are we keeping "tasklist" and "tasklet" keywords as well? theres
> barely a dozen very old bugs for both of them.
I think it'd be fine to remove noappdbentry, tasklist, and tasklet.
If there are no objections by next weekend, let's go ahead and do it.
- Dan
On 12/30/2009 03:21 AM, Julius Schwartzenberg wrote:
> This patch depends on Detlef Riekenberg's patch from June 2008 and
> expects it to have been applied:
> http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html
>
> It was not committed due to bug 14085:
> http://bugs.winehq.org/show_bug.cgi?id=14085
Can't you just submit that initial test framework with the 3 imports (if
all 3 are indeed needed)? The bug will of course not be closed but at
least some of your work could be committed.
--
Cheers,
Paul.
The valgrind bot seems to have locked up soon after
I left for vacation, but it's back up. Today's results:
http://kegel.com/wine/valgrind/logs/2009-12-31-09.07/
Stats:
1 Invalid free/ delete / delete[]
1 Use of uninitialised value of size 4
2 Invalid write of size 4
2 Source and destination overlap in memcpy
3 Syscall param writev
6 Invalid read of size 2
8 Invalid write of size 1
12 Invalid read of size 4
49 Conditional jump or move depends on uninitialised value
598 XXX bytes in XXX blocks are definitely lost
total: 682
The total on Dec 18th was 807. Nice progress!
I believe the following patch
commit 8268ed978389662c7b43212e008037cae3ce900e
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Dec 28 22:19:31 2009 +0100
kernel32: Do not include 16-bit headers in 32-bit files.
is causing
gmake[2]: Entering directory `/usr/test/Wine/dlls/kernel32' /files/pfeifer/gcc/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -I/usr/local/include -g -O2 -o module.o module.c
In file included from module.c:36:0:
../../include/winbase.h:1560:84: error: expected declaration specifiers or '...' before 'va_list'
../../include/winbase.h:1561:85: error: expected declaration specifiers or '...' before 'va_list'
In file included from module.c:37:0:
../../include/winternl.h:2223:81: error: expected declaration specifiers or '...' before 'va_list'
../../include/winternl.h:2389:58: error: expected declaration specifiers or '...' before 'va_list'
../../include/winternl.h:2390:75: error: expected declaration specifiers or '...' before 'va_list'
over here on my FreeBSD 7.2 tester.
Gerald
I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows executables you can now also submit patch files to the bot. The bot will apply the patch files to a clean git tree, cross-compile the test and run the test on Windows VMs. You'll also be able to download the cross-compiled test executable to test it on different Windows machines.
Ge.
2009/12/31 Rico Schüller <kgbricola(a)web.de>:
> struct d3d10_effect_shader_variable *s;
...
> + v->data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct d3d10_effect_shader_variable));
...
> + s = v->data;
I think this would be nicer:
s = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*s));
...
v->data = s;
That's mostly my fault for writing it like that in the first place,
but we might as well fix that.
> + default:
> + ERR("This should not happen!\n");
> + break;
You'll probably want to return E_FAIL here.
> + struct d3d10_effect_variable *v = &e->anonymous_shaders[e->anonymous_shader_current];
> + struct d3d10_effect_type *t = &e->anonymous_shader_type[e->anonymous_shader_current];
...
> + hr = parse_fx10_anonymous_shader(o->pass->technique->effect, o->type);
...
> + o->data = &o->pass->technique->effect->anonymous_shaders[o->pass->technique->effect->anonymous_shader_current-1];
If you create a structure for anonymous shaders, you can store that in
a single array. You can then pass a pointer to that structure to
parse_fx10_anonymous_shader(), and handle "anonymous_shader_current"
in parse_fx10_object(). E.g.:
struct d3d10_effect *effect = o->pass->technique->effect;
struct d3d10_effect_anonymous_shader *shader =
&effect->anonymous_shaders[effect->anonymous_shader_current];
hr = parse_fx10_anonymous_shader(effect, o->type, shader);
if (FAILED(hr)) return hr;
++effect->anonymous_shader_current;
o->data = shader;
Note that you should also validate that "anonymous_shader_current" <
"anonymous_shader_count". The count is supposed to be correct, but the
.fx might lie about it, possibly on purpose.
2009/12/31 Rico Schüller <kgbricola(a)web.de>:
> +static struct d3d10_effect_variable null_local_buffer = {0};
> +static struct d3d10_effect_variable null_variable = {0};
> +static struct d3d10_effect_variable null_scalar_variable = {0};
> +static struct d3d10_effect_variable null_vector_variable = {0};
> +static struct d3d10_effect_variable null_matrix_variable = {0};
> +static struct d3d10_effect_variable null_string_variable = {0};
> +static struct d3d10_effect_variable null_shader_resource_variable = {0};
> +static struct d3d10_effect_variable null_render_target_view_variable = {0};
> +static struct d3d10_effect_variable null_depth_stencil_view_variable = {0};
> +static struct d3d10_effect_variable null_shader_variable = {0};
> +static struct d3d10_effect_variable null_blend_variable = {0};
> +static struct d3d10_effect_variable null_depth_stencil_variable = {0};
> +static struct d3d10_effect_variable null_rasterizer_variable = {0};
> +static struct d3d10_effect_variable null_sampler_variable = {0};
This doesn't hurt (much), but since a lot of people seem to be unaware
of this I think it's worth mentioning again. Global variables as well
as static (local) variables are initialized to 0 / NULL by default.
The way this works in the language spec is that objects with static
storage duration (i.e. the entire lifetime of the program/module) are
initialized to 0 / NULL unless explicitly initialized. In practice
that means global and static variables (but note that static on a
global variable or function has a different meaning from static on a
local variable).
> +static void d3d10_null_effect_variable_init(struct d3d10_effect_variable *v, struct ID3D10EffectVariableVtbl *vtbl)
> +{
> + v->vtbl = vtbl;
> + v->buffer = &null_local_buffer;
> + v->effect = NULL;
> + v->name = NULL;
> + v->semantic = NULL;
> + v->buffer_offset = 0;
> + v->annotation_count = 0;
> + v->flag = 0;
> + v->data_size = 0;
> + v->type = &null_type;
> + v->elements = NULL;
> + v->members = NULL;
> + v->annotations = NULL;
> +}
Most of these are redundant, since the variable will be already
initialized with zeroes.
Hi All,
I'm pleased to announce that after a lot of work lately I've pretty much
completed the graphics for the icons for shell32, user32 and the
programs all sizes and screen depths:
http://www.airwebreathe.org.uk/wine-icon/
There are a few minor things left to do:
* comctl32: Finish and submit - only idb_std_small.bmp needs to be
upgraded. Only idb_std_small.bmp is 32-bit in XP, and Vista
* comdlg32: Convert bitmaps to 8-bit. Maybe rework comdlg32 so
that the graphics are stored as a icons not bitmaps for so that
different colour depths can be handled elegantly. What does
windows do?
* credui: Test on a low bit-depth platform, and submit.
* cryptui: Redo emblems on certwarning.bmp, certerror.bmp, and
convert bitmaps into icons for so that different colour depths
can be handled elegantly.
* winecfg: new transparent bitmap won't work without xrender on a
32-bpp screen. Think again.
* wine: image lists still strip the alpha channel. talk to
thunderbird about 32-bit DDBs
* control, dxdiag, iexplore, winecfg: These programs currently do
not have an icon, and although my patches add the icon to the
src dir, further patches will be needed to add the icon to the
progam's resources, and display them in the app windows.
These things are all relatively minor, and I think at this stage it
would be good to merge as soon as possible. The only major issue that
remains is that there are 3 icons from Gnome that need to be relicensed
as LGPL for our use. I've e-mailed the gnome artists mailing list, so
hopefully we'll hear back from them soon.
Once this is done I'm suggesting we merge the icons for shell32, user32
and the programs. If you're interested you can try them right now at the
public-beta-2 branch of my gitorious repo:
http://gitorious.org/wine-tango/wine-tango/commits/public-beta-2
My final question is about what to do with my source artwork. The
artwork has been collected from a variety of sources. Some is SVGs, some
gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the
wine source repo, but does anyone have any bright ideas where these
files *should* go? They'll need to be published in case the icons ever
need to be changed in any way.
Any thoughts?
Best Regards
Joel