- Wine-Devel - list.winehq.org

Re: More msvcrt scanf tests
by Alexandre Julliard Feb. 25, 2004

Feb. 25, 2004

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > + todo_wine ok(strstr(buffer,"e+008") != 0,"Sprintf different \"%s\"\n",buffer); > + sprintf(buffer,I64x,(ULONGLONG)0xffffffffffffffff); Long long constants are not portable, you need to compute them from long constants. -- Alexandre Julliard julliard(a)winehq.org

5 9

RFC: OlePicture patch
by Fabian Cenedese Feb. 25, 2004

Feb. 25, 2004

Hi Can anybody comment on this? http://www.winehq.org/hypermail/wine-patches/2004/02/0121.html I know that it's not the best solution (or if it is it's without explanation). I tried to find anything about this magic number but I found nothing. Unless someone has a reason _not_ to apply it I vote in favour of it. It helps VB programs with the SSTab control without pictures assigned to the tabs to load properly. As there are no pictures it shouldn't read more data from the stream and try to create a picture with wrong data. Thanks bye Fabi

1 0

Fun quickfix
by Mike Hearn Feb. 25, 2004

Feb. 25, 2004

Hi, Here's an easy to fix bug for somebody wanting to get into Wine hacking, or who has a spare few minutes. The basic problem is with the tab control and can be seen by running http://bylands.dur.ac.uk/~mh/Tab.exe ... that (from control spy). As you can see on the bottom row, the top of the tabs are overdrawn by the row above. Putting a Sleep call into the tab drawing code reveals that we're not drawing the tabs in any particular order (presumably it's the order they were added) and reading the code indicates that having TAB_DrawItem overdraw its bottom is the expected behaviour. The code can be seen in dlls/comctl32/tab.c, in TAB_Refresh and TAB_DrawItem One fix is to draw the tabs from top row to the bottom, instead of in a random order. In order to do that, you need to read the code in TAB_SetItemBounds and add a new field to TAB_ITEM to record which row it was placed in. Then, in TAB_Refresh, firstly sort the TAB_ITEMS topmost to bottommost before drawing them. This shouldn't be too hard, but would fix a nasty visual glitch in Wine. If anybody feels like doing it but gets stuck feel free to ask here for help. On the other hand if you're an old hand at Wine feel free to fix it too, there's little point keeping bugs around for training purposes :) thanks -mike

3 2

Re: Pipe tests coprrected
by Ferenc Wagner Feb. 25, 2004

Feb. 25, 2004

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > dlls/kernel/tests/pipe.c > Added tests for redirected STDIN/STDOUT > Added todo_wine test for waiting on closed pipe > > The tests now succeed on NT40(vmware) They do on XP, too. The MinGW-compiled binary now won't run from a network drive. Also, test 3 of 7 loops, so I didn't run it. Apart from that, the report goes like below. -- Feri. pipe.c:823:test 1 of 7: pipe.c:645: Test failed: CreateNamedPipe failed pipe.c:647: Test failed: WriteFile to not-yet-connected pipe pipe.c:649: Test failed: ReadFile from not-yet-connected pipe pipe.c:653: Test failed: CreateFile failed pipe.c:673: Test failed: CloseHandle pipe.c:825:test 2 of 7: pipe.c:264: Test failed: CreateNamedPipe failed pipe.c:272: Test failed: CreateNamedPipe failed pipe.c:274: Test failed: CloseHandle pipe.c:275: Test failed: CloseHandle pipe.c:284: Test failed: CreateNamedPipe failed pipe.c:292: Test failed: nMaxInstances not obeyed pipe.c:295: Test failed: CloseHandle pipe.c:304: Test failed: CreateNamedPipe failed pipe.c:312: Test failed: PIPE_ACCESS_* mismatch allowed pipe.c:315: Test failed: CloseHandle pipe.c:827:test 3 of 7: should be fixed pipe.c:829:test 4 of 7: pipe.c:149:test_CreateNamedPipe starting pipe.c:174: Test failed: connecting to nonexistent named pipe should fail with ERROR_FILE_NOT_FOUND pipe.c:186: Test failed: CreateNamedPipe failed pipe.c:189: Test failed: CreateFile failed pipe.c:248: Test failed: CloseHandle pipe.c:250:test_CreateNamedPipe returning pipe.c:831:test 5 of 7: pipe.c:833:test 6 of 7: pipe.c:835:all tests done pipe: 44 tests executed, 0 marked as todo, 19 failures.

