wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: small ctl3d fix
by Dmitry Timoshkov 15 Feb '03

15 Feb '03

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > > > Dmitry's patch doesn't fix my problem, because app call only > > > Ctl3dIsAutoSubclass and it expects it to be true. > > > > > > ChangeLog: > > > Changed default internal ctl3d auto subclass flag from false to true > > > > My test shows that after a successful Ctl3dRegister() > Ctl3dIsAutoSubclass() > > returns FALSE. Therefore your patch is wrong and you have to investigate > > what sequence of ctl3d calls in your application makes it return TRUE. > > > > -- > > Dmitry. > > > > like i said, it calls only Ctl3dIsAutoSubclass() and expects true, otherwise > it starts debugger. what if it should be set true for default and > Ctl3dRegister sets it to false? No, my test shows that by default it's set to FALSE. If you can't investigate it yourself for any reason please send a +relay compressed bz2 log (not more than 500 Kb) to me (*not* to the list) showing the real behaviour of your application. Thanks. -- Dmitry.

1 0

Treeview Icons now broken builtin too
by Uwe Bonnes 15 Feb '03

15 Feb '03

Hallo, some time ago, I reported, that in Xilinx Webpack some Icons associated with a treeview where distorted, when using the native commctrl dlls, but all right when using builtin dlls. With the recent updates, now builtin behaves like native and shows distorted Icons. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: small ctl3d fix
by Dmitry Timoshkov 15 Feb '03

15 Feb '03

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > Dmitry's patch doesn't fix my problem, because app call only > Ctl3dIsAutoSubclass and it expects it to be true. > > ChangeLog: > Changed default internal ctl3d auto subclass flag from false to true My test shows that after a successful Ctl3dRegister() Ctl3dIsAutoSubclass() returns FALSE. Therefore your patch is wrong and you have to investigate what sequence of ctl3d calls in your application makes it return TRUE. -- Dmitry.

1 0

Patch Manager
by Fabian Cenedese 15 Feb '03

15 Feb '03

Hi I have never supplied patches myself. But I read all the mails about how to submit patches. I saw on the wxWindows page that they have a Patch- Manager. Mainly just a form to enter all necessary data. Maybe something like that could be useful here too. http://sourceforge.net/tracker/?group_id=9863&atid=309863&func=add bye Fabi

4 3

VC++ nmake not working with Wine 20030115 when it worked with 200208xx
by J. Grant 14 Feb '03

14 Feb '03

Hi, Calling nmake from /wcmd/ used to work, now it does not. I can't see why not, here is the debugger ouput if anyone knows whats wrong I'd be happy to hear! Breakpoint 1 at 0x40009bd0 (_end+0x37fae414) *** Invalid address 0x40011f80 (_end+0x37fb67c4) <snip> Unhandled exception: unimplemented function msvcrt.dll.__p__pgmptr called in 32- bit code (0x40733056). In 32-bit mode. 0x40733056 (__wine_unimplemented+0x56 [msvcrt.spec.c:47] in msvcrt.dll.so): jmp 0x40733050 (__wine_unimplemented+0x50 [msvcrt.spec.c:47] in msvcrt.dll.so) 47 for (;;) RtlRaiseException( &rec ); Wine-dbg> There are a few unknown functions with "__p__pgmptr" void __wine_stub_msvcrt_dll_122(void) { __wine_unimplemented("__p__pgmptr"); } I'm not sure why this problem occures now, when it worked before. Comments welcome Regards JG

5 16

Non-applied patches
by Shachar Shemesh 14 Feb '03

14 Feb '03

Hi Alexandre, I'm just trying to understand whether you are still trying to fight the backlog, my patches fell through the cracks, or that you decided not to apply them. I am referring to: http://www.winehq.com/hypermail/wine-patches/2003/01/0399.html and http://www.winehq.com/hypermail/wine-patches/2003/01/0401.html If the last option, please explain what is wrong with them. Sh. P.S. A simple mail saying "I'm still fighting the backlog, I'll let you know when I've covered all the submitted patches" will suffice, as far as I'm concerned. -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/

2 2

Re: Listview delete column zero
by Duane Clark 14 Feb '03

14 Feb '03

