May 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 1/6] d3dx9: Get rid of table lookup for converting between register indexes and offsets.

by Paul Gofman

On 05/29/2017 09:19 PM, Matteo Bruni wrote: > 2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > >> static unsigned int get_reg_offset(unsigned int table, unsigned int offset) >> { >> - return offset / table_info[table].reg_component_count; >> + return table == PRES_REGTAB_OBCONST ? offset : offset >> 2; >> +} >> + >> +static unsigned int get_offset_reg(unsigned int table, unsigned int reg_idx) >> +{ >> + return table == PRES_REGTAB_OBCONST ? reg_idx : reg_idx << 2; >> } > I suppose using an explicit division and multiplication here wouldn't > change the generated code, in which case I'd slightly prefer that. It > doesn't matter right now, just mentioning it for potentially similar > cases in the future. Yes, sure, if it would be constant literal for multiplication / division here. >> @@ -1033,9 +1035,9 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const >> unsigned int offset; >> >> offset = start_offset + i * major_stride + j; >> - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) >> + if (get_reg_offset(table, offset) >= rs->table_sizes[table]) >> { >> - if (table_info[table].reg_component_count != 1) >> + if (table != PRES_REGTAB_OBCONST) >> FIXME("Output offset exceeds table size, name %s, component %u.\n", >> debugstr_a(param->name), i); >> break; > Not new and probably I just forgot the details, but, why would the > register component count matter for the FIXME? The length of the data to be copied to registers can be limited by RegisterCount in (pre)shader constant description. But when register is 4-value, the major count for output loop should already mind that (since we always have row count and column count <= 4). The only legitimate case we may need to break from the inner loop is boolean constant matrix setting. So actually fixme condition should never happen, though break from the inner loop on boolean constant setting may be required. I am changing this place in the next patches (I didn't send yet) when optimizing this place. I was actually going to add a bit more tests for this case along with the forthcoming changes, and I suspect a bug here (I actually need to effectively compare with constant register count and not with the table size). We have a test for full update with boolean matrices (which will not trigger the error here) but commit of individual matrices test probably will. > >> - offset = reg_index * table_info[table].reg_component_count >> - + offset % table_info[table].reg_component_count; >> + offset = get_offset_reg(table, reg_index) + offset % get_offset_reg(table, 1); > That "get_offset_reg(table, 1)" comes up a number of times. Maybe > worth making an extra get_reg_components(table) (or similar) helper? > Simply for even greater clarity. > > Yes, sure.

May 29, 2017

Re: [PATCH 6/6] d3dx9: Merge constant setting for child parameters when possible.

by Matteo Bruni

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + if (!(const_set->table == current_table && current_start_offset == start_offset > + && const_set->direct_copy == first_const->direct_copy > + && current_data == const_set->param->data > + && (const_set->direct_copy || (first_const->param->type == const_set->param->type > + && first_const->param->class == const_set->param->class > + && first_const->param->columns == const_set->param->columns > + && first_const->param->rows == const_set->param->rows > + && first_const->register_count == const_set->register_count > + && (i == const_tab->const_set_count - 1 > + || first_const->param->element_count == const_set->param->element_count))))) > + { > + TRACE("direct_copy %u, i %u, index %u, param %s.%s, current_data %p, const_set->param->data %p, "\ > + "current_start_offset %u, start_offset %u, const_set->table %u, current_table %u.\n", > + const_set->direct_copy, i, index, debugstr_a(param->name), > + debugstr_a(const_set->param->name), current_data, const_set->param->data, > + current_start_offset, start_offset, const_set->table, current_table); > + break; > + } This looks like a debug trace. > + TRACE("Merging %u child parameters for %s, not merging %u, direct_copy %u.\n", i - index, > + debugstr_a(param->name), const_tab->const_set_count - i, first_const->direct_copy); I guess it's intentional that you're printing this even when not merging anything, in that case the TRACE sounds a bit awkward though. Maybe have a separate TRACE for that case? BTW, please format the BOOL with %#x. > + if (i > index + 1) > + { > + first_const->element_count = element_count; > + if (first_const->direct_copy) > + { > + first_const->element_count = 1; > + if (index == start_index > + && !(param->type == D3DXPT_VOID && param->class == D3DXPC_STRUCT)) > + { > + if (param_type_to_table_type(param->type) == PRES_VT_MAX) > + return D3DERR_INVALIDCALL; > + first_const->param = param; > + } > + first_const->register_count = get_reg_offset(current_table, current_start_offset) > + - first_const->register_index; > + } > + memmove(&const_tab->const_set[index + 1], &const_tab->const_set[i], > + sizeof(*const_tab->const_set) * (const_tab->const_set_count - i)); > + const_tab->const_set_count -= i - index - 1; > + } Just for my own curiosity, do you think it's significant to merge non-direct_copy entries? Not that it hurts anything to have it.