1 0

buffer too small for currency
by Fabian Cenedese Feb. 24, 2004

Feb. 24, 2004

Hi I get this warning when I try to start a basic program. This comes from the function VARIANT_GetLocalisedNumberChars. I added some printfs and found that my currency is apparently "SFr.", so 4 chars plus zero which is too much for the 4 char buffer. Strange though that on the command line it looks differently: locale -k LC_MONETARY int_curr_symbol="CHF " currency_symbol="Fr." mon_decimal_point="." mon_thousands_sep=" " mon_grouping=3;3 ... Anyway, I thought I increase this buffer. But then the string gets stored in two separate variables (each one char) in the VARIANT_NUMBER_CHARS struct. Is there a reason that this is not a string? Why only two chars? Thanks bye Fabi

3 4

WineGuru
by Dimitrie O. Paun Feb. 24, 2004

Feb. 24, 2004

Hi Boaz, I've looked at the potato-factory, and to be honest I don't like the interface. The very fact that I have to logon before I can see anything makes it fairly useless for me. Now, before and put in too much infrastructure, I think we can start small as follows: -- have people submit material to wine-devel -- various folks (volunteers needed) will collect them and post them in a nice, orderly manner to a special area (TBD) on WineHQ This has the advantage of being a lot more controlled, and I'm sure the editorial review will pay off. If the volume becomes too big, we can consider in the future to automate the process. But until then, I think the manual approach is better. -- Dimi.

3 2

Mixing native and bulitin DLL (MSVCRT)
by Uwe Bonnes Feb. 24, 2004

Feb. 24, 2004

Hallo, I am trying to debug a problem with builtin MSVCRT. Is there any easy way to deviate calls from builtin msvcrt to native msvcrt. At present I have renamed native msvcrt in the wine system directory. Then in the builtin msvcrt I call a function and for that function I do a LoadLibrary(<renamed native msvcrt>) and a GetProcAddress(hinstofrenamendmsvcrt,<original function) to finally call that procedure. I experimented with the forwards in the spec file, but didn't succeed. Is there any easier way? 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

Winedbg that catches exception raised in IsBadReadPtr
by Christian Costa Feb. 24, 2004

Feb. 24, 2004

Hi, Winedbg catches the exception raised and handled in a __TRY/__EXCEPT/__ENTRY statement in the IsBadReadPtr function. Is it a normal behaviour? And if yes how can I disable it? Without Winedbg everything is fine. Thanks in advance, Bye, Christian

3 2

rebar issues
by Matt Chapman Feb. 24, 2004

Feb. 24, 2004

Hi, I'm having some rebar issues with a particular application (Canon File Viewer Utility). The rebar is meant to look something like: |0--------------- |1------|2---| |3------|4------|5------|6------ | (and there are some extra hidden bands) Instead in wine the result is: |0--------------- ||| |3------ |||| with the remaining bands having 0-size child windows (and there's important functionality in those bands). The minimum sizes provided by the application seem to be right. The application then requests maximisation of 0,3,4,5,6 in that order, which isn't implemented in WINE so that should not do anything, but I'd still expect the minimum sizes to be honoured. The output of wine --debugmsg +rebar is at: http://www.cse.unsw.edu.au/~matthewc/rebar.gz (62K) I'm currently trying to understand the source, but if anyone is familiar with the rebar and has any suggestions that would be much appreciated. Thanks, Matt

2 3

Re: Fix compile of programs/winedbg/elf.c on NetBSD 1.6
by Eric Pouech Feb. 24, 2004

Feb. 24, 2004

Yorick Hardy a écrit : > Changelog: Use SHN_UNDEF instead of STN_UNDEF when it is defined > and STN_UNDEF is not. Fixes compiling on NetBSD 1.6. > > > Kind regards, > both STN_UNDEF and SHN_UNDEF exist in ELF definition and are meant to be used in different cases, which your patch mixes. Hence the fix is wrong (even if by change STN_UNDEF and SHN_UNDEF both are defined as 0) So, I'd rather suggest something (at the top of the file) as #ifndef STN_UNDEF # define STN_UNDEF 0 #endif A+

2 4