Duane Clark wrote: > While the MSDN specifically says that column zero should not be deleted, > it does in fact work on WinNT, and at least one app depends on it. On > WinNT, deleting column zero deletes the last column of items but the > first header. Since no app will ever depend on that bizarre behavior, > we just delete the last column including the header. > I probably should have mentioned why the app deletes column zero. It repeatedly deletes column zero, testing the returned Boolean until it gets false, and then it starts inserting new columns. So it ends up completely replacing the listview contents.

2 2

edit control bug - EM_LIMITTEXT does not work
by Felipe W Damasio 14 Feb '03

14 Feb '03

Hi, When you try to limit the maximum chars accepted in an edit control by doing something like this: SendMessage(hwndEdit, EM_LIMITTEXT, 10, 0); Wine simply ignores it, and let the user type more than 10 (in this example) characters. This looks bad, because the user could eventually overflow the allocated memory for the dialog, making the program crash. Cesar Mello (mello(a)elipse.com.br) coded a little program to show this limitation: ftp://ftp.elipse.com.br/pub/about1/about1-src.tar.gz I just created a bug entry on bugs.winehq: http://bugs.winehq.com/show_bug.cgi?id=1280 Could someone help me with this? Thanks a lot and kind regards, Felipe

1 0

Re: For your consideration, here's a preview of some new seh_try_macros-type
by Rolf Kalbermatter 14 Feb '03

14 Feb '03

Dan Kegel <dank(a)kegel.com> wrote: >Alexandre Julliard wrote: >> There are people building Wine with the Sun compiler. Also it makes >> sense for at least some dlls to allow building them with MSVC to test >> them under Windows. And in general using different compilers is a good >> way to shake out bugs from the code. > >I always build my conformance tests both in the normal way >and standalone with msvc. >IMHO every executable and DLL we do should run on Windows, too, >if it doesn't absolutely have to make Unix system calls. I regularly compile some of the DLLs under MSVC. The current state of DLLs is so that the non core DLLs compile usually almost fine but linking is a quite big issue I haven't fully tackled. If I link with the MSCV libs I get often undefined imports and linking with MSVC generated import libs from Wine source requires some hand work, as the MSVC IDE only generates the import lib AFTER the entire DLL has been successfully created, so you get sort of a catch 22 situation. Another issue is that most of the DLLs are not yet in a state where they can possibly be put into a current Windows installation, without causing all sorts of crashes and weird problems. The interdependencies between DLLs in a W2K installation is really enormous and a lot of functions in the Wine DLLs are not yet implemented or not fully complient. Rolf Kalbermatter

2 1

DirectSound problems
by Matthieu Foillard 14 Feb '03

14 Feb '03

It seems that there is a bug with DirectSound. Using Half-life, when i start the console, it goes into un infinite loop : $ /usr/bin/wine --debugmsg +dsound Program\ Files/Half-Life/hl.exe -- -opengl -game cstrike -windowed -console -noipx 2> /tmp/log it says : ... warn:dsound:DSOUND_MixCancelAt (0x403f6318, 0), buf_mixpos=25296 trace:dsound:IDirectSoundBufferImpl_Unlock (0x403f6318,0x403f6410,65536,(nil),0):stub trace:dsound:IDirectSoundBufferImpl_Lock (0x403f6318,0,65536,0x40760064,0x40760054,0x4076005c,0x40760058,0x00000000) at 60129 trace:dsound:IDirectSoundBufferImpl_Lock ->65536.0 trace:dsound:IDirectSoundBufferImpl_Lock locking prebuffered region, ouch warn:dsound:DSOUND_MixCancelAt (0x403f6318, 0), buf_mixpos=25296 trace:dsound:IDirectSoundBufferImpl_Unlock (0x403f6318,0x403f6410,65536,(nil),0):stub trace:dsound:IDirectSoundBufferImpl_Lock (0x403f6318,0,65536,0x40760064,0x40760054,0x4076005c,0x40760058,0x00000000) at 60129 trace:dsound:IDirectSoundBufferImpl_Lock ->65536.0 trace:dsound:IDirectSoundBufferImpl_Lock locking prebuffered region, ouch ... Over and over and the game console is "lock". If I disable sound (by comment out oss driver in ~/.wine/config) it works fine. I have this problem using both oss and arts driver. Sometimes after some times, it works and the game console unlocks and all goes fine. Sometimes i wait for a long time and it never works. i have an es1370 sound card, kernel 2.4.20, /dev/dsp0 and /dev/dsp1 are both working. It seems that the game menu use /dev/dsp1 and the game itself (e.g. the console) uses /dev/dsp0. I can't explain this. Thanks for your help mgf -- Matthieu Foillard <m.foillard(a)taktile.com> tel : 0146090496 - gsm : 0686574170 pgp : 0x1609654F