May 29, 2017

Re: [PATCH 4/6] d3dx9: Evaluate condition if parameter can be directly copied during initialization.

by Matteo Bruni

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: The patch subject is a bit cumbersome IMO, what about "d3dx9: Add a direct copy path to set_constants()."?

May 29, 2017

Re: [PATCH 3/6] d3dx9: Factor out param_type_to_table_type() function.

by Matteo Bruni

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 262b7c1..bddd74f 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -193,7 +193,8 @@ enum pres_value_type > PRES_VT_FLOAT, > PRES_VT_DOUBLE, > PRES_VT_INT, > - PRES_VT_BOOL > + PRES_VT_BOOL, > + PRES_VT_MAX > }; I guess you mean PRES_VT_COUNT. > > static const struct > @@ -260,6 +261,22 @@ struct d3dx_pres_ins > struct d3dx_pres_operand output; > }; > > +static enum pres_value_type param_type_to_table_type(D3DXPARAMETER_TYPE type) In d3d we usually name those the other way around e.g. table_type_from_param_type().

May 29, 2017

Re: [PATCH 2/6] d3dx9: Factor out get_constant_dimensions() function.

by Matteo Bruni

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 43 +++++++++++++++++++++++++++---------------- > 1 file changed, 27 insertions(+), 16 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 29a2346..262b7c1 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -979,6 +979,31 @@ void d3dx_free_param_eval(struct d3dx_param_eval *peval) > HeapFree(GetProcessHeap(), 0, peval); > } > > +static void get_constant_dimensions(struct d3dx_const_param_eval_output *const_set, BOOL *transpose, > + unsigned int *major, unsigned int *minor, unsigned int *major_stride, unsigned int *n, > + unsigned int *count) It seems better to pass around a struct pointer in place of all those separate out arguments, e.g. struct const_upload_info. Then you can name the helper get_"structname"() too. > + *n = min(*major * *major_stride, > + get_offset_reg(table, const_set->register_count) + *major_stride - 1) / *major_stride; > + *count = *n * *minor; Preexisting, but "n" is a bit confusing, especially considering that there is a "count" too. Something like "available_major" / "reg_count"? count might be "component_count" or similar. Maybe you can find some better names...

May 29, 2017

Re: [PATCH 1/6] d3dx9: Get rid of table lookup for converting between register indexes and offsets.

by Matteo Bruni

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > static unsigned int get_reg_offset(unsigned int table, unsigned int offset) > { > - return offset / table_info[table].reg_component_count; > + return table == PRES_REGTAB_OBCONST ? offset : offset >> 2; > +} > + > +static unsigned int get_offset_reg(unsigned int table, unsigned int reg_idx) > +{ > + return table == PRES_REGTAB_OBCONST ? reg_idx : reg_idx << 2; > } I suppose using an explicit division and multiplication here wouldn't change the generated code, in which case I'd slightly prefer that. It doesn't matter right now, just mentioning it for potentially similar cases in the future. Also this patch probably should have been split in two, with the first patch introducing get_offset_reg() with no functional changes and the second hardcoding the table check / dropping the table lookup. Not worth a rework at this point I guess. > @@ -1033,9 +1035,9 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > unsigned int offset; > > offset = start_offset + i * major_stride + j; > - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) > + if (get_reg_offset(table, offset) >= rs->table_sizes[table]) > { > - if (table_info[table].reg_component_count != 1) > + if (table != PRES_REGTAB_OBCONST) > FIXME("Output offset exceeds table size, name %s, component %u.\n", > debugstr_a(param->name), i); > break; Not new and probably I just forgot the details, but, why would the register component count matter for the FIXME? > - offset = reg_index * table_info[table].reg_component_count > - + offset % table_info[table].reg_component_count; > + offset = get_offset_reg(table, reg_index) + offset % get_offset_reg(table, 1); That "get_offset_reg(table, 1)" comes up a number of times. Maybe worth making an extra get_reg_components(table) (or similar) helper? Simply for even greater clarity.

May 29, 2017

Re: [PATCH v7 08/26] x86/insn-eval: Add a utility function to get register offsets

by Borislav Petkov

