Re: winmm: For MCI parsing, use 64bit compatible structures.
joerg-cyril.hoe...@t-systems.com a écrit : Hi, I believe this patch can stand on its own, regardless of whether we discover an MCI_INTEGER64 type or similar later (cf. bug 22146). It is not all about Wine64. I have two others in my queue: - One deals with HWND and the like in the MCI_XYZ_PARMS. - Another adds more tests that do not depend on sound being configured. These are not ready yet for submission. Yet this first patch is good enough to start gathering results on test.winehq. André's machine basically passed the MCI tests no worse than Wine32 with it. This patch depends on the Sysinfo patch from earlier today. Regards, Jörg Höhle this patch is ugly as hell... and it still believe we can do the MCI parser without knowing about MCI structures internals A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: [PATCH 1/5] winmm: Improve MCI's Sysinfo command.
joerg-cyril.hoe...@t-systems.com a écrit : Hi, this is the first of a series of patches I started writing last year. It suffered from the typical "some patches are 100% complete but follow others that are only 80%" syndrome. Now I filled in the missing parts. The fifth implements more tests to prove the pertinence of the code patches. Regards, Jörg Höhle did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? actually, I'd say it belongs to the 16=>32 mci message mapper, not in generic 32bit code A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: on most hated "OS" in the history of computing
On 29 March 2010 10:37, Damjan Jovanovic wrote: > Why should Debian politics be a barrier to its adoption by Wine? It's not that, it's what the actual licence text says: http://opensource.org./licenses/sybase.php Read what you give away just by using the software ... - d.
Re: kernel32: Fix moving a file to the same one
André Hentschel writes:
> diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c
> index 2b69e8c..d34b3a7 100644
> --- a/dlls/kernel32/path.c
> +++ b/dlls/kernel32/path.c
> @@ -1031,6 +1031,9 @@ BOOL WINAPI MoveFileWithProgressW( LPCWSTR source,
> LPCWSTR dest,
> if (flag & MOVEFILE_WRITE_THROUGH)
> FIXME("MOVEFILE_WRITE_THROUGH unimplemented\n");
>
> +if (!strcmpiW( source, dest ))
> +return TRUE; /* we are done */
> +
There's a lot more to this than simply comparing the specified paths.
--
Alexandre Julliard
julli...@winehq.org
Re: Reorganizing msvcrt related dlls implementation
Piotr Caban writes: > Hi, > > Recently I was working on some msvcrt/msvcr90 functions. > > I found few problems related to how the implementation is organized: > - Some of the functions are invoking invalid_parameter, msvcrt is not > allowing to change it, msvcr90 exports _set_invalid_parameter_handler. > - create_locale (not available on msvcrt) needs almost exactly the > same internal functions as set_locale. > > I see few ways of implementing this functions: > - Copy implementations of functions that are invoking > invalid_parameter_handler to msvcr90. This will introduce lots of code > duplication in future (currently most of functions that should invoke > invalid_parameter_handler are not implemented or are not calling > it). Almost whole locale.c file will be copied. > - Create wine specific dll, forward msvcrt and msvcr90 calls to it. > - Move implementation of some functions from msvcrt to msvcr90. It'll > probably introduce similar problems when newer msvcrXX appears. > > What solution is preferred? Any other ideas? For cases like this where half the functionality is already in msvcrt, I think it's OK to export the extra functions from msvcrt too. Hopefully they will get added by Microsoft sooner or later, since msvcrt is sort of a superset of all the msvcr* dlls. Just make a clear note that they are not officially exported yet. -- Alexandre Julliard julli...@winehq.org
Reorganizing msvcrt related dlls implementation
Hi, Recently I was working on some msvcrt/msvcr90 functions. I found few problems related to how the implementation is organized: - Some of the functions are invoking invalid_parameter, msvcrt is not allowing to change it, msvcr90 exports _set_invalid_parameter_handler. - create_locale (not available on msvcrt) needs almost exactly the same internal functions as set_locale. I see few ways of implementing this functions: - Copy implementations of functions that are invoking invalid_parameter_handler to msvcr90. This will introduce lots of code duplication in future (currently most of functions that should invoke invalid_parameter_handler are not implemented or are not calling it). Almost whole locale.c file will be copied. - Create wine specific dll, forward msvcrt and msvcr90 calls to it. - Move implementation of some functions from msvcrt to msvcr90. It'll probably introduce similar problems when newer msvcrXX appears. What solution is preferred? Any other ideas? Cheers, Piotr
Re: [TRY 4] [PATCH] user32: horizontal and vertical scrolling of selection in edit control
Henry Kroll III wrote: > +if (es->region_posx < 0)EDIT_EM_LineScroll(es,-10,0); > +else if (es->region_posx > 0)EDIT_EM_LineScroll(es,10,0); > +if (es->region_posy < 0)EDIT_EM_LineScroll(es,0,-1); > +else if (es->region_posy > 0)EDIT_EM_LineScroll(es,0,1); Where do -/+10,-/+1 come from? A test case wouldn't hurt. Also please add some spacing and try to follow the indentation style of existing code. -- Dmitry.
Re: on most hated "OS" in the history of computing
On Mon, Mar 29, 2010 at 11:14 AM, Saulius Krasuckas wrote:
> Hello
>
> * On Sun, 28 Mar 2010, Damjan Jovanovic wrote:
>>
>> Out of interest, why were you visiting openwatcom.org? Are you also
>> looking into Win16 tests for Wine?
>
> Kind of. I was looking into licensing problems preventing its inclusion
> in Debian. Seems like I should try starting negotiation between OWC folks
> and Debian-legal experts on slight license changes.
>
>
> S.
>
Why should Debian politics be a barrier to its adoption by Wine?
The installer from the openwatcom downloads page (version 1.8) works
well - just stick to the official release and not the "Alternative
Distributions" at the bottom of the page, which can't cross-compile.
Then after you install it, it's a simple matter of:
export WATCOM=/path/to/install/dir
export PATH=$WATCOM/binl:$PATH
export INCLUDE=$WATCOM/h/win
export LIB=$WATCOM/lib386/win
wcc -bt=windows hello.c
wcl -l=windows hello.o
wine hello.exe
where hello.c has this:
#include
int PASCAL WinMain( HINSTANCE this_inst, HINSTANCE prev_inst,
LPSTR cmdline, int cmdshow )
{
MessageBox(NULL,"Hello world","Win16",MB_OK);
return 0;
}
$ file hello.exe
hello.exe: MS-DOS executable, NE for MS Windows 3.x
:-)
Damjan
Re: on most hated "OS" in the history of computing
On 29 March 2010 10:14, Saulius Krasuckas wrote: > * On Sun, 28 Mar 2010, Damjan Jovanovic wrote: >> Out of interest, why were you visiting openwatcom.org? Are you also >> looking into Win16 tests for Wine? > Kind of. I was looking into licensing problems preventing its inclusion > in Debian. Seems like I should try starting negotiation between OWC folks > and Debian-legal experts on slight license changes. The problem is that the OpenWatcom licence is so unremittingly awful that debian-legal went "ahahaha, you must be joking" and quickly dismissed it. It obviously fails the DFSG in a ridiculous number of ways. Heck, reading it myself I'm reluctant to even *run* the software. I'm boggling that the OSI accepted it, given the OSI rules are based on the Debian rules. I did email licens...@fsf, who said they may try to negotiate with Sybase over getting it to actually being a free software licence. Because it would be an obviously good thing for a good DOS/Win16 compiler to be free software. I don't know if anyone at FSF has managed to do anything about this, though a legacy environment such as this is likely not the highest of priorities for a tiny charity of minimal resources. - d.
Re: on most hated "OS" in the history of computing
Hello * On Sun, 28 Mar 2010, Damjan Jovanovic wrote: > > Out of interest, why were you visiting openwatcom.org? Are you also > looking into Win16 tests for Wine? Kind of. I was looking into licensing problems preventing its inclusion in Debian. Seems like I should try starting negotiation between OWC folks and Debian-legal experts on slight license changes. S.
Re: [PATCH 5/8] msvcr90: Added _get/set_invalid_parameter_handler implementation (try4)
On 03/24/2010 10:39 PM, Piotr Caban wrote: +p_invalid_parameter = (void *)GetProcAddress( hMsvcrt,"_invalid_parameter"); +if(p_invalid_parameter) +*p_invalid_parameter = test_invalid_parameter_handler; Hi Piotr, That last assignment makes the tests crash on Vista+. Could you have a look? -- Cheers, Paul.