1 0

Re: wine/dlls/comctl32 listview.c
by Rein Klazes 14 Feb '03

14 Feb '03

On Tue, 11 Feb 2003 16:17:31 -0600, you wrote: > Modified files: > dlls/comctl32 : listview.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Compute matrix of first paint when we actually have some items > (problem first spotted & debugged by Duane Clark). This causes a rgeression in newsbin. The listview with the headers do not update during a "retrieve all headers". Until something else triggers a redraw, eg uncover window pane. From then everything works as expected. Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 3

named pipes still broken?
by Dan Kegel 14 Feb '03

14 Feb '03

Is it just me, or are named pipes broken for other people, too? In my tests, Wine can create named pipes, but the reading side can't open them. (Even without my recent changes to sync.c which added filename checking.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: 2GB visible partition size
by Duane Clark 14 Feb '03

14 Feb '03

Tony Lambregts wrote: > Alexandre Julliard wrote: >> >>Well, yes, if we really need to change the fstype it should be a >>generic option that allows all types to be specified, not just >>NTFS. And it shouldn't overload the existing "type" parameter, it >>should be a separate entry. >> > OK. I guess my biggest problem with this is that the most obvious name > for this entry is "Filesytem" which is already used <g>. Since the parameter of interest is specifically named "fsname" rather than "fstype" or "Filesystem", perhaps that should be the configurable parameter name. I would think that would eliminate any confusion.

2 1

For your consideration, here's a preview of some new seh_try_macros-type stuff...
by Gregory M. Turner 14 Feb '03

14 Feb '03