On Fri, May 05, 2017 at 11:17:06AM -0700, Ricardo Neri wrote: > The function get_reg_offset() returns the offset to the register the > argument specifies as indicated in an enumeration of type offset. Callers > of this function would need the definition of such enumeration. This is > not needed. Instead, add helper functions for this purpose. These functions > are useful in cases when, for instance, the caller needs to decide whether > the operand is a register or a memory location by looking at the rm part > of the ModRM byte. As of now, this is the only helper function that is > needed. > > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > Cc: Kees Cook <keescook(a)chromium.org> > Cc: Thomas Garnier <thgarnie(a)google.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Dmitry Vyukov <dvyukov(a)google.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/include/asm/insn-eval.h | 1 + > arch/x86/lib/insn-eval.c | 15 +++++++++++++++ > 2 files changed, 16 insertions(+) > > diff --git a/arch/x86/include/asm/insn-eval.h b/arch/x86/include/asm/insn-eval.h > index 5cab1b1..7e8c963 100644 > --- a/arch/x86/include/asm/insn-eval.h > +++ b/arch/x86/include/asm/insn-eval.h > @@ -12,5 +12,6 @@ > #include <asm/ptrace.h> > > void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs); > +int insn_get_modrm_rm_off(struct insn *insn, struct pt_regs *regs); > > #endif /* _ASM_X86_INSN_EVAL_H */ > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c > index 182e2ae..8b16761 100644 > --- a/arch/x86/lib/insn-eval.c > +++ b/arch/x86/lib/insn-eval.c > @@ -97,6 +97,21 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > return regoff[regno]; > } > > +/** > + * insn_get_reg_offset_modrm_rm() - Obtain register in r/m part of ModRM byte That name needs to be synced with the function name below. > + * @insn: Instruction structure containing the ModRM byte > + * @regs: Structure with register values as seen when entering kernel mode > + * > + * Return: The register indicated by the r/m part of the ModRM byte. The > + * register is obtained as an offset from the base of pt_regs. In specific > + * cases, the returned value can be -EDOM to indicate that the particular value > + * of ModRM does not refer to a register and shall be ignored. > + */ > +int insn_get_modrm_rm_off(struct insn *insn, struct pt_regs *regs) ^^^^^^^^^^^^^^^^^^^^ -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

May 29, 2017

Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

by Borislav Petkov

On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote: > We are not in a critical failure path. The invalid register type is caused > when trying to decode invalid instruction bytes from a user-space program. > Thus, simply print an error message. To prevent this warning from being > abused from user space programs, use the rate-limited variant of printk. > > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Andy Lutomirski <luto(a)kernel.org> > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Masami Hiramatsu <mhiramat(a)kernel.org> > Cc: Adrian Hunter <adrian.hunter(a)intel.com> > Cc: Kees Cook <keescook(a)chromium.org> > Cc: Thomas Garnier <thgarnie(a)google.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Dmitry Vyukov <dvyukov(a)google.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/lib/insn-eval.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c > index e746a6f..182e2ae 100644 > --- a/arch/x86/lib/insn-eval.c > +++ b/arch/x86/lib/insn-eval.c > @@ -5,6 +5,7 @@ > */ > #include <linux/kernel.h> > #include <linux/string.h> > +#include <linux/ratelimit.h> > #include <asm/inat.h> > #include <asm/insn.h> > #include <asm/insn-eval.h> > @@ -85,9 +86,8 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > break; > > default: > - pr_err("invalid register type"); > - BUG(); > - break; > + printk_ratelimited(KERN_ERR "insn-eval: x86: invalid register type"); You can use pr_err_ratelimited() and define "insn-eval" with pr_fmt. Look for examples in the tree. Btw, "insn-eval" is perhaps not the right name - since we're building an instruction decoder, maybe it should be called "insn-dec" or so. I'm looking at those other arch/x86/lib/insn.c, arch/x86/include/asm/inat.h things and how they're starting to morph into one decoding facility, AFAICT. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

May 29, 2017

Re: [PATCH v7 05/26] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0

by Borislav Petkov

On Fri, May 05, 2017 at 11:17:03AM -0700, Ricardo Neri wrote: > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software > Developer's Manual volume 2A states that when a SIB byte is used and the > base of the SIB byte points is base = 101b and the mod part > of the ModRM byte is zero, the base port on the effective address > computation is null. In this case, a 32-bit displacement follows the SIB > byte. This is obtained when the instruction decoder parses the operands. > > To signal this scenario, a -EDOM error is returned to indicate callers that > they should ignore the base. > > Cc: Borislav Petkov <bp(a)suse.de> > Cc: Andy Lutomirski <luto(a)kernel.org> > Cc: Dave Hansen <dave.hansen(a)linux.intel.com> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com> > Cc: Colin Ian King <colin.king(a)canonical.com> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Nathan Howard <liverlint(a)gmail.com> > Cc: Adan Hawthorn <adanhawthorn(a)gmail.com> > Cc: Joe Perches <joe(a)perches.com> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> > Cc: x86(a)kernel.org > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> > --- > arch/x86/mm/mpx.c | 27 ++++++++++++++++++++------- > 1 file changed, 20 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c > index 7397b81..30aef92 100644 > --- a/arch/x86/mm/mpx.c > +++ b/arch/x86/mm/mpx.c > @@ -122,6 +122,15 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs, > > case REG_TYPE_BASE: > regno = X86_SIB_BASE(insn->sib.value); > + /* > + * If ModRM.mod is 0 and SIB.base == 5, the base of the > + * register-indirect addressing is 0. In this case, a > + * 32-bit displacement is expected in this case; the > + * instruction decoder finds such displacement for us. That last sentence reads funny. Just say: "In this case, a 32-bit displacement follows the SIB byte." > + */ > + if (!X86_MODRM_MOD(insn->modrm.value) && regno == 5) > + return -EDOM; > + > if (X86_REX_B(insn->rex_prefix.value)) > regno += 8; > break; -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

