Wine-Devel
By thread
wine-devel@list.winehq.org
By month
Messages by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
July 2021
- 86 participants
- 1756 messages
[PATCH vkd3d 1/7] vkd3d: Resolve D3D12_DESCRIPTOR_RANGE_OFFSET_APPEND during table parsing.
by Conor McCarthy
Simplifies the code path for handling array bindings and unbounded
ranges.
Signed-off-by: Conor McCarthy <cmccarthy(a)codeweavers.com>
---
libs/vkd3d/command.c | 6 +-----
libs/vkd3d/state.c | 26 +++++++++++++++++++++-----
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/libs/vkd3d/command.c b/libs/vkd3d/command.c
index 7150c59b..8bed7303 100644
--- a/libs/vkd3d/command.c
+++ b/libs/vkd3d/command.c
@@ -2674,7 +2674,6 @@ static void d3d12_command_list_update_descriptor_table(struct d3d12_command_list
descriptor_table = root_signature_get_descriptor_table(root_signature, index);
- descriptor = base_descriptor;
descriptor_count = 0;
current_descriptor_write = descriptor_writes;
current_image_info = image_infos;
@@ -2682,10 +2681,7 @@ static void d3d12_command_list_update_descriptor_table(struct d3d12_command_list
{
range = &descriptor_table->ranges[i];
- if (range->offset != D3D12_DESCRIPTOR_RANGE_OFFSET_APPEND)
- {
- descriptor = base_descriptor + range->offset;
- }
+ descriptor = base_descriptor + range->offset;
for (j = 0; j < range->descriptor_count; ++j, ++descriptor)
{
diff --git a/libs/vkd3d/state.c b/libs/vkd3d/state.c
index a381679e..d62cb9a0 100644
--- a/libs/vkd3d/state.c
+++ b/libs/vkd3d/state.c
@@ -591,6 +591,8 @@ static HRESULT d3d12_root_signature_init_root_descriptor_tables(struct d3d12_roo
for (i = 0; i < desc->NumParameters; ++i)
{
const D3D12_ROOT_PARAMETER *p = &desc->pParameters[i];
+ unsigned int offset = 0;
+
if (p->ParameterType != D3D12_ROOT_PARAMETER_TYPE_DESCRIPTOR_TABLE)
continue;
@@ -604,6 +606,25 @@ static HRESULT d3d12_root_signature_init_root_descriptor_tables(struct d3d12_roo
if (!(table->ranges = vkd3d_calloc(table->range_count, sizeof(*table->ranges))))
return E_OUTOFMEMORY;
+ for (j = 0; j < range_count; ++j)
+ {
+ range = &p->u.DescriptorTable.pDescriptorRanges[j];
+
+ if (range->OffsetInDescriptorsFromTableStart != D3D12_DESCRIPTOR_RANGE_OFFSET_APPEND)
+ offset = range->OffsetInDescriptorsFromTableStart;
+
+ table->ranges[j].offset = offset;
+ table->ranges[j].descriptor_count = range->NumDescriptors;
+ table->ranges[j].descriptor_magic = vkd3d_descriptor_magic_from_d3d12(range->RangeType);
+ table->ranges[j].register_space = range->RegisterSpace;
+ table->ranges[j].base_register_idx = range->BaseShaderRegister;
+
+ TRACE("Descriptor table %u, range %u, offset %u, type %#x, count %u.\n", i, j,
+ offset, range->RangeType, range->NumDescriptors);
+
+ offset += range->NumDescriptors;
+ }
+
for (j = 0; j < range_count; ++j)
{
range = &p->u.DescriptorTable.pDescriptorRanges[j];
@@ -638,12 +659,7 @@ static HRESULT d3d12_root_signature_init_root_descriptor_tables(struct d3d12_roo
++cur_binding;
}
- table->ranges[j].offset = range->OffsetInDescriptorsFromTableStart;
- table->ranges[j].descriptor_count = range->NumDescriptors;
table->ranges[j].binding = vk_binding;
- table->ranges[j].descriptor_magic = vkd3d_descriptor_magic_from_d3d12(range->RangeType);
- table->ranges[j].register_space = range->RegisterSpace;
- table->ranges[j].base_register_idx = range->BaseShaderRegister;
}
}
--
2.32.0
July 30, 2021
[PATCH 3/3] d2d1: Implement d2d_effect_{Get,Set}Input{,Count}().
by Ziqing Hui
Signed-off-by: Ziqing Hui <zhui(a)codeweavers.com>
---
dlls/d2d1/d2d1_private.h | 4 +++
dlls/d2d1/effect.c | 61 ++++++++++++++++++++++++++++++++++++----
dlls/d2d1/tests/d2d1.c | 7 +----
3 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/dlls/d2d1/d2d1_private.h b/dlls/d2d1/d2d1_private.h
index ce99e7c3432..a80e1b6a18d 100644
--- a/dlls/d2d1/d2d1_private.h
+++ b/dlls/d2d1/d2d1_private.h
@@ -572,6 +572,10 @@ struct d2d_effect
LONG refcount;
ID2D1Factory *factory;
+ UINT32 min_inputs;
+ UINT32 max_inputs;
+ ID2D1Image **inputs;
+ UINT32 inputs_count;
};
void d2d_effect_init(struct d2d_effect *effect, ID2D1Factory *factory) DECLSPEC_HIDDEN;
diff --git a/dlls/d2d1/effect.c b/dlls/d2d1/effect.c
index 40dd2187953..50b1c5917f4 100644
--- a/dlls/d2d1/effect.c
+++ b/dlls/d2d1/effect.c
@@ -67,12 +67,19 @@ static ULONG STDMETHODCALLTYPE d2d_effect_Release(ID2D1Effect *iface)
{
struct d2d_effect *effect = impl_from_ID2D1Effect(iface);
ULONG refcount = InterlockedDecrement(&effect->refcount);
+ unsigned int i;
TRACE("%p decreasing refcount to %u.\n", iface, refcount);
if (!refcount)
{
ID2D1Factory_Release(effect->factory);
+ for (i = 0; i < effect->inputs_count; ++i)
+ {
+ if (effect->inputs[i])
+ ID2D1Image_Release(effect->inputs[i]);
+ }
+ heap_free(effect->inputs);
heap_free(effect);
}
@@ -166,26 +173,64 @@ static HRESULT STDMETHODCALLTYPE d2d_effect_GetSubProperties(ID2D1Effect *iface,
static void STDMETHODCALLTYPE d2d_effect_SetInput(ID2D1Effect *iface, UINT32 index, ID2D1Image *input, BOOL invalidate)
{
- FIXME("iface %p, index %u, input %p, invalidate %d stub!\n", iface, index, input, invalidate);
+ struct d2d_effect *effect = impl_from_ID2D1Effect(iface);
+
+ TRACE("iface %p, index %u, input %p, invalidate %d.\n", iface, index, input, invalidate);
+
+ if (index < effect->inputs_count)
+ {
+ if (effect->inputs[index])
+ ID2D1Image_Release(effect->inputs[index]);
+ ID2D1Image_AddRef(effect->inputs[index] = input);
+ }
}
static HRESULT STDMETHODCALLTYPE d2d_effect_SetInputCount(ID2D1Effect *iface, UINT32 count)
{
- FIXME("iface %p, count %u stub!\n", iface, count);
+ struct d2d_effect *effect = impl_from_ID2D1Effect(iface);
+ unsigned int i;
- return E_NOTIMPL;
+ TRACE("iface %p, count %u.\n", iface, count);
+
+ if (count < effect->min_inputs || count > effect->max_inputs)
+ return E_INVALIDARG;
+
+ if (count != effect->inputs_count)
+ {
+ if (count < effect->inputs_count)
+ {
+ for (i = count; i < effect->inputs_count; ++i)
+ {
+ if (effect->inputs[i])
+ ID2D1Image_Release(effect->inputs[i]);
+ }
+ }
+ effect->inputs_count = count;
+ HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, effect->inputs, sizeof(*effect->inputs) * count);
+ }
+
+ return S_OK;
}
static void STDMETHODCALLTYPE d2d_effect_GetInput(ID2D1Effect *iface, UINT32 index, ID2D1Image **input)
{
- FIXME("iface %p, index %u, input %p stub!\n", iface, index, input);
+ struct d2d_effect *effect = impl_from_ID2D1Effect(iface);
+
+ TRACE("iface %p, index %u, input %p.\n", iface, index, input);
+
+ if (index < effect->inputs_count && effect->inputs[index])
+ ID2D1Image_AddRef(*input = effect->inputs[index]);
+ else
+ *input = NULL;
}
static UINT32 STDMETHODCALLTYPE d2d_effect_GetInputCount(ID2D1Effect *iface)
{
- FIXME("iface %p stub!\n", iface);
+ struct d2d_effect *effect = impl_from_ID2D1Effect(iface);
- return 0;
+ TRACE("iface %p.\n", iface);
+
+ return effect->inputs_count;
}
static void STDMETHODCALLTYPE d2d_effect_GetOutput(ID2D1Effect *iface, ID2D1Image **output)
@@ -274,5 +319,9 @@ void d2d_effect_init(struct d2d_effect *effect, ID2D1Factory *factory)
effect->ID2D1Effect_iface.lpVtbl = &d2d_effect_vtbl;
effect->ID2D1Image_iface.lpVtbl = &d2d_effect_image_vtbl;
effect->refcount = 1;
+ effect->min_inputs = 1;
+ effect->max_inputs = 1;
+ effect->inputs_count = 1;
+ effect->inputs = heap_alloc_zero(sizeof(*effect->inputs));
ID2D1Factory_AddRef(effect->factory = factory);
}
diff --git a/dlls/d2d1/tests/d2d1.c b/dlls/d2d1/tests/d2d1.c
index 76ac27f11c6..ff2d3c8c1ba 100644
--- a/dlls/d2d1/tests/d2d1.c
+++ b/dlls/d2d1/tests/d2d1.c
@@ -9800,8 +9800,6 @@ static void test_effect(BOOL d3d11)
max_inputs, test->max_inputs);
}
- todo_wine
- {
input_count = ID2D1Effect_GetInputCount(effect);
ok (input_count == 1 || input_count == 2, "Got unexpected input count %u.\n", input_count);
input_count = (test->max_inputs < 64 ? test->max_inputs + 1 : 64);
@@ -9811,6 +9809,7 @@ static void test_effect(BOOL d3d11)
if (j < test->min_inputs || j > test->max_inputs)
ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
else
+ todo_wine_if(test->max_inputs > 1 && j > 1)
ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
}
@@ -9820,7 +9819,6 @@ static void test_effect(BOOL d3d11)
ID2D1Effect_GetInput(effect, j, &image_a);
ok(image_a == NULL, "Got unexpected image_a %p.\n", image_a);
}
- }
set_size_u(&size, 1, 1);
bitmap_desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM;
@@ -9830,8 +9828,6 @@ static void test_effect(BOOL d3d11)
hr = ID2D1RenderTarget_CreateBitmap(ctx.rt, size, NULL, 4, &bitmap_desc, &bitmap);
ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
- todo_wine
- {
ID2D1Effect_SetInput(effect, 0, (ID2D1Image *)bitmap, FALSE);
for (j = 0; j < input_count + 8; ++j)
{
@@ -9846,7 +9842,6 @@ static void test_effect(BOOL d3d11)
ID2D1Image_Release(image_a);
}
ID2D1Bitmap_Release(bitmap);
- }
ID2D1Effect_Release(effect);
winetest_pop_context();
--
2.25.1
July 30, 2021
[PATCH 2/3] d2d1/tests: Add tests for effect inputs.
by Ziqing Hui
Signed-off-by: Ziqing Hui <zhui(a)codeweavers.com>
---
dlls/d2d1/tests/d2d1.c | 53 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/dlls/d2d1/tests/d2d1.c b/dlls/d2d1/tests/d2d1.c
index 629bbd65523..76ac27f11c6 100644
--- a/dlls/d2d1/tests/d2d1.c
+++ b/dlls/d2d1/tests/d2d1.c
@@ -9680,13 +9680,16 @@ static void test_mt_factory(BOOL d3d11)
static void test_effect(BOOL d3d11)
{
- unsigned int i, min_inputs, max_inputs, str_size;
+ unsigned int i, j, min_inputs, max_inputs, str_size, input_count;
+ D2D1_BITMAP_PROPERTIES bitmap_desc;
D2D1_BUFFER_PRECISION precision;
ID2D1Image *image_a, *image_b;
struct d2d1_test_context ctx;
ID2D1DeviceContext *context;
ID2D1Factory1 *factory;
+ ID2D1Bitmap *bitmap;
ID2D1Effect *effect;
+ D2D1_SIZE_U size;
BYTE buffer[64];
BOOL cached;
CLSID clsid;
@@ -9797,6 +9800,54 @@ static void test_effect(BOOL d3d11)
max_inputs, test->max_inputs);
}
+ todo_wine
+ {
+ input_count = ID2D1Effect_GetInputCount(effect);
+ ok (input_count == 1 || input_count == 2, "Got unexpected input count %u.\n", input_count);
+ input_count = (test->max_inputs < 64 ? test->max_inputs + 1 : 64);
+ for (j = 0; j < input_count; ++j)
+ {
+ hr = ID2D1Effect_SetInputCount(effect, j);
+ if (j < test->min_inputs || j > test->max_inputs)
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+ else
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+ }
+
+ input_count = ID2D1Effect_GetInputCount(effect);
+ for (j = 0; j < input_count + 8; ++j)
+ {
+ ID2D1Effect_GetInput(effect, j, &image_a);
+ ok(image_a == NULL, "Got unexpected image_a %p.\n", image_a);
+ }
+ }
+
+ set_size_u(&size, 1, 1);
+ bitmap_desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM;
+ bitmap_desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_IGNORE;
+ bitmap_desc.dpiX = 96.0f;
+ bitmap_desc.dpiY = 96.0f;
+ hr = ID2D1RenderTarget_CreateBitmap(ctx.rt, size, NULL, 4, &bitmap_desc, &bitmap);
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+
+ todo_wine
+ {
+ ID2D1Effect_SetInput(effect, 0, (ID2D1Image *)bitmap, FALSE);
+ for (j = 0; j < input_count + 8; ++j)
+ {
+ if (j >= input_count)
+ ID2D1Effect_SetInput(effect, 0, (ID2D1Image *)bitmap, FALSE);
+ ID2D1Effect_GetInput(effect, j, &image_a);
+ if (j == 0)
+ ok(image_a == (ID2D1Image *)bitmap, "Got unexpected image_a %p.\n", image_a);
+ else
+ ok(image_a == NULL, "Got unexpected image_a %p.\n", image_a);
+ if (image_a)
+ ID2D1Image_Release(image_a);
+ }
+ ID2D1Bitmap_Release(bitmap);
+ }
+
ID2D1Effect_Release(effect);
winetest_pop_context();
}
--
2.25.1
July 30, 2021
[PATCH 1/3] d2d1/tests: Add failure tests for ID2D1Effect_GetValue().
by Ziqing Hui
Signed-off-by: Ziqing Hui <zhui(a)codeweavers.com>
---
This patch is identical to patch 210309.
dlls/d2d1/tests/d2d1.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/dlls/d2d1/tests/d2d1.c b/dlls/d2d1/tests/d2d1.c
index 72487692abf..629bbd65523 100644
--- a/dlls/d2d1/tests/d2d1.c
+++ b/dlls/d2d1/tests/d2d1.c
@@ -9680,13 +9680,14 @@ static void test_mt_factory(BOOL d3d11)
static void test_effect(BOOL d3d11)
{
- unsigned int i, min_inputs, max_inputs;
+ unsigned int i, min_inputs, max_inputs, str_size;
D2D1_BUFFER_PRECISION precision;
ID2D1Image *image_a, *image_b;
struct d2d1_test_context ctx;
ID2D1DeviceContext *context;
ID2D1Factory1 *factory;
ID2D1Effect *effect;
+ BYTE buffer[64];
BOOL cached;
CLSID clsid;
HRESULT hr;
@@ -9735,6 +9736,33 @@ static void test_effect(BOOL d3d11)
todo_wine
{
+ hr = ID2D1Effect_GetValue(effect, 0xdeadbeef, D2D1_PROPERTY_TYPE_CLSID, (BYTE *)&clsid, sizeof(clsid));
+ ok(hr == D2DERR_INVALID_PROPERTY, "Got unexpected hr %#x.\n", hr);
+
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_CLSID, buffer, sizeof(clsid) + 1);
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_CLSID, buffer, sizeof(clsid) - 1);
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_CLSID, buffer, sizeof(clsid));
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_DISPLAYNAME, D2D1_PROPERTY_TYPE_STRING, buffer, sizeof(buffer));
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+ str_size = (wcslen((WCHAR *)buffer) + 1) * sizeof(WCHAR);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_DISPLAYNAME, D2D1_PROPERTY_TYPE_STRING, buffer, str_size);
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_DISPLAYNAME, D2D1_PROPERTY_TYPE_STRING, buffer, str_size - 1);
+ ok(hr == D2DERR_INSUFFICIENT_BUFFER, "Got unexpected hr %#x.\n", hr);
+
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, 0xdeadbeef, (BYTE *)&clsid, sizeof(clsid));
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_UNKNOWN, (BYTE *)&clsid, sizeof(clsid));
+ ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_VECTOR4, (BYTE *)&clsid, sizeof(clsid));
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+ hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID, D2D1_PROPERTY_TYPE_VECTOR4, buffer, sizeof(buffer));
+ ok(hr == E_INVALIDARG, "Got unexpected hr %#x.\n", hr);
+
hr = ID2D1Effect_GetValue(effect, D2D1_PROPERTY_CLSID,
D2D1_PROPERTY_TYPE_CLSID, (BYTE *)&clsid, sizeof(clsid));
ok(hr == S_OK, "Got unexpected hr %#x.\n", hr);
--
2.25.1
July 30, 2021
[PATCH vkd3d] tests: Include <stddef.h> from "d3d12_crosstest.h".
by Chip Davis
Neither MinGW's nor Microsoft's <windows.h> includes <stddef.h>, either
directly or indirectly.
Fixes cross compilation errors related to using offsetof(3).
Signed-off-by: Chip Davis <cdavis(a)codeweavers.com>
---
tests/d3d12_crosstest.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/d3d12_crosstest.h b/tests/d3d12_crosstest.h
index 43af375..0b77bde 100644
--- a/tests/d3d12_crosstest.h
+++ b/tests/d3d12_crosstest.h
@@ -52,6 +52,7 @@ typedef int HRESULT;
#include <inttypes.h>
#include <limits.h>
#include <math.h>
+#include <stddef.h>
#include <time.h>
#ifdef _WIN32
--
2.31.1
July 30, 2021
[PATCH] jscript: Allocate non-temporary storage for statement lists which persist after parsing.
by Paul Gofman
Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com>
---
new_statement_list() uses parser_alloc_tmp() and the memory for statement list may get freed
in script_parse() thus making compile_function() use the freed memory.
dlls/jscript/parser.y | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/dlls/jscript/parser.y b/dlls/jscript/parser.y
index 9fc7ea61dc3..4bad7e326db 100644
--- a/dlls/jscript/parser.y
+++ b/dlls/jscript/parser.y
@@ -249,7 +249,17 @@ static expression_t *new_prop_and_value_expression(parser_ctx_t*,property_list_t
/* ECMA-262 10th Edition 15.1 */
Script
- : ScriptBody HtmlComment { ctx->source = $1; }
+ : ScriptBody HtmlComment {
+ if ($1)
+ {
+ ctx->source = parser_alloc(ctx, sizeof(*ctx->source));
+ *ctx->source = *$1;
+ }
+ else
+ {
+ ctx->source = NULL;
+ }
+ }
/* ECMA-262 10th Edition 15.1 */
ScriptBody
@@ -1440,7 +1450,15 @@ static expression_t *new_function_expression(parser_ctx_t *ctx, const WCHAR *ide
ret->identifier = identifier;
ret->parameter_list = parameter_list ? parameter_list->head : NULL;
- ret->statement_list = statement_list;
+ if (statement_list)
+ {
+ ret->statement_list = parser_alloc(ctx, sizeof(*ret->statement_list));
+ *ret->statement_list = *statement_list;
+ }
+ else
+ {
+ ret->statement_list = NULL;
+ }
ret->event_target = event_target;
ret->src_str = src_str;
ret->src_len = src_len;
@@ -1657,7 +1675,6 @@ HRESULT script_parse(script_ctx_t *ctx, struct _compiler_ctx_t *compiler, byteco
jsstr_release(line_str);
return DISP_E_EXCEPTION;
}
-
*ret = parser_ctx;
return S_OK;
}
--
2.31.1
July 29, 2021
Re: [PATCH 1/4] Handle FSCTL in NtDeviceIoControlFile.
by Alexandre Julliard
"Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes:
> Actually, I think our definition is wrong, and the ordering of
> Internal and InternalHigh shouldn't depend on endianness. It was added
> in [1], but I think that commit incorrectly assumed that InternalHigh
> was a "high" part of Internal in any meaningful way, which it is not.
>
> For that matter, is the Offset/OffsetHigh part correct? I'm not sure
> there are any places where we alias those members with a
> LARGE_INTEGER.
>
> [Did Windows *ever* support BE CPUs? I know that early versions of NT
> supported Alpha, MIPS, PowerPC (and current version support ARM), but
> my research tells me that even at the time all were bi-endian and that
> Windows ran them in LE.]
Windows never supported it, and I don't think it makes sense for us to
pretend that we do either.
--
Alexandre Julliard
julliard(a)winehq.org
July 29, 2021
Re: [PATCH 1/4] Handle FSCTL in NtDeviceIoControlFile.
by Zebediah Figura (she/her)
On 7/29/21 1:30 PM, Alex Xu (Hello71) wrote:
> Excerpts from Zebediah Figura (she/her)'s message of July 26, 2021 12:36 pm:
>> On 7/26/21 9:13 AM, Alex Xu (Hello71) wrote:
>>> Excerpts from Chip Davis's message of July 25, 2021 4:06 pm:
>>>> Needs tests showing that FSCTLs do indeed work with NtDeviceIoControlFile().
>>>>
>>>>
>>>> Chip
>>>>
>>>
>>> Yes, I see your point.
>>>
>>> It looks like it should be simple to add NtDeviceIoControlFile in
>>> dlls/ntdll/tests/file.c, but I was wondering: there don't seem to be any
>>> tests already, and it seems like it should make more sense to add a test
>>> for DeviceIoControl instead (since that is what most applications will
>>> care about).
>>>
>>> However, looking at that, there are two implementations of
>>> DeviceIoControl, in kernelbase and kernel32. Why doesn't the kernel32
>>> one forward to kernelbase like most kernel32 functions? Also, why is the
>>> kernelbase function different from the kernel32 function? I don't know
>>> anything about VxDs, but it seems odd that the kernel32 one uses
>>> Information only for non-overlapped IO, but kernelbase uses it for
>>> overlapped too. Actually, looking at dlls/ntdll, it doesn't seem like
>>> InternalHigh is actually used for anything? It seems like it might
>>> happen to work on little-endian machines by chance due to alignment of
>>> OVERLAPPED and IO_STATUS_BLOCK, but this doesn't seem like a reliable
>>> method.
>>>
>>> I checked git history, seems like InternalHigh should actually be
>>> Information everywhere? Thoughts?
>>
>> No, this was done intentionally by Microsoft. OVERLAPPED is a documented
>> user API; IO_STATUS_BLOCK is not (although now it is a documented kernel
>> API). The fields of IO_STATUS_BLOCK are handled at the
>> kernel32/kernelbase level but this handling is obscured in the user API
>> by calling them "Internal" and "InternalHigh". The fields in the two
>> structures match regardless of endianness.
>
> How is this done in Wine? IO_STATUS_BLOCK in include/winternl.h has
> Status then Information, and include/winbase.h has InternalHigh then
> Internal for WORDS_BIGENDIAN, and reversed if not. Seems to me like
> InternalHigh is Information on LE, and Status/Pointer on BE.
>
> I think Windows probably won't actually support BE CPUs in the future,
> considering they are becoming less and less popular, and looks like
> MinGW does not support it, but why should we intentionally write to
> Information and then read from InternalHigh? It seems unnecessarily
> confusing. The only value explicitly stored in InternalHigh in Wine
> appears to be 0; all other values are aliased.
Actually, I think our definition is wrong, and the ordering of Internal
and InternalHigh shouldn't depend on endianness. It was added in [1],
but I think that commit incorrectly assumed that InternalHigh was a
"high" part of Internal in any meaningful way, which it is not.
For that matter, is the Offset/OffsetHigh part correct? I'm not sure
there are any places where we alias those members with a LARGE_INTEGER.
[Did Windows *ever* support BE CPUs? I know that early versions of NT
supported Alpha, MIPS, PowerPC (and current version support ARM), but my
research tells me that even at the time all were bi-endian and that
Windows ran them in LE.]
[1] https://www.winehq.org/pipermail/wine-patches/2005-March/016419.html
>> I'm not sure why we don't load VXD drivers in kernelbase; there doesn't
>> seem to be any obvious reason why we can't, but we don't anyway.
>
> I guess maybe the logic is that Win9x-era programs should use kernel32,
> not kernelbase? kernelbase DeviceIoControl is only 1.5 years old, maybe
> Julliard remembers?
>
> I think current VxD behavior is basically "non-standard Wine extension"
> nowadays anyways; as long as programs work with no VxDs installed I
> don't see the issue either way.
>
>> There aren't any generic tests for NtDeviceIoControlFile and
>> NtFsControlFile because all of the tests are rather specific to the
>> different ioctls used. I'd recommend finding any place in the tests
>> where one is used and testing the other as well. It wouldn't surprise me
>> if both are identical nowadays.
>
> OK, sounds good.
>
> Regards,
> Alex.
>
July 29, 2021
Re: [PATCH 1/4] Handle FSCTL in NtDeviceIoControlFile.
by Alex Xu (Hello71)
Excerpts from Zebediah Figura (she/her)'s message of July 26, 2021 12:36 pm:
> On 7/26/21 9:13 AM, Alex Xu (Hello71) wrote:
>> Excerpts from Chip Davis's message of July 25, 2021 4:06 pm:
>>> Needs tests showing that FSCTLs do indeed work with NtDeviceIoControlFile().
>>>
>>>
>>> Chip
>>>
>>
>> Yes, I see your point.
>>
>> It looks like it should be simple to add NtDeviceIoControlFile in
>> dlls/ntdll/tests/file.c, but I was wondering: there don't seem to be any
>> tests already, and it seems like it should make more sense to add a test
>> for DeviceIoControl instead (since that is what most applications will
>> care about).
>>
>> However, looking at that, there are two implementations of
>> DeviceIoControl, in kernelbase and kernel32. Why doesn't the kernel32
>> one forward to kernelbase like most kernel32 functions? Also, why is the
>> kernelbase function different from the kernel32 function? I don't know
>> anything about VxDs, but it seems odd that the kernel32 one uses
>> Information only for non-overlapped IO, but kernelbase uses it for
>> overlapped too. Actually, looking at dlls/ntdll, it doesn't seem like
>> InternalHigh is actually used for anything? It seems like it might
>> happen to work on little-endian machines by chance due to alignment of
>> OVERLAPPED and IO_STATUS_BLOCK, but this doesn't seem like a reliable
>> method.
>>
>> I checked git history, seems like InternalHigh should actually be
>> Information everywhere? Thoughts?
>
> No, this was done intentionally by Microsoft. OVERLAPPED is a documented
> user API; IO_STATUS_BLOCK is not (although now it is a documented kernel
> API). The fields of IO_STATUS_BLOCK are handled at the
> kernel32/kernelbase level but this handling is obscured in the user API
> by calling them "Internal" and "InternalHigh". The fields in the two
> structures match regardless of endianness.
How is this done in Wine? IO_STATUS_BLOCK in include/winternl.h has
Status then Information, and include/winbase.h has InternalHigh then
Internal for WORDS_BIGENDIAN, and reversed if not. Seems to me like
InternalHigh is Information on LE, and Status/Pointer on BE.
I think Windows probably won't actually support BE CPUs in the future,
considering they are becoming less and less popular, and looks like
MinGW does not support it, but why should we intentionally write to
Information and then read from InternalHigh? It seems unnecessarily
confusing. The only value explicitly stored in InternalHigh in Wine
appears to be 0; all other values are aliased.
> I'm not sure why we don't load VXD drivers in kernelbase; there doesn't
> seem to be any obvious reason why we can't, but we don't anyway.
I guess maybe the logic is that Win9x-era programs should use kernel32,
not kernelbase? kernelbase DeviceIoControl is only 1.5 years old, maybe
Julliard remembers?
I think current VxD behavior is basically "non-standard Wine extension"
nowadays anyways; as long as programs work with no VxDs installed I
don't see the issue either way.
> There aren't any generic tests for NtDeviceIoControlFile and
> NtFsControlFile because all of the tests are rather specific to the
> different ioctls used. I'd recommend finding any place in the tests
> where one is used and testing the other as well. It wouldn't surprise me
> if both are identical nowadays.
OK, sounds good.
Regards,
Alex.
July 29, 2021
Re: Proposal to take over macOS packaging
by Dean Greer
Hi Zhenbo
The proposal does include me (Dean aka Gcenx), the proposal incorporates
the current configuration/findings that are used for the packages I'm
providing.
However the url you provided is for the homebrew tap now the packages for
the actual location see [1]
[1]: https://github.com/Gcenx/macOS_Wine_builds
On Thu, Jul 29, 2021 at 12:39 PM Zhenbo Li <litimetal(a)gmail.com> wrote:
> Hi,
>
> How about using Gcenx's package[1]? If Gcenx's package is okay, I
> think we may avoid some duplicate jobs.
>
>
> [1]: https://github.com/Gcenx/homebrew-wine
>
> On Thu, Jul 29, 2021 at 2:33 AM Gijs Vermeulen <gijsvrm(a)gmail.com> wrote:
> >
> > Hi everyone,
> >
> > Currently, official macOS packages haven't been released since wine-5.7.
> Thus I'm sending this email on behalf of myself and Dean Greer to
> officially nominate ourselves to take over the macOS packaging.
> >
> > There are, however, some specifics we'd like to discuss.
> >
> > The old packages were built with compatibility for macOS 10.8 and
> higher, but Apple stopped supporting 10.8 a very long time ago and it would
> be hard to keep supporting it for the packages.
> >
> > To get anything lower functional would mean needing to compile all the
> needed dylibs on the lowest supported version, as package managers don't
> have prebuilds for these versions.
> >
> > The ideal solution would be to raise the minimum macOS version to 10.13.
> This version has only recently lost support and would allow us to ship
> feature-complete packages.
> >
> > Metal also started maturing a lot from 10.13 onwards. [1]
> >
> > Is this something that you could agree too?
> >
> > Kind regards,
> > Gijs & Dean
> >
> > [1]
> https://source.winehq.org/git/wine.git/commit/0d23ecd9ec8a0c24e5444e0fc9cf6…
>
>
>
> --
>
> Sincerely,
> Zhenbo Li
>
>
July 29, 2021