Let me know what you think of these. So far, I like them better than the original versions, although in solving some limitations of the old macros, I've created some new ones. This version avoids ({ }) entirely, in favor of Ove's original thought, which was to use __LINE__; therefore, putting multiple __(finally|except) clauses in the same line probably breaks. Otherwise, these are better macros. They are slightly more easily understood (although still pretty darn confusing, especially in the debugger), probably more resiliant against compiler optimizations, and have much less awful performance. Best of all, they ought to properly re-raise exceptions after executing finally clauses. There is some cruft in there, btw, which will be fixed before I submit anything to patches. They still break break/continue, of course, since they still rely on __TRY / __EXCEPT blocks to do the dirty-work. You can run the original seh_macros.c test against these successfully, except for the "absurdly nested" ones which use macros and presumably would fail quite dramatically due to __LINE__ duplications. FWIW, compared to the degree of "pressing need" for these macros, I have already spent way too much time on them... But the old ones kind of sucked, and, frankly, it's a fun semantic puzzle that requires pusing the limits of good old cpp just a _bit_ further than may have been intended ... so, here it is. Note that I'm declaring a variable in the header file here. I guess, I should fix this by creating an internal API in ntdll? I never quite figured out whether global non-static variables in a dll are thread-local, or what... (same for lexically scoped static ones -- real clueless here, and building a new system so I don't have much doco's at my fingertips ATM) Sooo.... Anyone want to help me decide what's the best way to get a thread-local global variable instantiated? Probably, my previous attempt with TlsAlloc was semantically correct, but that was /way/ too fat a solution, I'd like something much quicker if its at all possible. Otherwise this won't be threadsafe, which seems like a bad call, esp. since such code will probably end up being used to guard against unacceptable resource leakage.. warning, cut-and-pasted this patch in chunks so it might be bugged... should be clear enough how to duplicate, however, if it fails... --- ../wine.vanilla/include/wine/exception.h 2003-01-29 21:50:14.000000000 -0600 +++ ./include/wine/exception.h 2003-02-09 01:33:45.000000000 -0600 @@ -21,8 +21,12 @@ #ifndef __WINE_WINE_EXCEPTION_H #define __WINE_WINE_EXCEPTION_H +/* WRC can't find setjmp.h. Does it not check /usr/include? */ +#if (!(defined(__WRC__))) + #include <setjmp.h> #include "windef.h" +#include "excpt.h" /* The following definitions allow using exceptions in Wine and Winelib code * @@ -59,6 +63,16 @@ * You can use them to leave a __EXCEPT block though. * * -- AJ + * + * Now we can implement the __try/__except/__finally magic of VC++ as standard (?) macros. + * this is a "good enough" implementation, it's incomplete, but should suffice for most uses. + * + * The macros require some symbols to be found in ntdll.dll.so, so link with that DLL if you + * use them. + * + * If you are using VC++ and this header, #define USE_COMPILER_EXCEPTIONS before you include it. + * + * -gmt */ /* Define this if you want to use your compiler built-in __try/__except support. @@ -146,8 +160,90 @@ extern DWORD __wine_finally_handler( PEXCEPTION_RECORD record, EXCEPTION_FRAME *frame, CONTEXT *context, LPVOID pdispatcher ); + +#if (!defined(NO_VC_SEH_MACROS)) + +#ifndef _WINE_ALREADY_DEFINED_SEH_MACROS__ +#define _WINE_ALREADY_DEFINED_SEH_MACROS__ + +/* fixme: should be renamed since these are used for except too */ +typedef void (*__p_seh_finally_executer) (); +typedef void (*__p_seh_dotry_executer) (__p_seh_finally_executer); +__p_seh_finally_executer __thread_outermost_handler_ptr; + +#define __SEH_LINEUNIQ_CAT2(x,y) __SEH_LINEUNIQ_ ## y ## x +#define __SEH_LINEUNIQ_CAT1(x,y) __SEH_LINEUNIQ_CAT2(x,y) + +#define __SEH_LINEUNIQ_NULLMACRO(x) x +#define __SEH_LINEUNIQ_MAGIC_LINE __SEH_LINEUNIQ_NULLMACRO( __LINE__ ) + +#define __SEH_LINEUNIQ_ID(x) __SEH_LINEUNIQ_CAT1( __SEH_LINEUNIQ_MAGIC_LINE , x ) + +#define __try \ + do { \ + void dotry(__p_seh_finally_executer fin) { \ + __label__ __seh_macro_exit_spot; \ + auto WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler); \ + __TRY { \ + { \ + +#define __finally \ + } \ + __seh_macro_exit_spot: \ + if (0) goto __seh_macro_exit_spot; \ + } __EXCEPT( __wine_seh_macro_exception_handler ) { \ + } __ENDTRY \ + (*fin)(); \ + WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler) { \ + (*fin)(); \ + return EXCEPTION_CONTINUE_SEARCH; \ + } \ + } \ + goto __SEH_LINEUNIQ_ID(DETOUR); \ + __SEH_LINEUNIQ_ID(RETOUR): \ + dotry( __thread_outermost_handler_ptr ); \ + } while (0); \ + goto __SEH_LINEUNIQ_ID(AFTERFINALLY); \ + auto void __SEH_LINEUNIQ_ID(Finally_Executer) (); \ + __SEH_LINEUNIQ_ID(DETOUR): \ + __thread_outermost_handler_ptr = & __SEH_LINEUNIQ_ID(Finally_Executer); \ + goto __SEH_LINEUNIQ_ID(RETOUR); \ + __SEH_LINEUNIQ_ID(AFTERFINALLY): ; \ + void __SEH_LINEUNIQ_ID(Finally_Executer) () + +#define __except(...) \ + } \ + __seh_macro_exit_spot: \ + if (0) goto __seh_macro_exit_spot; \ + } __EXCEPT( __wine_seh_macro_exception_handler ) { \ + (*fin)(); \ + } __ENDTRY \ + WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler) { \ + return ( __VA_ARGS__ ); \ + } \ + } \ + goto __SEH_LINEUNIQ_ID(DETOUR); \ + __SEH_LINEUNIQ_ID(RETOUR): \ + dotry( __thread_outermost_handler_ptr ); \ + } while (0); \ + goto __SEH_LINEUNIQ_ID(AFTEREXCEPT); \ + auto void __SEH_LINEUNIQ_ID(Except_Executer) (); \ + __SEH_LINEUNIQ_ID(DETOUR): \ + __thread_outermost_handler_ptr = & __SEH_LINEUNIQ_ID(Except_Executer); \ + goto __SEH_LINEUNIQ_ID(RETOUR); \ + __SEH_LINEUNIQ_ID(AFTEREXCEPT): ; \ + void __SEH_LINEUNIQ_ID(Except_Executer) () + +#define __leave goto __seh_macro_exit_spot + +#endif /* _WINE_ALREADY_DEFINED_SEH_MACROS__ */ + +#endif /* NO_VC_SEH_MACROS */ + #endif /* USE_COMPILER_EXCEPTIONS */ +#endif /* __WRC__ */ + static inline EXCEPTION_FRAME * WINE_UNUSED __wine_push_frame( EXCEPTION_FRAME *frame ) { #if defined(__GNUC__) && defined(__i386__) -- gmt

