Re: WineTools
Vincent Béron wrote: Le lun 17/01/2005 à 04:40, Joachim von Thadden a écrit : Hi, I am maintainer of the new WineTools package. As it is related on http://www.winehq.org/site/download under "3rd Party Tools" I want you do know that the text has to be changed, as Frank discontinued development for WineTools since a long time. The text should be now: WineTools is a menu driven installer for installing Windows programs under Linux written by Joachim von Thadden. This software lets you install the following Windows software: DCOM98, IE6, Windows Core Fonts, Windows System Software, Office & Office Viewer, Adobe Photoshop 7, Illustrator 9 and many other programs. "Written by" or "maintained by"? I thought Frank wrote it in the beginning... You will see in the patch that I sent: http://www.winehq.org/hypermail/wine-patches/2005/01/att-0477/01-press-download.diff I removed "under Linux written by Joachim von Thadden" As I had the exact same thoughts! Tom
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
Luke Kenneth Casson Leighton wrote: On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote: A DCOM implementation is more than a header file containing a few comments and a few declarations of Win32 functions that are randomly placed in there. perhaps it would be best for me to provide a reference to something i found on The Open Group's site. i assume that you (rob) are familiar with and aware of these documents, but for the benefit of those people who are not or might not be, i found these in some [accidental!] research last week and tonight. http://archive.opengroup.org/dce/meetings/july98/FrankHayes/index.htm http://www.opengroup.org/comsource/ http://www.opengroup.org/pubs/catalog/ax01.htm Thanks. The last link has a lot information and is not a document I'd found before. A lot of the info in there is already covered by MSDN, but I'm sure there's plenty that isn't. I've added it to my bookmarks for further browsing when I've got more time. FreeDCE has the plugins required to perform NTLM authenticated registry management. ... registry service, anyone? courtesy of wine's present code as a FreeDCE server? Sure, it is perfectly possible. The RPC registry functions are pretty much byte-for-byte compatible with the Win32 functions. I think the same is possible using our existing DCE/RPC implementation as a base though. Rob
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
Luke Kenneth Casson Leighton wrote: On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote: The only step left is for it to generate appropriate type format strings in the same format as Microsoft use. attached is an example from FreeDCE: samr.idl, with only one function in it for simplicity / demonstration purposes. you can compile the same IDL file with MSIDL.exe and compare the output. the expression format of what you refer to as "type format strings" that wez picked was for practicality purposes not for compatibility or interoperability with NT. This is the point. Anything which relys on that format is going to be of no use to us. I don't know how much of the codebase that represents. Sure, we can probably use other parts of the codebase like the different transports, as long as they don't depend on stuff like dcethreads, which is most likely incompatible with Wine. if you want to do _that_ you would be well advised to examine matthew chapman's "muddle" compiler. so i am also placing matthew chapman's "muddle 0.9.0" "un-IDL" compiler up on the same site as above. in it you will find a decoder that can understand the equivalent structures of samr_cstub.c above but in microsoft IDL format not DCE/RPC IDL format. Writing a decompiler and writing the actual functions to do the marshaling, unmarshaling and sizing are two different things. I have written an IDL decompiler myself (although it probably isn't anywhere near as good as muddle appears to be), so I know how to parse most of the data structures. The fun part is writing the correct data to the wire and writing test suites to confirm this. i hope that this helps you to appreciate that several man-years of effort may be shortcut by utilising this amazing piece of technology. putting it bluntly: don't waste this opportunity and don't waste this code. I do thank you for your concern, but I don't think you appreciate the effort in ripping code kicking and screaming and integrating it in into another project. 1. There are often a lot of dependencies, such as dcethreads, that one has to take into account. 2. The code could lack features that the Microsoft implementation exposes to clients. 3. If a Wine developer writes the code it is more likely to be maintained and we will have an expert to report problems to. I'll certainly look into re-using as much code as possible, but last time I looked it didn't look like it was worth the effort. Whatever the decision, it would be useful to have someone with your knowledge of the DCE/RPC protocol helping us with our implementation. We have re-used code from other projects in the past where the code was self-contained, such as here: http://cvs.winehq.org/cvsweb/wine/dlls/iccvid/iccvid.c?rev=1.6&content-type=text/x-cvsweb-markup So please don't think we are dead-set against reusing code and want to do it all ourselves. p.s. DCE/RPC even has acf files - just like MSRPC. it really _is_ the same code. I think you and I have different concepts of what the code means in this case. I think of the IDL and ACF files as the specification and the client/server code it generates as the actual code. The code generated by MIDL is not the same as that generated by the FreeDCE compiler. Rob
Re: MPR: remove netspi.h
Juan Lang wrote: For what reason, for documentation? Several of its declarations conflict with those in npapi.h, so it's potentially problematic. If it's not part of the PSDK, winelib users shouldn't need it to compile, or should expect to have to install the DDK if they need the prototypes, yes? To me, Wine feels like documentation of how Windows works, not just a rehash of the platform SDK. Removing documentation seems to be a step in the wrong direction. If somebody wanted to use netspi.h again (ie. for non-Wine purposes) they could just pull it from dlls/mpr, rather than extract the definitions from a C source file. If you think it's a better approach I can rename all the conflicting types, and document why the typenames don't match the expected ones. I'm not exactly sure why we need to rename the types... if we consider it a private include file, then problems only happen if we include another file with the same definitions, don't they? Mike
Re: [OLE #31] Dynamically Allocate the MTA
Le lun 17/01/2005 à 19:12, Robert Shearman a écrit : > Vincent Béron wrote: > > >Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : > > > > > >>Changelog: > >>- Make MTA dynamically allocated so that proxies and other resources are > >>freed at the proper time. > >>- Changed/removed some incorrect comments regarding apartments. > >> > >> > >> > >> > > > >This patch broke wineprefixcreate invocation for me. > > > >What happens is I get a: > >X Error of failed request: BadWindow (invalid Window parameter) > > Major opcode of failed request: 18 (X_ChangeProperty) > > Resource id in failed request: 0x77e61740 > > Serial number of failed request: 107 > > Current serial number in output stream: 114 > >error while wineprefixcreate runs "wine rundll32.exe > >setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". > > > >The error do go away if one of avifil32.dll or devenum.dll is commented > >out in [RegisterDllsSection] in wine.inf. > > > >My personal guess is that one (or both) of those dlls do something which > >they should not, and we end up with using freed or unallocated memory. > > > > > > I don't see the problem on my machine. Do the tests in dlls/ole32/tests > work for you? Not all of them (marshal: 107 tests executed, 0 marked as todo, 12 failures, moniker: 2 tests executed, 0 marked as todo, 1 failure, propvariant: 298 tests executed, 0 marked as todo, 0 failures, storage32: 89 tests executed, 0 marked as todo, 1 failure). > Is it possible to capture a +ole log for the wineprefixcreate invocation? > I'll do a review of the code paths that patch touches anyway, but I > don't see how it could affect things - devenum does not use MTAs and > avifil32 does not use COM. Since reaching the original conclusion yesterday, I'm able to have the same error with the 20050111 snapshot. So I don't think anymore that your patch was the problem (although at the time, a cvs updated at "Jan 12 19:27:00 2005 UTC" worked fine and one updated at "Jan 12 19:27:05 2005 UTC" caused the error). I guess some more work is needed on my part to clearly identify what's the problem (and it's cause). Vincent
Re: MPR: remove netspi.h
> I think it's probably better to move this file into dlls/mpr rather than > delete it altogether. Apparently it did exist in the Windows 98 DDK. For what reason, for documentation? Several of its declarations conflict with those in npapi.h, so it's potentially problematic. If it's not part of the PSDK, winelib users shouldn't need it to compile, or should expect to have to install the DDK if they need the prototypes, yes? If you think it's a better approach I can rename all the conflicting types, and document why the typenames don't match the expected ones. Even so, I'm not convinced a separate header file is preferable to moving the declarations to nps.c (the only user of these declarations.) --Juan __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
Re: MPR: remove netspi.h
Juan Lang wrote: ChangeLog: remove netspi.h, it had conflicting definitions with npapi.h and doesn't exist in the PSDK. Spotted by Paul Vriens. I think it's probably better to move this file into dlls/mpr rather than delete it altogether. Apparently it did exist in the Windows 98 DDK. Mike
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:
> A DCOM implementation is more than a header file
> containing a few comments and a few declarations of Win32 functions that
> are randomly placed in there.
perhaps it would be best for me to provide a reference to
something i found on The Open Group's site.
i assume that you (rob) are familiar with and aware of these
documents, but for the benefit of those people who are not
or might not be, i found these in some [accidental!] research
last week and tonight.
http://archive.opengroup.org/dce/meetings/july98/FrankHayes/index.htm
http://www.opengroup.org/comsource/
http://www.opengroup.org/pubs/catalog/ax01.htm
in the latter, you may obtain access to the online docs by agreeing
to TOG's access conditions.
in the latter, you fill find full information sufficient to implement
DCOM.
description of MSRPC, use of NTLM, the works.
note the heavy dependence on DCE/RPC.
one of the services required is a "Registry" and there is full
documentation on the registry API.
it is possible to recreate the winreg.idl file from this
documentation.
alternatively, you will find one already recreated by matty chapman's
"muddle" compiler, available from http://hands.com/~lkcl.
i am attaching it here for your convenience.
FreeDCE is capable of turning this into _useful_ NT-compatible code
FreeDCE has the plugins required to perform NTLM authenticated
registry management.
... registry service, anyone? courtesy of wine's present code as a
FreeDCE server?
according to the TOG docs, another service required is the
"secure service provider".
wow.
l.
/* Reconstructed by Matt Chapman <[EMAIL PROTECTED]> */
[ uuid(338cd001-2244-31f1--900038001003),
version(1.0),
implicit_handle(handle_t rpc_binding)
] interface winreg
{
/* Function 0x00 */
error_status_t RegOpenHKCR(
[in] [unique] wchar_t *server,
[in] long access,
[out] [context_handle] void **hnd
);
/* Function 0x01 */
error_status_t RegOpenHKCU(
[in] [unique] wchar_t *server,
[in] long access,
[out] [context_handle] void **hnd
);
/* Function 0x02 */
error_status_t RegOpenHKLM(
[in] [unique] wchar_t *server,
[in] long access,
[out] [context_handle] void **hnd
);
/* Function 0x03 */
error_status_t RegOpenHKPD(
[in] [unique] wchar_t *server,
[in] long access,
[out] [context_handle] void **hnd
);
/* Function 0x04 */
error_status_t RegOpenHKU(
[in] [unique] wchar_t *server,
[in] long access,
[out] [context_handle] void **hnd
);
/* Function 0x05 */
error_status_t RegClose(
[in,out] [context_handle] void **hnd
);
typedef struct {
short length;
short size;
[size_is(size/2)] [length_is(length/2)] [unique] short *string;
} UNICODE_STRING;
typedef struct {
[size_is(size)] [length_is(length)] [unique] char *buffer;
long size;
long length;
} BUFFER;
typedef struct {
long length;
BUFFER sec_desc;
char inherit;
} SECURITY_ATTRIBUTES;
/* Function 0x06 */
error_status_t RegCreateKey(
[in] [context_handle] void *hnd_parent,
[in] [ref] UNICODE_STRING *name,
[in] [ref] UNICODE_STRING *class,
[in] long reserved,
[in] long access,
[in] [unique] SECURITY_ATTRIBUTES *sec_info,
[out] [context_handle] void **hnd,
[in,out] [unique] long *disposition
);
/* Function 0x07 */
error_status_t RegDeleteKey(
[in] [context_handle] void *hnd,
[in] [ref] UNICODE_STRING *name
);
/* Function 0x08 */
error_status_t RegDeleteValue(
[in] [context_handle] void *hnd,
[in] [ref] UNICODE_STRING *name
);
typedef struct {
long low;
long high;
} NTTIME;
/* Function 0x09 */
error_status_t RegEnumKey(
[in] [context_handle] void *hnd,
[in] long index,
[in,out] [ref] UNICODE_STRING *name,
[in,out] [unique] UNICODE_STRING *class,
[in,out] [unique] NTTIME *mtime
);
/* Function 0x0a */
error_status_t RegEnumValue(
[in] [context_handle] void *hnd,
[in] long index,
[in,out] [ref] UNICODE_STRING *name,
[in,out] [unique] long *type,
[in,out] [size_is(*size+1)] [length_is(*length+1)] [unique] char *value,
[in,out] [unique] long *size,
[in,out] [unique] long *length
);
/* Function 0x0b */
error_status_t RegFlushKey(
[in] [context_handle] void *hnd
);
/* Function 0x0c */
error_status_t RegGetKeySecurity(
[in] [context_handle] void *hnd,
[in] long info_type,
[in,out] [ref] BUFFER *sec_info
);
/* Function 0x0d */
error_status_t RegLoadKey(
[in] [context_handle] void *hnd,
[in] [ref] UNICODE_STRING *subkey,
[in] [ref] UNICODE_STRING *file
);
/* Function 0x0e */
error_status_t RegNotifyChangeKeyValue(
[in] [
Re: WineTools
Le lun 17/01/2005 à 04:40, Joachim von Thadden a écrit :
> Hi,
>
> I am maintainer of the new WineTools package. As it is related on
> http://www.winehq.org/site/download under "3rd Party Tools" I want you
> do know that the text has to be changed, as Frank discontinued
> development for WineTools since a long time.
>
> The text should be now:
>
> WineTools is a menu driven installer for installing Windows programs
> under Linux written by Joachim von Thadden. This software lets you
> install the following Windows software: DCOM98, IE6, Windows Core Fonts,
> Windows System Software, Office & Office Viewer, Adobe Photoshop 7,
> Illustrator 9 and many other programs.
"Written by" or "maintained by"? I thought Frank wrote it in the
beginning...
>
> You can download WineTools here: http://www.von-thadden.de/Joachim/WineTools/
Some of the config files included in the "wt210jo" release look somewhat
out of date. The definition of drives in config has been dropped since a
couple of months, as well as the definition for the System, Temp, Path
and Profile environment variables, the ShellLinker key, the Resolution
key (in [fonts]), the serial and parallel ports keys, the
{Load,Write}HomeRegistryFiles keys, the WineLook key, and the
ClearAllSelections and PersistentSelection keys (in [Clipboard]).
Some of it is now handled in the registry, some in the .wine/dosdevices
dir.
Providing outdated stuff doesn't help Wine or it's users. Work on Wine
or winecfg (for easier configuration) would be preferred (I know this is
Free Software, so you work on what you like).
I'm not trying to dismiss WineTools, it's just that I'd much prefer
people working on improving the "real" thing rather than distribute
workarounds for a specific combination of Windows software and Wine
release.
Vincent
Re: Help debugging Fotowire
Mike Hearn wrote: On Mon, 17 Jan 2005 20:15:35 +0200, Antti MÃkelà wrote: If there is some easy way to get a bit more "verbose" view on what the program was exactly trying to do with the Calendarinfo call, that might be something I could at least *try* to patch up myself. At least if it's something simple. Your best bet is to put some ERR statements (so they are always printed) in the stub code itself. You're right, kernel32 functions are trickier to test, you need to install the mingw cross compiler (RPMs are available somewhere, I forget where) then cross-compile a test case that can be run on any random Windows box. But if you write the test to rely on that the test will fail on Win98. regards, Jakob
Re: tests
Well, you could find out why the quoted code snippet doesn't work on NT, and possibly suggest a better test... It was recommended by Dimitry, btw. (cc'd) I don't think I'll have time to do that any time soon :-( Ivan.
Re: [OLE #31] Dynamically Allocate the MTA
Vincent Béron wrote: Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : Changelog: - Make MTA dynamically allocated so that proxies and other resources are freed at the proper time. - Changed/removed some incorrect comments regarding apartments. This patch broke wineprefixcreate invocation for me. What happens is I get a: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x77e61740 Serial number of failed request: 107 Current serial number in output stream: 114 error while wineprefixcreate runs "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". The error do go away if one of avifil32.dll or devenum.dll is commented out in [RegisterDllsSection] in wine.inf. My personal guess is that one (or both) of those dlls do something which they should not, and we end up with using freed or unallocated memory. I don't see the problem on my machine. Do the tests in dlls/ole32/tests work for you? Is it possible to capture a +ole log for the wineprefixcreate invocation? I'll do a review of the code paths that patch touches anyway, but I don't see how it could affect things - devenum does not use MTAs and avifil32 does not use COM. Rob
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Mon, Jan 17, 2005 at 01:49:11PM -0800, Steven Edwards wrote: > Hi, > > --- Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > > _why_ are you duplicating the efforts of two separate free > > software projects? > > I have been scratching my head trying to figure out a way that Samba, > Samba-Tng, ReactOS, FreeDCE > and Wine can all work together on some of these projects. I don't know much > if anything about > DCE/RPC so I can only guess that all of the existing free implementations > were either > A) not suited for Wine by design. ... that's definitely not the case [except in samba, that is: i have made _too_ much of an effort to persuade them of exactly what you have been scratching your head over] > or > > B) there were license issues. _that's_ not the case! allow me to explain. DCE 1.1 is OSF 1.0 "BSD-compatible" license. FreeDCE is the same except for its threading library, and that's self-contained and "wrapped". [i.e. it doesn't actually link against the code, it "replaces" the posix threading library functions and "over-rides" them using Versioning] i know - it's a semantics issue, and if it _really_ bothers you [singular, plural, whatever], it's < 10k lines of code and could easily be rewritten by somebody like loic (hello loic). > Option B was the case of Wine developing its own IDL compiler and some of the > SMB support > implemented in Wine. Samba being GPL caused quite a bit of a problem for us. yes, and i talked to rms about it, for advice, and he said basically "tough"!!! he believes the LGPL to have, in hindsight, to have been a mistake, for free software. i understand where he is coming from on this, and there exists a clause that _could_ be evoked in Wine to turn the entire code into GPL - but that's rather extreme and unnecessary [i believe] now DCE 1.2.2 is LGPL'd - so there's no problem there. additionally, the people who worked on it [adding DCOM, NTLMSSP, GSS-API] have pretty much worked on it on their own, they are _few_ in number, therefore they own the code, and can choose how to license it - GPL, LGPL. my samba code is now actually public domain what i am saying is that you will have to speak nicely to Wez if you want LGPL'd versions of his DCOM code [to go from FreeDCE into DCE 1.2.2] _plus_ the GSS-API stuff and NTLMSSP stuff is all behind ".so" interfaces, the header files of which are BSD licensed. so even if those components remain GPL, it's okay, because they are .so's loaded at runtime by a BSD licensed bit of code (nyah ha hah hr) yes, it's a bit messy, but it is only messy because this is from several projects who haven't been working together or collaborating to achieve something faster than they can on their own. so there exists an opportunity to save an awful lot of time. and people are, 'scuse my french, dicking about running their "not invented here" psycho syndromes about how clever their open source project and how _they_ own all the code, is instead of realising that this is just way too big for one team to take on, and just getting on with it. so DON'T WASTE IT. thank you. l.
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:
> We already have our own IDL parser.
you have an IDL parser and that is only about 10% of the work required.
> The only step left is for it to
> generate appropriate type format strings in the same format as Microsoft
> use.
attached is an example from FreeDCE: samr.idl, with only one function
in it for simplicity / demonstration purposes.
you can compile the same IDL file with MSIDL.exe and compare the
output.
i do not know what the equivalent argument to dceidl -cstub is which
asks the DCE IDL compiler to keep the intermediate c code: if MSIDL
does not have that then obviously you will need to examine the
if you use the MSVC 4.X studio MSIDL compiler you will find
that what you describe as type format strings will be virtually
identical to the attached samr_cstub.c code.
i hassled and harried microsoft enough for them to do an almost
total rewrite of NT 5's DCE/RPC compiler: i therefore cannot
reliably inform you as to whether the type format strings
are the same for the compiler used on NT 5.0.
you will need the FreeDCE latest cvs and you will also need the patches
that can be found on http://hands.com/~lkcl.
these patches integrate Wez's work which he did in 2000 including
adding "expressions" into the IDL syntax (which you will note is
missing from DCE 1.2.2 and 1.1) and also "implicit" handles.
so it is possible to do complex expressions such as length_is(len * 2 -
1) and, as i understand it to be more essential to DCOM, size_is((len +
7) & ~0x7) - things like that.
wez focussed on this critical work in order to properly support DCOM
formats on-wire, and the reason it only took him a couple of months is
because of the incredibly well-designed FreeDCE code.
the expression format of what you refer to as "type format strings"
that wez picked was for practicality purposes not for compatibility or
interoperability with NT.
if you want to do _that_ you would be well advised to examine matthew
chapman's "muddle" compiler.
so i am also placing matthew chapman's "muddle 0.9.0" "un-IDL"
compiler up on the same site as above.
in it you will find a decoder that can understand the equivalent
structures of samr_cstub.c above but in microsoft IDL format not
DCE/RPC IDL format.
i hope that this helps you to appreciate that several man-years of
effort may be shortcut by utilising this amazing piece of technology.
putting it bluntly: don't waste this opportunity and don't waste this
code.
thank you,
l.
p.s. DCE/RPC even has acf files - just like MSRPC. it really _is_ the
same code.
[ uuid(12345778-1234-abcd-ef00-0123456789ac),
version(1.0),
pointer_default(unique)
] interface samr
{
const long MAX_SIZE = 1000;
typedef [context_handle] void *connect_hnd_t;
typedef [context_handle] void *domain_hnd_t;
typedef [context_handle] void *user_hnd_t;
typedef [context_handle] void *group_hnd_t;
typedef [context_handle] void *alias_hnd_t;
typedef [context_handle] void *obj_hnd_t;
typedef [context_handle] void *unknown_hnd_t;
/* Function 0x00 */
long SamrConnect(
[in] handle_t h ,
[in] unsigned short server,
[out] connect_hnd_t *hnd,
[in] long access
);
}
interface samr {
}
/* Generated by IDL compiler version FreeDCE 1.1.0.7 with GNU Flex/Bison */
#ifdef VMS
#pragma nostandard
#endif
#include
#include
static rpc_syntax_id_t IDL_transfer_syntaxes[1] = {
{
{0x8a885d04u, 0x1ceb, 0x11c9, 0x9f, 0xe8, {0x8, 0x0, 0x2b, 0x10, 0x48, 0x60}},
2}};
static rpc_if_rep_t IDL_ifspec = {
1, /* ifspec rep version */
1, /* op count */
1, /* if version */
{0x12345778u, 0x1234, 0xabcd, 0xef, 0x00, {0x1, 0x23, 0x45, 0x67, 0x89, 0xac}},
2, /* stub/rt if version */
{0, NULL}, /* endpoint vector */
{1, IDL_transfer_syntaxes} /* syntax vector */
};
/* global */ rpc_if_handle_t samr_v1_0_c_ifspec = (rpc_if_handle_t)&IDL_ifspec;
static idl_ulong_int IDL_offset_vec[] = {
0,
0
};
static IDL_rtn_func_t IDL_rtn_vec[] = {
(IDL_rtn_func_t)NULL,
(IDL_rtn_func_t)NULL
};
static idl_byte IDL_type_vec[] = {
0xff,0xff,0xff,0xff,
1,
0,
0xff,0xff,
0x03,0x00,
0x02,0x00,
0x01,0x00,
0x00,0x00,
0x78,0x57,0x34,0x12,
0x34,0x12,
0xcd,0xab,
0xef,
0x00,
0x01,0x23,0x45,0x67,0x89,0xac,
0x00,0x00,0x00,0x00,
0x04,0x00,0x00,0x00,
0x78,0x00,0x00,0x00,
0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,
0x01,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,
0x05,0x00,0x00,0x00,
0x02,0x00,0x00,0x00,
0x58,0x00,0x00,0x00,
0x02,0x00,0x00,0x00,
0x68,0x00,0x00,0x00,
0x02,0x00,0x00,0x00,
IDL_DT_USHORT,
IDL_DT_EOL,
0xff,0xff,
0x04,0x00,0x00,0x00,
IDL_DT_LONG,
IDL_DT_EOL,
0xff,0xff,
0x03,0x00,0x00,0x00,
IDL_DT_PASSED_BY_REF,
IDL_DT_OUT_CONTEXT,
IDL_DT_EOL,
0xff,
0x00,0x00,0x00,0x00,
IDL_DT_LONG,
IDL_DT_EOL,
0xff,0xff,
0x10,0x00,0x00,0x00,
0
};
idl_long_int SamrConnect
#ifdef IDL_PROTOTYPES
(
/* [in] */ handle_t h,
/* [in] */ idl_ushort_int server,
/*
Re: Which QueryInterface is called?
On Mon, 17 Jan 2005 14:33:13 -0800, Bill Medland wrote: > 'Fraid not. See attached. I added the corresponding traces just to confirm > that I was actually executing the modified code. > As you can see, it located, connected and constructed. Could you do a +ole,+tid,+olerelay trace please?
Re: Help debugging Fotowire
On Mon, 17 Jan 2005 20:15:35 +0200, Antti MÃkelà wrote: > If there is some easy way to get a bit more "verbose" view on what the > program was exactly trying to do with the Calendarinfo call, that might be > something I could at least *try* to patch up myself. At least if it's > something simple. Your best bet is to put some ERR statements (so they are always printed) in the stub code itself. You're right, kernel32 functions are trickier to test, you need to install the mingw cross compiler (RPMs are available somewhere, I forget where) then cross-compile a test case that can be run on any random Windows box. thanks -mike
Re: [AppDB] new screenshot and image classes
The live server doesn't have GD, can you do something about it Paul (imagemagick or GD 1.x) ? If yes, can you resend when fixed: 1)My thumbs.php script Objet: Re: [AppDB] new screenshot and image classes Date: Sun, 16 Jan 2005 21:39:03 +0100 2) The patch Objet: [AppDB] fixed: new screenshot and image classes Date: Sun, 16 Jan 2005 21:36:15 +0100 I'd gladly do it myself but I think you are much more experienced than me regarding image manipulation. FYI Here is the IRC log: (23:15:49) laxdragon: jernst: no joy, in order to support GD 2.0, I will need to rebuild php. I'm not willing to do that at the moment. (23:16:17) laxdragon: damn red hat 9 is s out of date. (23:33:02) jernst: laxdragon: to rebuild php I just do emerge php ;-). (23:33:18) jernst: laxdragon: so what's the solution now ? do we use crappy resizing functions ? (23:33:25) jernst: laxdragon: do you have imagemagick instead ? (23:34:10) laxdragon: jernst: if this were debian it wouldn't have been a problem ayway. We set this up with Red Hat back when we though using a red hat support contract was a good idea. (23:34:29) laxdragon: jernst: yes, that is installed. (23:35:04) jernst: laxdragon: when you say you don't want to make that at the moment, it means you won't do it anytime soon ? Or you mean you'll do it later this month ? (23:35:51) laxdragon: jernst: I have plans to swith the server over to debian, but until then, I'm not doing any major changes on that box. (23:36:07) jernst: laxdragon: ok I'll ask Polleke if he can rewrite his image functions using either GD 1 or imagemagick (23:36:12) laxdragon: this is why I want WineHQ on its own box, I don't have time to do this right now. (23:36:43) laxdragon: if it didn't effect the codeweavers site, I wouldn't care. signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Help debugging Fotowire
On Monday 17 January 2005 20:00, Mike Hearn wrote: > I'm not sure. Your best bet is to try calling the functions in your own > mini test programs in the same way that Fotowire does until you find > something that doesn't work right. Well, that's not something I probably can do as I don't have *any* experience regarding Win32 system calls. Nor do I really have any tools to conduct such testing..All I really have is a non-working application and I was hoping that with the right debug options the problem could be solved. But what I understand from the errors is that GetCalendarinfo functions are not fully implemented (ie. that's why they are called stubs, right?), and return something like zero as a result. I got that error with 20041201 even without using the native oleaut32. Now I need the native oleaut32 to get that far (so maybe the builtin oleaut32 somehow got broken between releases?). Anyhow, the real problem is still with the CalendarInfo's as I hardly cannot replace the kernel32 with native one... (or can I, at least partially?) If there is some easy way to get a bit more "verbose" view on what the program was exactly trying to do with the Calendarinfo call, that might be something I could at least *try* to patch up myself. At least if it's something simple. Thanks for trying, anyway.. -- - Antti Mäkelä - http://www.cs.tut.fi/~zarhan - There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here,it will instantly disappear and be replaced by something even more bizarre and inexplicable.
Re: Which QueryInterface is called?
On January 17, 2005 01:36 pm, Mike Hearn wrote:
> I think Robs theory is right, but IMHO we need more tracing in this part
> of the code anyway. Try applying this patch and resending the log.
>
> I suspect you'll get
>
> err:proxy_manager_create_ifproxy: Could not locate PSFactoryBuffer for IID
> {---C000-0046}
>
> But let's find out.
>
> thanks -mike
'Fraid not. See attached. I added the corresponding traces just to confirm
that I was actually executing the modified code.
As you can see, it located, connected and constructed.
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:CoGetClassObject
CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46},
IID:{0001---c000-0046}
0009:warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
not registered inproc
0009:trace:ole:create_marshalled_proxy
rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46},
iid={0001---c000-0046}
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_server activating local server
'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for
{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0012:trace:ole:DllMain 0x55 0x1 0x1
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2
0012:trace:ole:DllMain (0x6e,1,0x1)
0012:trace:ole:CoInitializeEx ((nil), 2)
0012:trace:ole:CoInitializeEx () - Initializing the COM libraries
0012:trace:ole:RunningObjectTableImpl_Initialize ()
0012:trace:ole:COM_CreateApartment creating new apartment, model=2
0012:trace:ole:COM_CreateApartment Created apartment on OXID 110012
0012:trace:ole:WINE_StringFromCLSID
0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA}
0012:trace:ole:CoRegisterClassObject
({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x40570180,0x0004,0x0001,0x41f094)
0012:trace:ole:CoMarshalInterface (0x40058e50,
{0001---c000-0046}, 0x40570180, 0, (nil), 1)
0012:trace:ole:CoGetStandardMarshal
({0001---c000-0046},0x40570180,0,(nil),1,0x52fd60)
0012:trace:ole:CoMarshalInterface Using standard marshaling
0012:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace
0012:trace:ole:StdMarshalImpl_MarshalInterface
(...,{0001---c000-0046},...)
0012:trace:ole:start_apartment_listener_thread apt->listenertid=0
0014:trace:ole:apartment_listener_thread Apartment listener thread starting on
(\\.\pipe\WINE_OLE_StubMgr_00110012)
0012:trace:ole:CoGetPSClsid () riid={0001---c000-0046},
pclsid=0x52fcf4
0012:trace:ole:WINE_StringFromCLSID
0x594170->{0001---C000-0046}
0012:trace:ole:__CLSIDFromStringA {0320---C000-0046} ->
0x52fcf4
0012:trace:ole:CoGetPSClsid () Returning
CLSID={0320---c000-0046}
0012:trace:ole:WINE_StringFromCLSID
0x52fcf4->{0320---C000-0046}
0012:trace:ole:CoGetClassObject
CLSID: {0320---c000-0046},
IID:{d5f569d0-593b-101a-b569-08002b2dbf7a}
0012:trace:ole:COMPOBJ_DLLList_Add
0012:trace:ole:PSFacBuf_CreateStub
({0001---c000-0046},0x40570180,0x52fcec)
0012:fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented
0012:trace:ole:get_stub_manager_from_object not found for object 0x40570180
0012:trace:ole:register_ifstub constructing new stub manager
0012:trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x40058c20
for object with IUnknown 0x40570180
0012:trace:ole:stub_manager_new_ifstub oid=1, stubbuffer=0x40058f10,
iptr=0x40570180, iid={0001---c000-0046},
tablemarshal=TRUE
0012:trace:ole:stub_manager_int_release after 1
0015:trace:ole:local_server_thread Starting threader for
{b6b35894-dd6f-11d3-84ac-00c04f0e1b46}.
0015:trace:ole:WINE_StringFromCLSID
0x40058e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0015:trace:ole:local_server_thread marshalling IClassFactory to client
0009:trace:ole:create_marshalled_proxy read marshal id from pipe
0009:trace:ole:create_marshalled_proxy unmarshalling classfactory
0009:trace:ole:CoUnmarshalInterface (0x4009e788,
{0001---c000-0046}, 0x1ea4f4dc)
0009:trace:ole:get_unmarshaler_from_stream Using standard unmarshaling
0009:trace:ole:StdMarshalImpl_UnmarshalInterface
(...,{0001---c000-0046},)
0009:trace:ole:CoGetPSClsid () riid={0001---c000-0046},
pclsid=0x1ea4ef84
0009:t
Re: Question about testing SHQueryValueExA in shlwapi/tests/shreg.c
On Mon, 17 Jan 2005 23:05:59 +0100, Paul Vriens wrote: > Wine and Win98 leave the buffer intact (the contents and thus size > differ however) > WinXPProf and W2KProf clear (so it seems) the buffer. That's why it's tested - MSDN is useful but not what we care about. You can guarantee if NT clears the buffer, somebody somewhere will have written an app which relies on it (or vice-versa).
Question about testing SHQueryValueExA in shlwapi/tests/shreg.c
Hi, I'm trying to fix the tests in shlwapi/tests/shreg.c (or Wine for that matter). One thing that puzzles me in the current code is the checks done after we receive a ERROR_MORE_DATA when we pass a size smaller than the actual data. MSDN states: If the buffer specified by pvData parameter is not large enough to hold the data, the function returns ERROR_MORE_DATA and stores the required buffer size in the variable pointed to by pcbData. In this case, the contents of the pvData buffer are undefined. If that's the case, what's the use of checking the returned buffer with something? Wine and Win98 leave the buffer intact (the contents and thus size differ however) WinXPProf and W2KProf clear (so it seems) the buffer. Cheers, Paul Vriens.
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
Hi, --- Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > _why_ are you duplicating the efforts of two separate free > software projects? I have been scratching my head trying to figure out a way that Samba, Samba-Tng, ReactOS, FreeDCE and Wine can all work together on some of these projects. I don't know much if anything about DCE/RPC so I can only guess that all of the existing free implementations were either A) not suited for Wine by design. or B) there were license issues. Option B was the case of Wine developing its own IDL compiler and some of the SMB support implemented in Wine. Samba being GPL caused quite a bit of a problem for us. Thanks Steven __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, Jan 16, 2005 at 05:44:26PM -0500, Wez Furlong wrote: > I've been distant from DCE for a little while, so I don't have all the > details at the tip of my brain. > > Luke isn't quite correct, but is mostly correct :-) burblburble never truer... > FreeDCE doesn't contain a working DCOM implementation. ah - i wasn't aware of that. > The following > areas need(ed) some work for that: > > 1/ NTLMSSP (which we now have in freedce, thanks to Luke) and GSS-API thanks to luke howard [although it's not needed for DCOM] > 2/ The rpcd/endpoint mapper needs awareness of ORPC and implement one or > two ORPC specific services in order to maintain the lifetime of remotely > activated components. which jelmer of the samba team is aware of because he has _also_ started implementing DCOM. > 3/ The IDL compiler and marshalling stubs need awareness of ORPC > 4/ On top of that, the local COM library needs to be implemented > Filling out these areas is *massively less work* than re-implementing > DCE-RPC; I made a fair start on (2) and (3) 4 years ago, but lack of > interest from the world at large (and a need to pay my bills) caused it > to be put on hold. thank you for filling in the areas in which my knowledge was hazy about what was involved. > Please believe me when I say that there is a large amount of non-trivial > code in there; I have huge respect for the people that wrote it and the > amount of time that it took to get it there. Don't forget that this is > production quality code that has been used by huge players for years. ibm, dec, fujitsu, entegrity, arthur anderson, HP - about the only people who _haven't_ really used it are sun microsystems because they are known to always chase after money, taking people off projects and putting them on others - so nobody in their right mind would consider awarding them a $500m contract. > I > pity anyone that would think of taking on the task of re-implementing > it, not because it's nasty but because it's a *huge* effort. > > While I can't commit development time right at this moment (I'm booked > up with the PHP project in most of my "free" time), I am happy to help > in any other way that I can; I researched the implementation of DCOM > quite heavily back then, so I probably have a better idea than most > about getting it done. > > --Wez. > > PS: I'd *love* to have someone sponsor my employer (omniti.com) to have > me work on getting this implemented. > > Luke Kenneth Casson Leighton wrote: > >>I already checked out FreeDCE and the newly released DCE-RPC several days > >>ago. Neither provides a DCOM implementation, neither resembles what we > >>need. We may be able to take some code or ideas from them with some work > >>to massage it, but there's not much of use there. > > > > > >dear mike, > > > >you are correct about DCE 1.2.2 not containing DCOM: it is > >FreeDCE that does. > > > >other than that - with all due respect, and if i understand > >you correctly: you are wrong [or looking in the wrong place] > > > >e see this: > > > > > > http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/dcom/dcom.h?rev=1.1&view=markup > > > >which has been available for just over four years, now. > > > > > >are you _seriously_ intending to reimplement the DCE/RPC IDL > >compiler - because that's what's required!!! > > > >DCOM is DCE/RPC underneath: DCOM even has the uuids and > >transports of DCE/RPC. DCOM is just a c++ wrapper on top of > >some underlying c APIs, and from what i can gather, you "up" > >the revision numbers of the interfaces, which DCE/RPC can even > >do for you. > > > >perhaps i should put you in touch with wez furlong who did > >the original FreeDCE DCOM work. > > > >you _cannot_ be serious about reinventing the 250,000 lines > >of c code required to properly support DCE/RPC which is a > >prerequisite for supporting DCOM. > > > >i can understand the samba team doing that, but _another_ > >project doing it??? > > > >please tell me i am wrong in believing that you are giving > >serious consideration to a _third_ DCE/RPC runtime and > >development environment, to compete with samba 4's GPL'd > >implementation which is in development and with FreeDCE's > >complete reference implementation which is available under an > >OSF 1.0 BSD-like license. > > > >l. > > > -- -- http://lkcl.net";>http://lkcl.net --
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote: > We already have our own IDL parser. The only step left is for it to > generate appropriate type format strings in the same format as Microsoft > use. i believe i know what you are referring to: matthew chapman wrote a reverser which looked for the state table, looking for the uuid and then offsetting from that in order to decode the state table _back_ into an IDL file - without of course the function names and variable and structure names. FreeDCE's IDL compiler has almost EXACTLY the same state table. why? because FreeDCE is the DCE 1.1 reference implementation which is available and has been available for approx ten years under the OSF 1.0 BSD-compatible license, so _guess_ where microsoft got their IDL compiler from? :) believe me when i say that duplicating this code is just... nuts when it already exists. l.
WineConf 2005: details
WHAT: WineConf 2005 WHEN: April 30 - May 1, 2005 WHERE: Institute of Communication Networks and Computer Engineering Stuttgart-Vaihingen Campus University of Stuttgart WHO: Anyone interested in Wine development. Please note: is a developers-only conference. HOW: Check out WineHQ for travel details. We still have quite a lot to work out, including the actual agenda, but we'll update these web pages as more info becomes available: http://www.winehq.org/site/wineconf If you plan on attending, please register on the website using the RSVP form as soon as possible. You can also find details on there about the wineconf mailing list. At this point there's a lot of planning that remains, so you'll have to bear with us as that discussion occurs. For those of you interested in Samba development, you might want to check out the SambaXP conference (http://www.sambaxp.org) since it's going to occur the two days following WineConf. WineConf 2004 was a lot of fun and I hope everyone can make it again. With a little luck we'll be able to attract everyone who couldn't make it to balmy, breezy Minneapolis last year. -Brian
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Mon, 17 Jan 2005 21:23:21 +, Luke Kenneth Casson Leighton wrote: > you do realise that you are duplicating a project that already exists > (FreeDCE) which is a BSD implementation > > ... and you do also realise that you are also working, albeit from a > different angle, on exactly the same thing that the samba 4 project is > duplicating? As Rob has pointed out, we're not duplicating anything as the code we need does not exist. There is no NIH syndrome here: if you can point to a LGPL or BSD/X11 licensed implementation of OLE32, OLEAUT32 and things like CreateProxyFromTypeInfo then we'd be very interested. The only one we do know of is in Cedega and we already used quite a lot of code from that. As it is, the DCE-RPC code already in Wine CVS is more than enough for now. If we need to extend it later using code from FreeDCE may be possible, but right now we : a) Don't know of *any* pure DCE-RPC applications people want to run b) Have a DCOM implementation that does not use RPC (b) will change at some point, however most programs out there today do not use the NDR marshallers or DCE-RPC APIs, instead they use MOP opcode strings or the universal marshaller which generates proxies on the fly from type databases. So there's still a lot to implement outside of the core RPC API, the capabilities of which just aren't used that heavily in Windows. So to recap: - FreeDCE implements DCE-RPC better than we do, but we don't care because we don't actually use our current RPC code yet, and when we do it won't be stressing the current capabilities. The capabilities that *will* be needed from our RPC runtime aren't implemented by any pre-existing project as they are Microsoft-specific extensions to the API - Samba4 is focussed only on wire compatibility, but not binary API compatibility. Right now we don't care much about wire compat, and won't for many years. They do not implement much code we care about, that which we do care about (things like the OXID Resolver) are not hard to write. Even so we have a dialog open with them on code sharing. Just to make this point perfectly clear *WE ARE WRITING CODE THAT DOES NOT EXIST ELSEWHERE*. The closest implementation of DCOM we need can be found in TransGamings Cedega, and we're using bits of their code already. Oh finally, I'd note that Rob and I learned most of what we know about DCOM when we were students, working as volunteers. "Lack of funding" has nothing to do with anything. You can learn about DCOM very cheaply, my biggest expense has been $40 or so for Essential COM by Don Box, an excellent book that I recommend. thanks -mike
Re: WineHQ:winetest: produce valid HTML
On Monday 17 January 2005 11:30, Ferenc Wagner wrote: > Jakob Eriksson <[EMAIL PROTECTED]> writes: > > I would prefer to have all failed tests at the top, so one > > could see easily which ones need to be fixed. > > Not being an addition but a change, I'd like to hear others' > opinion on this matter. My personal feeling is that losing > alphabetical ordering on test names isn't worth it, as color > monitors are fairly common nowadays. So vote for the change! I'd vote for tests staying in the same relative position from run to run (be that alphabetical or whatever). > > It would also be nice if the author of a test got an email > > whenever a test failed. > > Finding out the author of a test isn't easy, it requires > some digging into CVS. On the other hand, I'd choose an > opt-in method instead. But it's a separate project anyway, > the present machinery has pretty much nothing to facilitate > this. The summary.txt files are easy to parse and available > by HTTP, so one could use them to get the figures. One possibility is to send an email to the wine-devel list when something breaks (but only the one!). There were mixed reactions to this, for WRT, so I filtered all the emails and double-checked before forwarding them. Paul. pgpzevwbAydWR.pgp Description: PGP signature
Re: Which QueryInterface is called?
I think Robs theory is right, but IMHO we need more tracing in this part
of the code anyway. Try applying this patch and resending the log.
I suspect you'll get
err:proxy_manager_create_ifproxy: Could not locate PSFactoryBuffer for IID
{---C000-0046}
But let's find out.
thanks -mike
--- dlls/ole32/marshal.c (revision 108)
+++ dlls/ole32/marshal.c (local)
@@ -350,13 +350,21 @@ static HRESULT proxy_manager_create_ifpr
&ifproxy->proxy, &ifproxy->iface);
IPSFactoryBuffer_Release(psfb);
}
+else
+ERR("Could not locate PSFactoryBuffer for iid %s\n",
debugstr_guid(riid));
if (hr == S_OK)
+{
hr = IRpcProxyBuffer_Connect(ifproxy->proxy, This->chan);
+if (FAILED(hr)) ERR("Could not connect ifproxy to RPC channel\n");
+}
/* get at least one external reference to the object to keep it alive */
if (hr == S_OK)
+{
hr = ifproxy_get_public_ref(ifproxy);
+if (FAILED(hr)) ERR("Could not get public ref on ifproxy\n");
+}
if (hr == S_OK)
{
@@ -369,6 +377,8 @@ static HRESULT proxy_manager_create_ifpr
else
ifproxy_destroy(ifproxy);
+if (FAILED(hr)) ERR("PANIC: ifproxy construction failed, expect failure
now ...\n");
+
return hr;
}
Re: Debugging mingw applications using wine
> In that case, what is "winedbg --gdb" for? Why have this option if no GDB supports it? because it targets different stuff: winedbg (standalone) is able to load and use debug info from: - ELF modules (exec and shared libs) (with stabs info, dwarf2 isn't supported). As wine DLLs are implemented on top of ELF shared libs, this also includes wine builtin DLLs (Wine forces stabs as its debug info, even on newest version of gcc where dwarf2 is the default) - PE modules (native Win32 compilation), compiled with either MSVC or Mingw. Note that Mingw stores its debug information as stabs (same as ELF), but the way to get to the stabs information from an ELF or a PE module is different (as this information is referenced from the ELF (resp. PE) headers) gdb on Linux (it's also what you get with winedbg --gdb) is able (out of the box) to handle the ELF modules as explained above (it also handles dwarf2, with can be handy in some cases), but doesn't know on how to get stabs info from PE modules even if it knows how to handle stabs debug format. However, Mingw port of gdb on Win32 includes this support. Maybe Mingw's gdb port might be an alternative for you (but 1/ I never tested it, so it may even not work, 2/ won't give you access to debug information for the ELF modules). A+ -- Eric Pouech
Re: Running dxdiag
Dumping the headers is necessary for stupid installers that map DLL files manually and rummage around in the headers to figure out versions and stuff ... simply having an empty file isn't enough for all of them I'm afraid :( I have some basic stuff for this (which I wrote for some other reasons quite long ago - support of debug information), so if someone is interested, drop me a note. A+ -- Eric Pouech
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote: > Luke Kenneth Casson Leighton wrote: > > >>I already checked out FreeDCE and the newly released DCE-RPC several days > >>ago. Neither provides a DCOM implementation, neither resembles what we > >>need. We may be able to take some code or ideas from them with some work > >>to massage it, but there's not much of use there. > >> > >> > > > >dear mike, > > > >you are correct about DCE 1.2.2 not containing DCOM: it is > >FreeDCE that does. > > > >other than that - with all due respect, and if i understand > >you correctly: you are wrong [or looking in the wrong place] > > > >see this: > > > > > > http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/dcom/dcom.h?rev=1.1&view=markup > > > >which has been available for just over four years, now. > > > > > > I hope you're joking. lacking expertise due to lack of funding and sponsorship is a more accurate picture. > A DCOM implementation is more than a header file > containing a few comments and a few declarations of Win32 functions that > are randomly placed in there. i appreciate this. > >are you _seriously_ intending to reimplement the DCE/RPC IDL > >compiler - because that's what's required!!! > > > > > > We already have our own IDL parser. The only step left is for it to > generate appropriate type format strings in the same format as Microsoft > use. the dce idl compiler consists of 70,000 lines of highly complex code, 20,000 of which is the data handling code. > >DCOM is DCE/RPC underneath: DCOM even has the uuids and > >transports of DCE/RPC. > > > > We know. fantastic. > > DCOM is just a c++ wrapper on top of > >some underlying c APIs, > > > > No, it is an object oriented wrapper for normal RPC interfaces where a > state parameter representing the object is implicitly passed to the > function. > It has nothing to do with the language. my apologies for being too brief and simplistic in an area where there are people who have more expertise, time and funding than i have. > > >and from what i can gather, you "up" > >the revision numbers of the interfaces, which DCE/RPC can even > >do for you. > > > > > > No. DCOM interfaces always have a version number of 0.0. To create > extend an interface you must create a new interface. Microsoft typically > appends a number to the interface name and makes the new one inherit > from the old one. I suggest you take a few minutes to read the DCOM > draft specification, which should clear up a few misconceptions. it has been a long time since i actually programmed with COM objects: MSVC 4.3 to be precise, in about 1994. once again i apologise for my memory on these issues being rusty in an area where you have more expertise than i. my main concern in mentioning the capabilities of FreeDCE are in an effort to save you effort. > >perhaps i should put you in touch with wez furlong who did > >the original FreeDCE DCOM work. > > > > > > What DCOM work? i will let wez answer this one, if he is amenable. > >you _cannot_ be serious about reinventing the 250,000 lines > >of c code required to properly support DCE/RPC which is a > >prerequisite for supporting DCOM. > > > > > > I think you're over estimating by a factor of 2.5 there. Sure, it is a > large undertaking, but one that we can do one step at a time. We don't > have to implement *every* protocol to start with and we don't have to > implement every Ndr data type. if you used FreeDCE you would not need to implement any. you do realise that you are duplicating a project that already exists (FreeDCE) which is a BSD implementation ... and you do also realise that you are also working, albeit from a different angle, on exactly the same thing that the samba 4 project is duplicating? i find this alternately hilarious and frustrating and on balance am quite torn about actually telling you in case you get offended about being told that you are doing a "not invented here" syndrome or something. please: i am genuinely curious and seek enlightenment on this issue: _why_ are you duplicating the efforts of two separate free software projects? > >i can understand the samba team doing that, but _another_ > >project doing it??? > > > >please tell me i am wrong in believing that you are giving > >serious consideration to a _third_ DCE/RPC runtime and > >development environment, to compete with samba 4's GPL'd > >implementation which is in development and with FreeDCE's > >complete reference implementation which is available under an > >OSF 1.0 BSD-like license. > > > > > > No other project has implemented an API that is compatible to > Microsoft's yet. the area that i understand in particular detail is the DCE/RPC side of things, and i can say from experience that the capability of the DCE/RPC side of FreeDCE is outstanding the area which i am not entirely familiar with is the DCOM side, and you have the knowledge and expert
Re: WineHQ:winetest: produce valid HTML
On Mon, Jan 17, 2005 at 03:05:09PM +0100, Jakob Eriksson wrote: > But if I were to implement an opt-in scheme, you would be ok with it? I wouldn't be opposed to it, but I'd advice against expanding so much effort for such little benefit. We have so much to do, it's not like we're looking for stuff to kill time :) -- Dimi.
Re: Exiting a tests on the first failure
Paul Vriens <[EMAIL PROTECTED]> writes: > is it OK that have the above in a patch anyway, along with some extra > debugging output? I will try and find a key we can use, but one problem > could be that the failures are related to security (that's why I want to > have the extra output as well). We want more than extra debugging output, we really want the test to fail so that someone looks into it. We can't just pretend that everything is fine if we actually didn't run any test at all. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Which QueryInterface is called?
Bill Medland wrote: (Mike? Robert?,) I am trying to understand what is failing in a piece of -out-of-process COM under Wine. Basically it is an ATL-based CreateInstance that is returning E_NOINTERFACE under Wine. Below is a cut-down copy of the trace. What I don't understand is which QueryInterface is being called. I don't totally understand what is going on in the marshalling etc. but from what I can see I expected to see ClientIdentity_QueryRef called and some sort of marshalling going on in the last stages. Can anyone point me at which code is probably implementing the QueryInterface? Basic code: rclsid = __uuidof(ACCPACSignonMgr) CoCreateInstance (rclsid, NULL, CLSCTX_ALL, __uuidof(IUnknown), &pIUnknown); OleRun (pIUnknown) pIUnknown->QueryInterface (getIID(), &m_pInterface) pIUnknown->Release Problem: pIUnknown->QueryInterface returns E_NOINTERFACE The interface is provided by a an object running in a local server Why don't I see a trace on ClientIdentity_QueryInterface? I think we need to special-case IID_IUnknown in StdMarshalImpl_UnmarshalInterface to just create a proxy and not try to get the IRpcProxyBuffer for the interface. Rob
Which QueryInterface is called?
(Mike? Robert?,)
I am trying to understand what is failing in a piece of -out-of-process COM
under Wine. Basically it is an ATL-based CreateInstance that is returning
E_NOINTERFACE under Wine.
Below is a cut-down copy of the trace.
What I don't understand is which QueryInterface is being called. I don't
totally understand what is going on in the marshalling etc. but from what I
can see I expected to see ClientIdentity_QueryRef called and some sort of
marshalling going on in the last stages.
Can anyone point me at which code is probably implementing the QueryInterface?
Basic code:
rclsid = __uuidof(ACCPACSignonMgr)
CoCreateInstance (rclsid, NULL, CLSCTX_ALL, __uuidof(IUnknown), &pIUnknown);
OleRun (pIUnknown)
pIUnknown->QueryInterface (getIID(), &m_pInterface)
pIUnknown->Release
Problem:
pIUnknown->QueryInterface returns E_NOINTERFACE
The interface is provided by a an object running in a local server
Why don't I see a trace on ClientIdentity_QueryInterface?
Trace
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:CoGetClassObject
CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46},
IID:{0001---c000-0046}
0009:warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
not registered inproc
0009:trace:ole:create_marshalled_proxy
rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46},
iid={0001---c000-0046}
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:WINE_StringFromCLSID
0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_server activating local server
'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for
{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0012:trace:ole:DllMain 0x3a 0x1 0x1
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2
0012:trace:ole:DllMain (0x5e,1,0x1)
0012:trace:ole:CoInitializeEx ((nil), 2)
0012:trace:ole:CoInitializeEx () - Initializing the COM libraries
0012:trace:ole:RunningObjectTableImpl_Initialize ()
0012:trace:ole:COM_CreateApartment creating new apartment, model=2
0012:trace:ole:COM_CreateApartment Created apartment on OXID 110012
0012:trace:ole:WINE_StringFromCLSID
0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA}
0012:trace:ole:CoRegisterClassObject
({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x7fca0180,0x0004,0x0001,0x41f094)
0012:trace:ole:CoMarshalInterface (0x77e28e58,
{0001---c000-0046}, 0x7fca0180, 0, (nil), 1)
0012:trace:ole:CoGetStandardMarshal
({0001---c000-0046},0x7fca0180,0,(nil),1,0x76fd60)
0012:trace:ole:CoMarshalInterface Using standard marshaling
0012:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace
0012:trace:ole:StdMarshalImpl_MarshalInterface
(...,{0001---c000-0046},...)
0012:trace:ole:start_apartment_listener_thread apt->listenertid=0
0014:trace:ole:apartment_listener_thread Apartment listener thread starting on
(\\.\pipe\WINE_OLE_StubMgr_00110012)
0012:trace:ole:CoGetPSClsid () riid={0001---c000-0046},
pclsid=0x76fcf4
0012:trace:ole:WINE_StringFromCLSID
0x3e7df0->{0001---C000-0046}
0012:trace:ole:__CLSIDFromStringA {0320---C000-0046} ->
0x76fcf4
0012:trace:ole:CoGetPSClsid () Returning
CLSID={0320---c000-0046}
0012:trace:ole:WINE_StringFromCLSID
0x76fcf4->{0320---C000-0046}
0012:trace:ole:CoGetClassObject
CLSID: {0320---c000-0046},
IID:{d5f569d0-593b-101a-b569-08002b2dbf7a}
0012:trace:ole:COMPOBJ_DLLList_Add
0012:trace:ole:PSFacBuf_CreateStub
({0001---c000-0046},0x7fca0180,0x76fcec)
0012:fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented
0012:trace:ole:get_stub_manager_from_object not found for object 0x7fca0180
0012:trace:ole:register_ifstub constructing new stub manager
0012:trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x77e28c28
for object with IUnknown 0x7fca0180
0012:trace:ole:stub_manager_new_ifstub oid=1, stubbuffer=0x77e28f18,
iptr=0x7fca0180, iid={0001---c000-0046},
tablemarshal=TRUE
0012:trace:ole:stub_manager_int_release after 1
0015:trace:ole:local_server_thread Starting threader for
{b6b35894-dd6f-11d3-84ac-00c04f0e1b46}.
0015:trace:ole:WINE_StringFromCLSID
0x77e28e80->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0009:trace:ole:create_marshalled_proxy waiting for
\\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}
0015:trace:ole:local_server_thread marshalling IClassFactory to client
0009:trace:ole:create_marshalled_proxy read marshal id from pipe
0009:tra
Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
On Sun, 16 Jan 2005 22:23:54 +, Luke Kenneth Casson Leighton wrote: > you are correct about DCE 1.2.2 not containing DCOM: it is > FreeDCE that does. > > other than that - with all due respect, and if i understand > you correctly: you are wrong [or looking in the wrong place] I'm afraid FreeDCE contains some obsolete IDL (uses ancient interface names) and a few stubs. It doesn't implement DCOM or anything like it. Sorry. > are you _seriously_ intending to reimplement the DCE/RPC IDL compiler - > because that's what's required!!! Yes. We have no choice, there are no IDL compilers today that generate MIDL compatible output (as far as I'm aware). > you _cannot_ be serious about reinventing the 250,000 lines of c code > required to properly support DCE/RPC which is a prerequisite for > supporting DCOM. We are very serious, in fact, a lot of the work has already been done. We don't care about supporting every feature of DCE/RPC, most of them are simply never used by Windows applications. You're incorrect that DCE/RPC is a prerequisite for DCOM. If you don't care about wire compatibility (for now, we don't) it is not, and our current DCOM code doesn't use RPC at all. > please tell me i am wrong in believing that you are giving serious > consideration to a _third_ DCE/RPC runtime and development environment, > to compete with samba 4's GPL'd implementation which is in development > and with FreeDCE's complete reference implementation which is available > under an OSF 1.0 BSD-like license. You are not wrong, that is exactly what we're doing. There is an open dialog between us and the Samba4 team on where we can share code, however they do not have binary compatibility as an explicit goal which means our work does not overlap as much as you seem to think it does. thanks -mike
Re: Help debugging Fotowire
On Sun, 16 Jan 2005 23:00:42 +0200, Antti Mäkelä wrote: > Without any debugs and native oleaut32 I now get: > > bash-2.05b$ wine fwprint > fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented > fixme:time:GetCalendarInfoA (0409,0001,2030,(nil),0,0x77a6c718): > quarter-stub > fixme:time:GetCalendarInfoW (0409,0001,2030,(nil),0,0x77a6c718): > quarter-stub I'm not sure. Your best bet is to try calling the functions in your own mini test programs in the same way that Fotowire does until you find something that doesn't work right. thanks -mike
Re: Exiting a tests on the first failure
On Mon, 2005-01-17 at 13:24, Alexandre Julliard wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
>
> > If the first CreateKey fails, there is no need to continue with the
> > testing (because the rest of the tests will fail as well). What's the
> > best way to stop there?, something like this?:
> >
> > START_TEST(shreg)
> > {
> > HKEY hkey = create_test_entries();
> > +if (!hkey) return;
>
> No, the best way is to fix the test to use a key that works on all
> platforms. The test case is useless otherwise.
Hi Alexandre,
is it OK that have the above in a patch anyway, along with some extra
debugging output? I will try and find a key we can use, but one problem
could be that the failures are related to security (that's why I want to
have the extra output as well).
If it is security it will probably be harder to find a key which we can
use.
Cheers,
Paul.
Re: SHLWAPI: stub implementations
Hans Leidekker wrote:
-Hans
Changelog:
Stub implementations for PathUnExpandEnvStringsSHRegEnumUSValue{A,W},
SHRegCreateUSKey{A,W}, SHRegDeleteEmptyUSKey{A,W}, SHRegDeleteUSValue{A,W},
SHRegEnumUSValue{A,W}.
Index: dlls/shlwapi/path.c
===
RCS file: /home/wine/wine/dlls/shlwapi/path.c,v
retrieving revision 1.48
diff -u -r1.48 path.c
--- dlls/shlwapi/path.c 5 Oct 2004 18:07:14 - 1.48
+++ dlls/shlwapi/path.c 17 Jan 2005 16:36:09 -
@@ -3911,6 +3911,24 @@
}
/*
+ * PathUnExpandEnvStringsA [EMAIL PROTECTED]
+ */
+BOOL WINAPI PathUnExpandEnvStringsA(LPCSTR pszPath, LPSTR pszBuf, UINT cchBuf)
+{
+FIXME("(%s,%s,0x%08x)\n", debugstr_a(pszPath), debugstr_a(pszBuf), cchBuf);
+return FALSE;
+}
Can you add documentation for these and the other functions you've
added? You'll probably notice that these are the only functions in the
files that are now not documented.
Rob
Re: tests
Ivan Leo Puoti <[EMAIL PROTECTED]> writes: >> Do you mean that the tagless report was generated by a >> manual run while the one with the IvanLeo tag was run by >> winrash? > > Yes, those reports were both generated from the same > winetest binary. I'm not sure of what you mean by > crosschecks, but I'll do whatever can help, just let me > know what I should do. Well, you could find out why the quoted code snippet doesn't work on NT, and possibly suggest a better test... It was recommended by Dimitry, btw. (cc'd) -- Feri.
Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#4)
On Monday 17 January 2005 16:13, Joris Huizer wrote: > Sorry, I meant, what if the string ends with digits there? > If I find out how, I may add a testcase for that; The next line is this one: if (*s == '\0') return FALSE; So if the string were to end with a digit we bail out right away. Just tested that here as well and it's ok. -Hans
Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#4)
Hans Leidekker wrote: On Monday 17 January 2005 11:18, Joris Huizer wrote: +if (time->wDayOfWeek > 6) return FALSE; +while (*s && !isdigitW( *s )) s++; What happens if s just became NULL in this loop ? Huh? Sorry, I meant, what if the string ends with digits there? If I find out how, I may add a testcase for that; (Sorry about the other cases, I didn't read carefull enough) regards, Joris
DIB direct drawing - Bug 412: Implementing a DIB engine
Well, i'm a novice here (in wine and linux), but i think i could help with this task. I'm a good windows application developer (www.babel7.com), and i wrote two programs with some of the semantics you are looking for: painting over BMPs (or better DIBs). The 2 programs are for 256 colors and true RGB. They write on file BMPs. The painting functions were written to generate pie graphs, poligonals, rectangles, and so on, but they can be readapted to write on DIBs in memory. The sintax help (comm line wo parms) is in Spanish, but i will not ask for excuses for it. The use is very simple. I will rewrite an english sintax help if i begin with the task. You can download it and test if i could help. If yes, i will begin with the task... And time will say!! http://www.babel7.com/bmps.zip Regards... Aljandro Bonet Babel Informatica SL Madrid [EMAIL PROTECTED]
Re: WineHQ:winetest: produce valid HTML
Dimitrie O. Paun wrote: It would also be nice if the author of a test got an email whenever a test failed. Finding out the author of a test isn't easy, it requires some digging into CVS. And we can't just do it, we need opt-ins, etc. Not worth it IMO. But if I were to implement an opt-in scheme, you would be ok with it? regards, Jakob
Re: Wine scheduling and threading issues [was Re: Threading issues...]
Ingo Molnar wrote: It would be nice if someone with a proper Wine test-setup could check whether _negative_ renicing of highprio Windows threads solves the scheduling problems. In fact you could even try to map Windows priorities (16 levels available to nonprivileged users?) to the nice range of -7...+7, and run the test as root so that the renicing succeeds. Ingo I did something like that. I ran wineserver as root and a user wine app with same WINEPREFIX. The priorities work as expected and it was working for the mediocre app I had at the time. As Jeremy said, it is never the right way to do it programmatically. I was working on a system where wine is installed by an "administrator" Linux user with some privileges and all users shared the same wineprefix. (Multi-user wine, a bit like the NT model.) I abandoned it because of the problem I had with multiple displays. And also my Linux IT knowledge is not up to it so I had problems with file access and stuff
Re: tests
Do you mean that the tagless report was generated by a manual run while the one with the IvanLeo tag was run by winrash? Yes, those reports were both generated from the same winetest binary. I'm not sure of what you mean by crosschecks, but I'll do whatever can help, just let me know what I should do. Ivan.
Re: Janitorial : add missing declarations ( #3 )
Rémi Assailly <[EMAIL PROTECTED]> writes: > +/* USER */ > +extern DWORD X11DRV_MsgWaitForMultipleObjectsEx( DWORD count, const HANDLE > *handles, > + DWORD timeout, DWORD mask, > DWORD flags ); > +extern void X11DRV_InitKeyboard( BYTE *key_state_table ); > +extern UINT X11DRV_GetKeyboardLayoutList(INT size, HKL *hkl); > +extern HKL X11DRV_GetKeyboardLayout(DWORD dwThreadid); > +extern BOOL X11DRV_GetKeyboardLayoutName(LPWSTR name); > +extern HKL X11DRV_LoadKeyboardLayout(LPCWSTR name, UINT flags); > +extern BOOL X11DRV_UnloadKeyboardLayout(HKL hkl); > +extern HKL X11DRV_ActivateKeyboardLayout(HKL hkl, UINT flags); > +extern SHORT X11DRV_VkKeyScanEx(WCHAR wChar, HKL hkl); There's no need to add prototypes for the exported entry points, they are not called from anywhere inside the dll. It causes more work when changing the functions for no real benefit. -- Alexandre Julliard [EMAIL PROTECTED]
Re: WineHQ:winetest: produce valid HTML
On Mon, Jan 17, 2005 at 11:30:53AM +0100, Ferenc Wagner wrote: > > I would prefer to have all failed tests at the top, so one > > could see easily which ones need to be fixed. > > Not being an addition but a change, I'd like to hear others' > opinion on this matter. I agree, it's not worth losing alphabetical ordering. > > It would also be nice if the author of a test got an email > > whenever a test failed. > > Finding out the author of a test isn't easy, it requires > some digging into CVS. And we can't just do it, we need opt-ins, etc. Not worth it IMO. -- Dimi.
Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#4)
Hans Leidekker wrote: What happens if, the string ends with WININET_wkday[i][0] or WININET_wkday[i][1] ? It can't, that's protected by the: The best way to prove these things is to write a test cases. If others have doubts about your code, then they can add to the test case and check the code still works. Mike
Re: Exiting a tests on the first failure
Paul Vriens <[EMAIL PROTECTED]> writes:
> If the first CreateKey fails, there is no need to continue with the
> testing (because the rest of the tests will fail as well). What's the
> best way to stop there?, something like this?:
>
> START_TEST(shreg)
> {
> HKEY hkey = create_test_entries();
> +if (!hkey) return;
No, the best way is to fix the test to use a key that works on all
platforms. The test case is useless otherwise.
--
Alexandre Julliard
[EMAIL PROTECTED]
unsubscribe lexey
Re: Exiting a tests on the first failure
Paul Vriens <[EMAIL PROTECTED]> writes:
> If the first CreateKey fails, there is no need to continue with the
> testing (because the rest of the tests will fail as well). What's the
> best way to stop there?, something like this?:
>
> START_TEST(shreg)
> {
> HKEY hkey = create_test_entries();
> +if (!hkey) return;
Looks fine for me, given that in wine/test.h we have
#define START_TEST(name) void func_##name(void)
--
Feri.
Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#4)
On Monday 17 January 2005 11:18, Joris Huizer wrote:
> > +while (*s && !isalphaW( *s )) s++;
> > +if (*s == '\0' || *(s + 1) == '\0' || *(s + 2) == '\0') return
> > FALSE; +time->wDayOfWeek = 7;
> > +
> > +for (i = 0; i < 7; i++)
> > +{
> > +if (toupperW( WININET_wkday[i][0] ) == toupperW( *s ) &&
> > +toupperW( WININET_wkday[i][1] ) == toupperW( *(s + 1) ) &&
> > +toupperW( WININET_wkday[i][2] ) == toupperW( *(s + 2) ) )
> > +{
> > +time->wDayOfWeek = i;
> > +break;
> > +}
> > +}
>
> What happens if, the string ends with WININET_wkday[i][0] or
> WININET_wkday[i][1] ?
It can't, that's protected by the:
if (*s == '\0' || *(s + 1) == '\0' || *(s + 2) == '\0') return FALSE
above. The third check prevents that.
> > +if (time->wDayOfWeek > 6) return FALSE;
> > +while (*s && !isdigitW( *s )) s++;
>
> What happens if s just became NULL in this loop ?
Huh?
> What happens if, the string ends with WININET_month[i][0] or
> WININET_month[i][1] ?
Same as above.
-Hans
Re: more tests for tests.winehq.org
Stefan Leichter <[EMAIL PROTECTED]> writes: > now we have fixed mingw to build the new test. So perform them after > building ;-) > > ChangeLog > --- > Include new tests Thanks for your work and attention! -- Feri.
Re: WineHQ:winetest: produce valid HTML
Jakob Eriksson <[EMAIL PROTECTED]> writes: > Ferenc Wagner wrote: > >> What makes you think I've got one? It should be *you* >> who speak up and tell what information/presentation is >> need for the best and easiest use. > > I would prefer to have all failed tests at the top, so one > could see easily which ones need to be fixed. Not being an addition but a change, I'd like to hear others' opinion on this matter. My personal feeling is that losing alphabetical ordering on test names isn't worth it, as color monitors are fairly common nowadays. So vote for the change! > It would also be nice if the author of a test got an email > whenever a test failed. Finding out the author of a test isn't easy, it requires some digging into CVS. On the other hand, I'd choose an opt-in method instead. But it's a separate project anyway, the present machinery has pretty much nothing to facilitate this. The summary.txt files are easy to parse and available by HTTP, so one could use them to get the figures. -- Feri.
Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#4)
Hans Leidekker wrote:
Well, if you really want to be sure no bad string overflows occur, this
function is still not save:
+/***
+ * InternetTimeToSystemTimeW (WININET.@)
+ */
+BOOL WINAPI InternetTimeToSystemTimeW( LPCWSTR string, SYSTEMTIME* time, DWORD
reserved )
+{
+unsigned int i;
+WCHAR *s = (LPWSTR)string;
+
+TRACE( "%s %p 0x%08lx\n", debugstr_w(string), time, reserved );
+
+if (!string || !time || reserved != 0) return FALSE;
+
+/* Convert an RFC1123 time such as 'Fri, 07 Jan 2005 12:06:35 GMT' into
+ * a SYSTEMTIME structure.
+ */
+
+while (*s && !isalphaW( *s )) s++;
+if (*s == '\0' || *(s + 1) == '\0' || *(s + 2) == '\0') return FALSE;
+time->wDayOfWeek = 7;
+
+for (i = 0; i < 7; i++)
+{
+if (toupperW( WININET_wkday[i][0] ) == toupperW( *s ) &&
+toupperW( WININET_wkday[i][1] ) == toupperW( *(s + 1) ) &&
+toupperW( WININET_wkday[i][2] ) == toupperW( *(s + 2) ) )
+{
+time->wDayOfWeek = i;
+break;
+}
+}
What happens if, the string ends with WININET_wkday[i][0] or
WININET_wkday[i][1] ?
+
+if (time->wDayOfWeek > 6) return FALSE;
+while (*s && !isdigitW( *s )) s++;
What happens if s just became NULL in this loop ?
+time->wDay = strtolW( s, &s, 10 );
+
+while (*s && !isalphaW( *s )) s++;
+if (*s == '\0' || *(s + 1) == '\0' || *(s + 2) == '\0') return FALSE;
+time->wMonth = 0;
+
+for (i = 0; i < 12; i++)
+{
+if (toupperW( WININET_month[i][0]) == toupperW( *s ) &&
+toupperW( WININET_month[i][1]) == toupperW( *(s + 1) ) &&
+toupperW( WININET_month[i][2]) == toupperW( *(s + 2) ) )
+{
+time->wMonth = i + 1;
+break;
+}
+}
What happens if, the string ends with WININET_month[i][0] or
WININET_month[i][1] ?
+if (time->wMonth == 0) return FALSE;
+
+while (*s && !isdigitW( *s )) s++;
+if (*s == '\0') return FALSE;
+time->wYear = strtolW( s, &s, 10 );
+
+while (*s && !isdigitW( *s )) s++;
+if (*s == '\0') return FALSE;
+time->wHour = strtolW( s, &s, 10 );
+
+while (*s && !isdigitW( *s )) s++;
+if (*s == '\0') return FALSE;
+time->wMinute = strtolW( s, &s, 10 );
+
+while (*s && !isdigitW( *s )) s++;
+if (*s == '\0') return FALSE;
+time->wSecond = strtolW( s, &s, 10 );
+
+time->wMilliseconds = 0;
+return TRUE;
+}
Yes it's a pain, but if you want to be really strict on this, this is
not save yet
regards,
Joris
Exiting a tests on the first failure
Hi,
I'm currently looking into the shreg test of shlwapi. In the error-logs
on test.winehq.org I see a lot of errors.
If the first CreateKey fails, there is no need to continue with the
testing (because the rest of the tests will fail as well). What's the
best way to stop there?, something like this?:
START_TEST(shreg)
{
HKEY hkey = create_test_entries();
+if (!hkey) return;
Cheers,
Paul Vriens.
Re: tests
Ivan Leo Puoti <[EMAIL PROTECTED]> writes:
> I've run tests twice, once with winrash and once manually, on windows nt 4.0
> http://test.winehq.com/data/200501131000/#NT%204
> interestingly some tests that fail or timeout when run from winrash,
> work when
> run manually.
> Is there a way this could be fixed, or should we at least somehow mark tests
> that give different results when run with winrash or manually?
Do you mean that the tagless report was generated by a
manual run while the one with the IvanLeo tag was run by
winrash? That's strange, since the blue strip should only
be present when bRunningOnVisibleDesktop is true in the test
headers. And it's true in both cases. Here is the origin
of that flag (from winetest/main.c)
static int running_on_visible_desktop ()
{
return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE != 0);
}
Seems like it doesn't work properly. Can you perhaps do
some crosschecks? I'll also look into this later today.
--
Feri.