May 29, 2017

Re: [PATCH] api-ms-win-security-activedirectoryclient-l1-1-0: Add dll.

by Nikolay Sivov

On 29.05.2017 14:04, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > configure | 2 ++ > configure.ac | 1 + > dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in | 1 + > .../api-ms-win-security-activedirectoryclient-l1-1-0.spec | 8 ++++++++ > tools/make_specfiles | 4 ++++ > 5 files changed, 16 insertions(+) > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > > diff --git a/configure b/configure > index d2d391c..fb22627 100755 > --- a/configure > +++ b/configure > @@ -1026,6 +1026,7 @@ enable_api_ms_win_ntuser_dc_access_l1_1_0 > enable_api_ms_win_power_base_l1_1_0 > enable_api_ms_win_power_setting_l1_1_0 > enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +enable_api_ms_win_security_activedirectoryclient_l1_1_0 > enable_api_ms_win_security_audit_l1_1_1 > enable_api_ms_win_security_base_l1_1_0 > enable_api_ms_win_security_base_l1_2_0 > @@ -17897,6 +17898,7 @@ wine_fn_config_dll api-ms-win-ntuser-dc-access-l1-1-0 enable_api_ms_win_ntuser_d > wine_fn_config_dll api-ms-win-power-base-l1-1-0 enable_api_ms_win_power_base_l1_1_0 > wine_fn_config_dll api-ms-win-power-setting-l1-1-0 enable_api_ms_win_power_setting_l1_1_0 > wine_fn_config_dll api-ms-win-rtcore-ntuser-private-l1-1-0 enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +wine_fn_config_dll api-ms-win-security-activedirectoryclient-l1-1-0 enable_api_ms_win_security_activedirectoryclient_l1_1_0 > wine_fn_config_dll api-ms-win-security-audit-l1-1-1 enable_api_ms_win_security_audit_l1_1_1 > wine_fn_config_dll api-ms-win-security-base-l1-1-0 enable_api_ms_win_security_base_l1_1_0 > wine_fn_config_dll api-ms-win-security-base-l1-2-0 enable_api_ms_win_security_base_l1_2_0 > diff --git a/configure.ac b/configure.ac > index db4d168..dde867b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2843,6 +2843,7 @@ WINE_CONFIG_DLL(api-ms-win-ntuser-dc-access-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-setting-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-rtcore-ntuser-private-l1-1-0) > +WINE_CONFIG_DLL(api-ms-win-security-activedirectoryclient-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-audit-l1-1-1) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-2-0) > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > new file mode 100644 > index 0000000..e1e99bd > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > @@ -0,0 +1 @@ > +MODULE = api-ms-win-security-activedirectoryclient-l1-1-0.dll > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > new file mode 100644 > index 0000000..eef1c40 > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > @@ -0,0 +1,8 @@ > +@ stub DsBindWithSpnExW > +@ stub DsCrackNamesW > +@ stub DsFreeDomainControllerInfoW > +@ stub DsFreeNameResultW > +@ stub DsFreePasswordCredentials > +@ stub DsGetDomainControllerInfoW > +@ stub DsMakePasswordCredentialsW > +@ stub DsUnBindW > diff --git a/tools/make_specfiles b/tools/make_specfiles > index e544293..910bd0f 100755 > --- a/tools/make_specfiles > +++ b/tools/make_specfiles > @@ -157,6 +157,10 @@ my @dll_groups = > "api-ms-win-power-setting-l1-1-0", > ], > [ > + "ntdsapi", > + "api-ms-win-security-activedirectoryclient-l1-1-0", > + ], > + [ > "kernel32", > "api-ms-win-appmodel-identity-l1-1-0", > "api-ms-win-appmodel-runtime-l1-1-1", > Those exports are present in kernelbase spec file, maybe it's better to forward to it?

May 29, 2017