4 6

wcmd autoexec.bat?
by J. Grant 14 Feb '03

14 Feb '03

Hello I have been testing wcmd to automate some process I used to use on win98. However I can not find the autoexec.bat for wcmd? Currently the wcmd shell starts up with no prompt, this has to be corrected in my batch files. prompt $p$g etc. Wine seems to have 2 autoexec.bat's but does not seem to ever use them. /var/lib/wine/autoexec.bat never seems to be executed. Neither is the one I created in my fake c drive (/home/now3d/.wine/c/autoexec.bat) Is this issue known? are their any workarounds? Regards JG

3 4

Keyboard shortcut to disable DXGrab?
by Matthew Toseland 14 Feb '03

14 Feb '03

What would be involved in implementing a keyboard shortcut (ideally configurable) to temporarily disable DXGrab, when playing a game in a window? If such a thing was done, would it be accepted into the source? -- Matthew Toseland toad@amphibian.dyndns.org/amphibian@users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/ahNdJC6opVw/ ICTHUS.

1 0

Re: popupmenu itemsize
by Uwe Bonnes 14 Feb '03

14 Feb '03

>>>>> "Christian" == Christian Kristukat <semmel(a)hoc.net> writes: Christian> Hi, I suspect that this again is a dirty patch but it helps Christian> in working with Microcal Origin. Maybe a more skilled person Christian> than me finds the real origin of this problem. At one point Christian> in the program a popup menu opens but only the items' width Christian> is calculated correctly, the height is not, in fact it is Christian> equal zero. For that case I added an arbitrarily chosen Christian> height of 12 points and it works fine. Here's the patch: ... Christian> lpitem->rect.bottom += 12; + Nagic constants mostly are evil? It the "12" perhaps related to some SYSPARAMS? ... Christian> PS: By the way: every cvs operation (update, diff) hangs Christian> after processing the last directory. However it seems to be Christian> complete and pressing CTRL-C seems not to corrupt Christian> anything. Any ideas? Are you using rhlx01.fht-esslingen.de? Andi works on that problem then. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

suspended threads acquiring synchronization objects
by Peter Hunnisett 14 Feb '03

14 Feb '03

Howdy, we've discovered that windows seems to not allow suspended threads to acquire synchronization objects, which make really really good sense, while wine does. I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Would people have a look at the patch and let me know if it's the best way to fix it, or if I've missed anything? Thanks, Peter peter(a)transgaming.com

3 2

Error in the server thread id fix
by Bill Medland 13 Feb '03

13 Feb '03

Is anyone else looking into a problem that appears to have been introduced by the server change on Feb 1st changing thread and process ids to small integers? As a result ACCPAC for Windows' main desktop process shuts down after about a minute, but leaves various other processes running. I'll have a look at it but I don't know how successful I'll be. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

4 7

2GB visible partition size
by J. Grant 13 Feb '03

13 Feb '03

Hello, I noticed there is a 2GB visible partition size. This seems to be like FAT16, however I am running on ext3, is there a config option I can set to remove this limit? Regards JG

4 5

Looking for information on implemented API's in wine
by David Miller 13 Feb '03

13 Feb '03

I am ready to begin work on the actual database aspect of cross referencing the windows dlls. As part of the database I would like to include the status of a given API in wine so it will be possible to do things like query for all unimplemented APIs in a given dll. The first questions I have are whether or not I can depend on the spec files to give a complete list, and can someone either point me to documentation on the spec files or explain everything I need to know in order to determine the status of APIs defined there?

1 0

CreateNamedPipe questions
by Dan Kegel 13 Feb '03

13 Feb '03

Oddly enough, it looks like it's ok to pass NULL as the filename to CreateNamedPipe. Anyone know what programs do that, and why? Here's a patch that makes our CreateNamedPipe check for legal filenames (or NULL). It should probably allow forward slashes... The patch also adds a quickie regression test, but I still have to use late binding for CreateNamedPipe (or is it ok for the test to fail on win9x?). Would this test have caught the recent named pipe breakage? If not, what would I need to add? Comments welcome; I'll send it to wine-patches after addressing any feedback. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: dlls/kernel/sync.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/sync.c,v retrieving revision 1.26 diff -u -p -u -r1.26 sync.c --- dlls/kernel/sync.c 25 Oct 2002 21:02:30 -0000 1.26 +++ dlls/kernel/sync.c 13 Feb 2003 07:47:27 -0000 @@ -508,6 +508,8 @@ HANDLE WINAPI CreateNamedPipeW( LPCWSTR { HANDLE ret; DWORD len = name ? strlenW(name) : 0; + static const WCHAR leadin[] = {'\\','\\','.','\\','P','I','P','E'}; + int i; TRACE("(%s, %#08lx, %#08lx, %ld, %ld, %ld, %ld, %p)\n", debugstr_w(name), dwOpenMode, dwPipeMode, nMaxInstances, @@ -516,7 +518,13 @@ HANDLE WINAPI CreateNamedPipeW( LPCWSTR if (len >= MAX_PATH) { SetLastError( ERROR_FILENAME_EXCED_RANGE ); - return 0; + return INVALID_HANDLE_VALUE; + } + /* FIXME: can name really be NULL?! */ + if (name && strncmpiW(name, leadin, sizeof(leadin)/sizeof(leadin[0]))) + { + SetLastError( ERROR_INVALID_NAME ); + return INVALID_HANDLE_VALUE; } SERVER_START_REQ( create_named_pipe ) { Index: dlls/kernel/tests/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/Makefile.in,v retrieving revision 1.6 diff -u -p -u -r1.6 Makefile.in --- dlls/kernel/tests/Makefile.in 4 Oct 2002 17:42:27 -0000 1.6 +++ dlls/kernel/tests/Makefile.in 13 Feb 2003 07:47:27 -0000 @@ -17,6 +17,7 @@ CTESTS = \ generated.c \ locale.c \ path.c \ + pipe.c \ process.c \ thread.c --- /dev/null 2002-08-30 16:31:37.000000000 -0700 +++ dlls/kernel/tests/pipe.c 2003-02-12 23:44:20.000000000 -0800 @@ -0,0 +1,109 @@ +/* + * Unit tests for named pipe functions in Wine + * + * Copyright (c) 2002 Dan Kegel + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdlib.h> +#include <stdio.h> +#include <time.h> + +#ifndef STANDALONE +#include "wine/test.h" +#else +#include <assert.h> +#define START_TEST(name) main(int argc, char **argv) +#define ok(condition, msg) assert(condition) +#endif + +#include <windef.h> +#include <winbase.h> +#include <winerror.h> +#include <wtypes.h> + +#define PIPENAME "\\\\.\\PiPe\\tests_" __FILE__ + +void test_CreateNamedPipeA(void) +{ + HANDLE hnp; + HANDLE hFile; + const char obuf[] = "Bit Bucket"; + char ibuf[32]; + DWORD written; + DWORD gelesen; + + /* Bad parameter checks */ + hnp = CreateNamedPipeA("not a named pipe", + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + + ok(hnp == INVALID_HANDLE_VALUE && GetLastError() == ERROR_INVALID_NAME, + "CreateNamedPipe should fail if name doesn't start with \\\\.\\pipe"); + +#if 0 /* Evidently it's ok in windows to pass NULL as the pipe name! */ + hnp = CreateNamedPipeA(NULL, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + 1, 1024, 1024, NMPWAIT_USE_DEFAULT_WAIT, NULL); + ok(hnp == INVALID_HANDLE_VALUE && GetLastError() == ERROR_INVALID_NAME, + "CreateNamedPipe should fail if name is NULL"); +#endif + + /* Functional checks */ + + hnp = CreateNamedPipeA(PIPENAME, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0); + ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); + if (hFile == INVALID_HANDLE_VALUE) + return; + + /* Make sure we can read and write a few bytes in both directions*/ + memset(ibuf, 0, sizeof(ibuf)); + ok(WriteFile(hnp, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(ReadFile(hFile, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); + ok(gelesen == sizeof(obuf), "read file len"); + ok(memcmp(obuf, ibuf, written) == 0, "content check"); + + memset(ibuf, 0, sizeof(ibuf)); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(ReadFile(hnp, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); + ok(gelesen == sizeof(obuf), "read file len"); + ok(memcmp(obuf, ibuf, written) == 0, "content check"); + + CloseHandle(hFile); + CloseHandle(hnp); +} + +START_TEST(pipe) +{ + test_CreateNamedPipeA(); +} +

3 4

Fix for Treeview Regression in Putty, winamp, et al.
by Drew "DanteAliegri" Ogle 13 Feb '03

13 Feb '03

Putty and winamp use dialogs which contain treeviews. When the treeview code sets values to be passed to the callback function, it decides there if it is returning to A or W. When it is returning to a dialog, it returns a W, however, when the user code which the dialog calls is an A function, it excepts TVN_*A, when the treeview code is sending TVN_*W. The most logical place to test for this, was in DefDlgProcW, which then modifies the code when it finds a) the msg to be WM_NOTIFY b) the lParam to be non-null c) the code to be of W form d) the code to be of a TVN_ type. As this is my second real patch, any comments are welcome :) -Dante Index: windows/defdlg.c =================================================================== RCS file: /home/wine/wine/windows/defdlg.c,v retrieving revision 1.29 diff -u -r1.29 defdlg.c --- windows/defdlg.c 14 Jan 2003 19:29:15 -0000 1.29 +++ windows/defdlg.c 13 Feb 2003 05:39:00 -0000 @@ -395,12 +395,22 @@ LRESULT WINAPI DefDlgProcW( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) { BOOL result = FALSE; + BOOL forWide = FALSE; WNDPROC dlgproc; + /* make sure we only change TVN_ codes. */ + if( msg == WM_NOTIFY && lParam && ((LPNMHDR)lParam)->code & 0x30 ) + forWide = TRUE; SetWindowLongW( hwnd, DWL_MSGRESULT, 0 ); if ((dlgproc = DEFDLG_GetDlgProc( hwnd ))) { + /* if call was meant for a W funcition, but the callback + * is really an A function, change the code from a W code + * to a A code. + **/ + if( forWide && (WINPROC_GetProcType( dlgproc) == WIN_PROC_32A )) + ((LPNMHDR)lParam)->code += 0x31; /* Call dialog procedure */ result = CallWindowProcW( dlgproc, hwnd, msg, wParam, lParam ); /* 16 bit dlg procs only return BOOL16 */

2 2

Re: wine-devel digest, Vol 1 #1689 - 17 msgs
by ATMRD＠aol.com 13 Feb '03

13 Feb '03

Hey, > I am running Gnome on a variant of FreeBSD called Darwin. It shoudln't matter what window manager your running be it Apple's Aqua, or Gnome or KDE, as long as the X11, libraries are installed, because regardless Darwin is still the core of the OS. > Darwin runs > on PPC architecture opposed to x86 architecture. My question is can > Wine run on this variant of FreeBSD? Theoritically Wine should run on any version of FreeBSD, however due to Darwin's arhicteture, allthough it is FreeBSD based,which does not use the ELF format but isntead the Mach-O, wine does not work correctly or at all to my knowledge. > Can I download the source and > build Wine for my system? You can try, but I dont think it will work with out major modification to some of the core libs wich are X86 dependant. If for some reason it does I'd be dilighted to hear about it. There is a project called darwine, at http://darwine.sf.net, you can find more information about running wine on Darwin there. Hope this helps ~Sanjay Connare.

1 0

Re: [ros-kernel] Cool!
by Steven Edwards 13 Feb '03

13 Feb '03

Thought you guys might like to see this. We are making major progress on 3rd party drivers --- Ge van Geldorp <ge(a)gse.nl> wrote: > Attached is a screen capture of GDITEST.EXE. You might think "what's so > cool about that, gditest has been running for a while now". Well, look > again. Note the lines starting in the top-left and running to the bottom > and right side. They're in real RGB(64, 64, 128), not in the gray to > which they're mapped when you're running on a 16 color VGA display! > > The screen capture was taken from ReactOS running in a VMware virtual > machine, using the 3rd party VMware 16 bit per pixel video driver. > > It will take me some more time to finish this. Although GDITEST.EXE > works, WINHELLO.EXE doesn't yet. There is some cleanup still to be done > and I need to do some more testing to make sure I didn't break the > existing VGA video drivers (VGAMP.SYS/VGADDI.DLL). However, I think > support for at least some 3rd party video drivers is within reach now. > > G� van Geldorp. > > ATTACHMENT part 2 image/gif name=gditest.gif __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel