- wine-devel - winehq.org

RE: Fix toolbar get style
by Ge van Geldorp 30 Apr '04

30 Apr '04

> From: Maxime Bellengé > > When a toolbar receives a TB_GETSTYLE message with wParam=0, > the application expects to get the toolbar style and not the > first button style. This patch fixes eMule 0.42e, now the > toolbar is visible. > > ChangeLog > * Fix TB_GETSTYLE to return the style of the toolbar when > wParam is 0 It seems there is another problem with the toolbar styles. When you CreateToolbarEx() with the WS_VISIBLE bit turned on, TOOLBAR_Create() will call GetWindowLongW() to get the window style and store that as the dwStyle member of TOOLBAR_INFO. Unfortunately, when the WM_CREATE message is sent the WS_VISIBLE bit of the window style retrieved with GetWindowLongW() is always turned off. It is turned on a little bit later, but no WS_STYLECHANGED is sent for this. So, the dwStyle member of TOOLBAR_INFO doesn't always mimick the "true" window style, it is possible that the WS_VISIBLE bit is off in TOOLBAR_INFO but on in the window style. If your app does something like: SendMessage(hwndTB, TB_SETSTYLE, 0, SendMessage(hwndTB, TB_GETSTYLE, 0, 0) | TBSTYLE_FLAT ); this will make your toolbar invisible. Gé van Geldorp.

2 1

how can i solve this problem???
by Falcifer 30 Apr '04

30 Apr '04

fixme:nls:CompareStringW Ignoring unknown style 0x10000000 fixme:hook:NotifyWinEvent (32768,0x20049,-4,2)-stub! fixme:nls:CompareStringW Ignoring unknown style 0x10000000 fixme:hook:NotifyWinEvent (32768,0x20049,-4,3)-stub! fixme:hook:NotifyWinEvent (32774,0x20049,-4,1)-stub! X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 73 (X_GetImage) Serial number of failed request: 21212 Current serial number in output stream: 21212 fixme:nls:CompareStringW Ignoring unknown style 0x10000000 fixme:hook:NotifyWinEvent (32768,0x20049,-4,2)-stub! fixme:nls:CompareStringW Ignoring unknown style 0x10000000 fixme:hook:NotifyWinEvent (32768,0x20049,-4,3)-stub! fixme:hook:NotifyWinEvent (32774,0x20049,-4,1)-stub! X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 73 (X_GetImage) Serial number of failed request: 21212 Current serial number in output stream: 21212 ----------------------------------------------------------------------------------- Any clue?? Its very important cause if i can run this corporative application in Linux all the firm will migrate gradually to Linux. Thanks

1 0

Running NT PPC with wine
by emmanuel maillard 30 Apr '04

30 Apr '04

Hi all, I'm looking for people using wine on linuxPPC who want try my patches to run a NT PPC exe. (i plan to reinstall linux/ppc to make my tests but i need to rearrange my HDs before, and it will take times ) This doesn't work for me on MacOSX but this could be due to our port for darwin, this why i need to have feedback from linux/ppc users. PE headers are store in little endian even for an PPC file, so I test endiannes and swap PE infos if needed. For my test i use winimage 3.0 for NT PPC, available here : http://www.winimage.com/download.htm map_image seems good : trace:module:map_image mapped PE file at 0x4f000-0xe5000 Trying to load PE image for unsupported architecture (PowerPC) trace:module:map_image mapping section .text at 0x50000 off 400 size 6c600 flags 60000020 trace:module:map_image mapping section .rdata at 0xbd000 off 6ca00 size 1c00 flags 40000040 trace:module:map_image mapping section .data at 0xbf000 off 6e600 size 3600 flags c0000040 trace:module:map_image clearing 0xc2600 - 0xc3000 trace:module:map_image mapping section .pdata at 0xc8000 off 71c00 size 5c00 flags 40000040 trace:module:map_image mapping section .idata at 0xce000 off 77800 size 3000 flags c0000040 trace:module:map_image mapping section .reldata at 0xd1000 off 7a800 size 200 flags c0000040 trace:module:map_image mapping section .rsrc at 0xd2000 off 7aa00 size e000 flags 40000040 trace:module:map_image mapping section .reloc at 0xe0000 off 88a00 size 5000 flags 42000040 trace:module:do_relocations relocating from 0x400000-0x496000 to 0x4f000-0xe5000 trace:module:do_relocations 1848 relocations for page 6e000 trace:module:do_relocations 816 relocations for page 6f000 trace:module:do_relocations 80 relocations for page 70000 trace:module:do_relocations 40 relocations for page 71000 trace:module:do_relocations 80 relocations for page 72000 trace:module:do_relocations 32 relocations for page 73000 trace:module:do_relocations 1236 relocations for page 79000 trace:module:do_relocations 1240 relocations for page 7a000 trace:module:do_relocations 1240 relocations for page 7b000 trace:module:do_relocations 1236 relocations for page 7c000 trace:module:do_relocations 1240 relocations for page 7d000 trace:module:do_relocations 796 relocations for page 7e000 trace:module:do_relocations 1316 relocations for page 7f000 trace:module:do_relocations 704 relocations for page 80000 trace:module:do_relocations 184 relocations for page 82000 But when process start : .... trace:module:MODULE_InitDLL entry : 0x0(L"WINIMAGE.exe",0x1) - END 0009:Starting process L"F:\\Desktop\\wimapp30\\WINIMAGE.exe" (entryproc=0xbe750) wait few seconds ... wine: Unhandled exception (thread 0009), starting debugger... i test it with mosaic too but failed due to an undefined symbol in iphlpapi.dll "err:module:load_builtin_dll failed to load .so lib for builtin L"iphlpapi.dll": dlcompat: dyld: wine Undefined symbols: _res_9_init" If someone with a Linux/x86 want to launch winimage PPC with +module enable to send me the output to see if my changes give right values it will be helpfull to. Thanks in advance emmanuel the patches (kernel/process.c, ntdll/loader.c, ntdll/virtual.c, server/mapping.c and winedump/pe.c) : full winimage output with +module :

1 1

Re: Fix toolbar get style
by maxime.bellenge＠laposte.net 30 Apr '04

30 Apr '04

> >>> maxime.bellenge(a)laposte.net 04/29/04 22:59 PM >>> > > When a toolbar receives a TB_GETSTYLE message with wParam=0, the > > application expects to get the toolbar style and not the first button > > style. This patch fixes eMule 0.42e, now the toolbar is visible. > > > > ChangeLog > > * Fix TB_GETSTYLE to return the style of the toolbar when wParam is 0 > > Good catch, but I think the original author of the > TB_GETSTYLE code got a bit confused. I think it should > always return the style of the toolbar (according to > MSDN) and should print an ERR or FIXME if wParam != 0, > as it is reserved. > Could you resubmit with that change? > > Rob > Hello I will perform some tests under win xp to check this behaviour because even if the author may have been confused. I think it is worth testing that. I will then send another patch. a+ Max Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

1 0

wineinstall problems at creatconfig-file
by Saulius Krasuckas 30 Apr '04

30 Apr '04

CVS Wine of today compiles OK, but at the end of wineinstall script I get some strange output (put below). After that it seems Wine is unable to read ~/.wine/config file. Thus it switches to default Desktop mode ("Desktop" = "640x480") while running any win32|wine app. That makes me feel quiet disappointed. Should I regress-test Wine or have I missed something? There are about 70 MBs of free disk space available for Wine in my box. [s2@katleriai wine]$ sh -x tools/wineinstall <skipped /> + echo 'Preparing to install default Wine registry entries...' Preparing to install default Wine registry entries... + '[' '!' -d /home/s2/.wine/dosdevices ']' + echo 'Installing default Wine registry entries...' Installing default Wine registry entries... + echo + programs/rundll32/rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 tools/wine.inf Line 8: Malformed key '[wine]' Line 8: Error creating key '[wine]' Line 9: Value without key '"Windows" = "c:\\windows"' Line 10: Value without key '"System" = "c:\\windows\\system"' Line 11: Value without key '"Temp" = "e:\\"' Line 12: Value without key '"Path" = "c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\"' Line 13: Value without key '"Profile" = "c:\\windows\\Profiles\\Administrator"' Line 14: Value without key '"GraphicsDriver" = "x11drv"' Line 17: Value without key '"ShellLinker" = "wineshelllink"' Line 21: Malformed key '[Version]' Line 21: Error creating key '[Version]' Line 29: Malformed key '[DllOverrides]' Line 29: Error creating key '[DllOverrides]' Line 31: Value without key '"oleaut32" = "builtin, native"' Line 32: Value without key '"ole32" = "builtin, native"' Line 33: Value without key '"comdlg32" = "builtin, native"' Line 34: Value without key '"shell32" = "builtin, native"' Line 35: Value without key '"shfolder" = "builtin, native"' Line 36: Value without key '"shlwapi" = "builtin, native"' Line 37: Value without key '"shdocvw" = "builtin, native"' Line 38: Value without key '"advapi32" = "builtin, native"' Line 39: Value without key '"msvcrt" = "native, builtin"' Line 40: Value without key '"mciavi.drv" = "native, builtin"' Line 41: Value without key '"mcianim.drv" = "native, builtin"' Line 42: Value without key '"msi" = "native, builtin"' Line 49: Value without key '"*" = "builtin, native"' Line 51: Malformed key '[x11drv]' Line 51: Error creating key '[x11drv]' Line 53: Value without key '"AllocSystemColors" = "100"' Line 55: Value without key '"PrivateColorMap" = "N"' Line 57: Value without key '"PerfectGraphics" = "N"' Line 61: Value without key '"Managed" = "Y"' Line 66: Value without key '"UseDGA" = "Y"' Line 68: Value without key '"UseXVidMode" = "Y"' Line 70: Value without key '"UseXRandR" = "Y"' Line 72: Value without key '"UseTakeFocus" = "Y"' Line 74: Value without key '"DXGrab" = "N"' Line 77: Value without key '"DesktopDoubleBuffered" = "N"' Line 93: Malformed key '[fonts]' Line 93: Error creating key '[fonts]' Line 96: Value without key '"Resolution" = "96"' Line 97: Value without key '"Default" = "-adobe-helvetica-"' Line 98: Value without key '"DefaultFixed" = "fixed"' Line 99: Value without key '"DefaultSerif" = "-adobe-times-"' Line 100: Value without key '"DefaultSansSerif" = "-adobe-helvetica-"' Line 114: Malformed key '[FontDirs]' Line 114: Error creating key '[FontDirs]' Line 120: Malformed key '[ppdev]' Line 120: Error creating key '[ppdev]' Line 128: Malformed key '[spooler]' Line 128: Error creating key '[spooler]' Line 129: Value without key '"FILE:" = "tmp.ps"' Line 130: Value without key '"LPT1:" = "|lpr"' Line 131: Value without key '"LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -"' Line 132: Value without key '"LPT3:" = "/dev/lp3"' Line 134: Malformed key '[ports]' Line 134: Error creating key '[ports]' Line 138: Malformed key '[Debug]' Line 138: Error creating key '[Debug]' Line 146: Malformed key '[registry]' Line 146: Error creating key '[registry]' Line 152: Value without key '"LoadGlobalRegistryFiles" = "Y"' Line 154: Value without key '"LoadHomeRegistryFiles" = "Y"' Line 156: Value without key '"LoadWindowsRegistryFiles" = "Y"' Line 158: Value without key '"WritetoHomeRegistryFiles" = "Y"' Line 162: Value without key '"SaveOnlyUpdatedKeys" = "Y"' Line 164: Malformed key '[Clipboard]' Line 164: Error creating key '[Clipboard]' Line 165: Value without key '"ClearAllSelections" = "0"' Line 166: Value without key '"PersistentSelection" = "1"' Line 167: Value without key '"UsePrimary" = "0"' Line 170: Malformed key '[afmdirs]' Line 170: Error creating key '[afmdirs]' Line 171: Value without key '"1" = "/usr/share/ghostscript/fonts"' Line 172: Value without key '"2" = "/usr/share/a2ps/afm"' Line 173: Value without key '"3" = "/usr/share/enscript"' Line 174: Value without key '"4" = "/usr/X11R6/lib/X11/fonts/Type1"' Line 176: Malformed key '[WinMM]' Line 176: Error creating key '[WinMM]' Line 179: Value without key '"Drivers" = "wineoss.drv" ; default for most common configurations' Line 186: Value without key '"WaveMapper" = "msacm.drv"' Line 187: Value without key '"MidiMapper" = "midimap.drv"' Line 189: Malformed key '[dsound]' Line 189: Error creating key '[dsound]' Line 209: Malformed key '[Network]' Line 209: Error creating key '[Network]' + echo + echo 'Registry entries successfully installed.' Registry entries successfully installed. + '[' yes = auto ']' ++ whoami + '[' s2 = root ']' + '[' -f /tmp/wineinstall.conf ']' + rm -f /tmp/wineinstall.conf + echo + echo 'Installation complete for now. Good luck (this is still alpha software).' Installation complete for now. Good luck (this is still alpha software). + echo 'If you have problems with WINE, please read the documentation first,' If you have problems with WINE, please read the documentation first, + echo 'as many kinds of potential problems are explained there.' as many kinds of potential problems are explained there. + exit 0

1 2

Re: Fix toolbar get style
by Robert Shearman 29 Apr '04

29 Apr '04

>>> maxime.bellenge(a)laposte.net 04/29/04 22:59 PM >>> > When a toolbar receives a TB_GETSTYLE message with wParam=0, the > application expects to get the toolbar style and not the first button > style. This patch fixes eMule 0.42e, now the toolbar is visible. > > ChangeLog > * Fix TB_GETSTYLE to return the style of the toolbar when wParam is 0 Good catch, but I think the original author of the TB_GETSTYLE code got a bit confused. I think it should always return the style of the toolbar (according to MSDN) and should print an ERR or FIXME if wParam != 0, as it is reserved. Could you resubmit with that change? Rob

1 0

RFH: winetest testing
by Dimitrie O. Paun 29 Apr '04

29 Apr '04

Folks, Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe We are trying to test the winetest infrastructure. TIA! -- Dimi.

15 47

Re: Using Windows ODBC drivers
by Dimitrie O. Paun 29 Apr '04

29 Apr '04

On Thu, 29 Apr 2004, Florian Wunderlich wrote: > 5.14.2. Using Windows ODBC drivers > Does anyone actually have any experience of this and anything to add? > > > I do, with Microsoft Access and the JetProxy JDBC. If there's any > interest, I can give you a quick summary on how to set things up. Yes, there is -- if you could provide a patch for section 5.14.2 it would be great. In the past, others have inquired about this issue, so having some documentation on it would be perfect. -- Dimi.

1 0

RegEdit problems
by Krzysztof Foltman 29 Apr '04

29 Apr '04

During deployment of some Linux desktop setup I had a major problem with WINE's regedit. First, I don't seem to be able to edit the (default) values of the keys (if they don't exist already ?). Second, the Modify dialog has Cancel as its default button. Third, there is no Find function. There are also some weird error messages in unexpected places. Is anybody working on it, or should I try it ? Using native regedit is not an option, as our goal is to avoid being a BSA victim completely. Krzysztof (who can't continue the RichEdit before getting the damn desktop to work)

3 3

Re: Re: CVS Invalid path for c:\\Windows
by brettholcomb＠charter.net 29 Apr '04

29 Apr '04

Arrghh! I'll do that. Thank you. Can the message be updated to tell us to look at the dosdevices directory. > > From: Alexandre Julliard <julliard(a)winehq.org> > Date: 2004/04/29 Thu AM 02:02:21 GMT > To: "Brett I. Holcomb" <brettholcomb(a)charter.net> > CC: wine-devel(a)winehq.com > Subject: Re: CVS Invalid path for c:\\Windows > > "Brett I. Holcomb" <brettholcomb(a)charter.net> writes: > > > Yes. I just did again and it doesn't work. Same error. Something got > > broken again I guess. > > Path entries from the config file are no longer used. Check the > contents of your ~/.wine/dosdevices directory. > > -- > Alexandre Julliard > julliard(a)winehq.org >

1 0

Conversion between Clipboard Formats
by Santosh Siddheshwar 29 Apr '04

29 Apr '04

Hi, Does WINE support automatic type conversion between certain kinds of clipboard formats? For e.g. between CF_TEXT and CF_UNICODETEXT and similar types of conversions? Any inputs would be appreciated Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: SetCalendarInfoA and SetCalendarInfoW implementations
by Stefan Leichter 29 Apr '04

29 Apr '04

Am Mittwoch, 28. April 2004 22:38 schrieb Wililam: > I have implemented the SetCalendarInfoA and SetCalendarInfoW API > functions in dlls/kernel/time.c. I am aware that you generally do not like > it when more than 1 thing is changed, but SetCalendarInfoA is not much more > than a > call to SetCalendarInfoW. I am also curious as to why both functions were > listed > as stdcalls rather than stubs when they were both stubs in the source file. > > I have enclosed the patch for the file against the latest source package. > > Here is the ChangeLog entry (I didn't patch the ChangeLog file): > > * dlls/kernel/time.c > William Lahti <computerman413(a)ezrs.com> > > - Implemented the SetCalendarInfoA and SetCalendarInfoW APIs. > > Sincerely yours, > > William Lahti Hello, for my limited understanding you need to convert lpCalData from ascii to unixode in SetCalendarInfoA before calling SetCalendarInfoW Bye Stefan

1 0

CVS Invalid path for c:\\Windows
by Brett I. Holcomb 29 Apr '04

29 Apr '04

I installed from CVS today and when I start wine I get the error below. This happens even with the standard config file that it creates. I've check both my and the config file and can't find any errors. I'm including the c drive part of the config file. Any ideas why this is telling me this? Thanks. Error: Invalid path L"c:\\Windows" for L"windows" directory: does not exist. Perhaps you have not properly edited your Wine configuration file (/home/brett/.wine-cvs/config) Config file excerptL [Drive C] "Path" = "fake_windows" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" -- Brett I. Holcomb

3 4

[PATCH] Exception c0000005 opening JPEG files in FoxPro
by Sergio López 29 Apr '04

29 Apr '04

Hello, When Visual FoxPro (tested with versions 6 and 7, wine-20040408) tries to open a JPEG file, it crash showing a c0000005 exception. The backtrace of winedbg shows the following API calls: 0 0x407c0e1d (CURSORICON_SimulateLoadingFromResourceW+0x8d(filename=0x403e63b0, fCursor=0x1, res=0x4074a208, ptr=0x4074a20c) [cursoricon.c:512] in USER32.DLL) (ebp=4074a1d0) 1 0x407c1d0d (CURSORICON_Load+0x28d(hInstance=0x0, name=0x403e63b0, width=0x20, height=0x20, colors=0x1, fCursor=0x1, loadflags=0x50) [cursoricon.c:799] in USER32.DLL) (ebp=4074a21c) 2 0x407c4ba0 (LoadImageW+0xb0(hinst=0x0, name=0x403e63b0, type=0x2, desiredx=0x20, desiredy=0x20, loadflags=0x50) [cursoricon.c:2133] in USER32.DLL) (ebp=4074a258) 3 0x407c4a8f (LoadImageA+0x14f(hinst=0x0, name=0x4074a370, type=0x2, desiredx=0x0, desiredy=0x0, loadflags=0x50) [cursoricon.c:2074] in USER32.DLL) (ebp=4074a334) 4 0x407c39b5 (LoadCursorFromFileA+0x45(name=0x4074a370) [cursoricon.c:1649] in USER32.DLL) (ebp=4074a358) 5 0x0053b8c5 (vfp7.exe.EntryPoint+0x13a8c5 in vfp7.exe) (ebp=4074a5e8) 6 0x00490d4b (vfp7.exe.EntryPoint+0x8fd4b in vfp7.exe) (ebp=4074a78c) 7 0x004abd03 (vfp7.exe.EntryPoint+0xaad03 in vfp7.exe) (ebp=4074a928) 8 0x00436a8d (vfp7.exe.EntryPoint+0x35a8d in vfp7.exe) (ebp=0000002b) The last function (CURSORICON_Simulate...) has a bug that makes the exception when the opened file isn't in RIFF format. Returning with fail when the file is in other format avoids the exception, and Visual FoxPro continue the execution loading correctly the image. Best regards, -- Sergio López koro(a)menteslibres.org

1 0

Re: SetCalendarInfoA and SetCalendarInfoW implementations
by Vincent Béron 28 Apr '04

28 Apr '04

Le mer 28/04/2004 à 16:38, Wililam a écrit : > I have implemented the SetCalendarInfoA and SetCalendarInfoW API > functions in dlls/kernel/time.c. I am aware that you generally do not like it > when more than 1 thing is changed, but SetCalendarInfoA is not much more than > a > call to SetCalendarInfoW. I am also curious as to why both functions were > listed > as stdcalls rather than stubs when they were both stubs in the source file. There are two levels of stubs: "real stubs", and dummy functions. stub is used in a spec file when there's no implementation whatsoever of a given function, not even a dummy one. If an app tries to use that function, it results in a segmentation fault (and usually a crash to the debugger). In the case of SetCalendarInfo{A,W}, some dummy function existed, so they were callable by an app without it crashing (hence the stdcall declaration). Of course it wouldn't actually do much, that's what your implementation is for. The "stub" in the FIXME is to remind people that some function is not really there, although it's been called. The line is difficult to draw between the two types of stub: some apps will crash with a real stub and need a dummy one, some other ones will crash with a dummy one and will route around real stubs. Usually it's done on a case by case basis. > > I have enclosed the patch for the file against the latest source package. > > Here is the ChangeLog entry (I didn't patch the ChangeLog file): Alexandre commits all the changelog entries to the ChangeLog file when there's a release. Your way to specify the changelog is the correct one. Vincent

1 0

Re: [Darwine] compiling wine on Darwin/MacOS X 4/10
by Pierre d'Herbemont 28 Apr '04

28 Apr '04

Emmanuel, I know that I did this hack, but it is not really a good one. Since it corrupts the stack (you get a stack frame error at every signal caught). So this issue would need to be a bit more investigated. But it is required for now, without it you can't launch an App. Pierre PS: its good to see that someone takes time to send those patches and work ;) So thanks for that. On 15 avr. 04, at 23:36, emmanuel maillard wrote: > Hi, > > an other patch for darwin/ppc > > changelog > Add darwin/ppc support in THREAD_InitStack > > emmanuel > > <kernel_thread.diff>

2 1

Re: [D3D8] Many Improvements
by Duane Clark 28 Apr '04

28 Apr '04

This commit to CVS doesn't compile for me: http://www.winehq.org/hypermail/wine-cvs/2004/04/0346.html The part the doesn't compile is the replacement of glCompressedTexImage2DARB() - glCompressedTexImage2DARB(gl_target, - ... + glCompressedTexImage2D(gl_target, + ... The old name compiled fine for me; changing it back fixes the compile. This is on RH7.3.

2 1

Re: exec-shield patch take 6
by Mike Hearn 28 Apr '04

28 Apr '04

Go Mike! Good to see this work finally turn into a patch against CVS :) On Wed, 2004-04-28 at 19:02 +0900, Mike McCormack wrote: > Description: > > This patch allows platforms using exec-shield patch against the Linux > kernel (eg. Fedora Core) to run Wine without disabling exec-shield. It also fixes the prelink case, right? :) > + vars.pe_size = 0x01000000; 0x1000000? Are you sure you didn't drop a zero somewhere? That's only 16mb.... we probably want something like 0x40000000 which reserves a gig of address space. Some very large game installers can in fact get close to this level, and as it's just non-backed address space we're reserving (for a shor time) there's no real reason to be stingy. > +/* > + * The _start function is the entry and exit point of this program > + * > + * It calls wld_start, passing a pointer to the args it receives > + * then jumps to the address wld_start returns after removing the > + * first argv[] value, and decrementing argc > + */ > +void _start(void); > +__asm ( > + ".align 4\n" > + "\t.global _start\n" > + "\t.type _start,@function\n" > +"_start:\n" > + "\tcall wld_start\n" > + "\tpush %eax\n" > + "\txor %eax,%eax\n" > + "\txor %ebx,%ebx\n" > + "\txor %ecx,%ecx\n" > + "\txor %edx,%edx\n" > + "\tret\n" > +); You know, I wonder if we couldn't make this simpler ... well, shorter, by assuming the stack is already set up and the main binary is mapped correctly, then being careful not to disturb the linker entry stack just reserve the areas we need with a few mmap syscalls, map in the real dynamic linker and do a jump. In effect, rather than repeat the work the kernel already did for everything but the real dynamic linker, insert a small shim between them. Thoughts? thanks -mike

3 2

Re: Add stub function HWND GetConsoleWindow()
by Dmitry Timoshkov 28 Apr '04

28 Apr '04

"Ylia K" <k_ilya(a)ukr.net> wrote: > * dlls/kernel/kernel32.spec, dlls/kernel/console.c, include/wincon.h > Ilya Korniyko <k_ilya(a)ukr.net> > Add stub function HWND GetConsoleWindow() > > It is for excelent file manager FAR Manager (www.rarlab.com). > FAR Manager doesn't run without this patch. > With patch it runs - good on winXP, very bad on winME. I'm wondering how your patch works at all, the call should smash the stack since it misses WINAPI modifier. -- Dmitry.

3 3

Re: SetFocus
by Alexandre Julliard 28 Apr '04

28 Apr '04

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Trying to set focus to an invisible window should fail I don't think that's correct, setting focus to an invisible window seems to work fine on Windows. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: RPCRT4: reimplement UuidCreate() with Win32 APIs (resubmit)
by Juan Lang 28 Apr '04

28 Apr '04

Alexandre wrote: > I don't think rpcrt4 should depend on iphlpapi, it > doesn't on Windows AFAICS. Right, rpcrt4 precedes iphlpapi. However, iphlpapi was created to allow you to do things that were platform-specific and often undocumented. In this case, rpcrt4 is trying to get the MAC address. On Windows 9x, you used to use WsControl for this, and this calls the appropriate VxD. Wine's WsControl forwards to iphlpapi instead (on Win9x iphlpapi calls WsControl). On Windows NT, you use a DeviceIoControl on the network device driver. Wine doesn't implement any of these. Wine could use ioctl on a UNIX fd, but I doubt this is what Hans wants to do, since he's trying to implement this using Win32. It appears to me that this is the most straightforward way to get the MAC address in Wine (but since I wrote iphlapi, you could count on me saying that ;) ) --Juan __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

Re: RPCRT4: reimplement UuidCreate() with Win32 APIs (resubmit)
by Alexandre Julliard 27 Apr '04

27 Apr '04

Hans Leidekker <hans(a)it.vu.nl> writes: > Anything wrong with this one? > > Changelog: > Reimplement UuidCreate() with Win32 APIs. I don't think rpcrt4 should depend on iphlpapi, it doesn't on Windows AFAICS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 2 Fatal Problems With Winesetuptk-0.73 (BOTH Sourceforge Release Formats)
by Ivan Leo Murray-Smith 27 Apr '04

27 Apr '04

If you build a binary for older versions of Linux, let me know and I'll put your binary on the sourceforge page. AFAIK winesetuptk will only work correctly with the itcl/tck libs shiped in the tarball. Ivan.

1 0

Winsock help...
by António Serra 27 Apr '04

27 Apr '04

Hi all! I'm porting a windows application to Linux using the winelib. I created a project with KDevelop and include all ( at least I think all ) the .dll.so needed by my project. After compiling a linker error message appears, saying that /windows/D/ HICOD2000/j2kserver/j2kserver/kdu_server.cpp:2894: undefined reference to `WSAWaitForMultipleEvents' . It happens that I included the ws2_32.dll.so in my project. Am I missing something? TIA -- ______________________ António Serra aserra.wine(a)iol.pt ______________________

2 1

Re: GetTimeZoneInformation patch
by Rein Klazes 27 Apr '04

27 Apr '04

On Tue, 27 Apr 2004 10:03:13 -0400, you wrote: > I was looking through the source code and noticed a FIXME for the > GetTimeZoneInformation API in dlls/kernel/time.c saying that the function > needed to return a different value if Daylight Savings Time was in effect. I > implemented that feature, and also made the function return the proper value > if DST was not in effect for the version being simulated. > > I have enclosed the patch for the file against the latest source package. > > Here is the ChangeLog entry (I didn't patch the ChangeLog file): > > * dlls/kernel/time.c > William Lahti <computerman413(a)ezrs.com> > > - Fixed return values in GetTimeZoneInformation Three remarks: - you are using ftime() of which my man page says: | These days the contents of the timezone and dstflag fields are undefined. and | This function is obsolete. Don't use it. Have a look at the implementation of GetDaylightFlag() or use it directly. - You state that on NT, 2K and XP the return code is TIME_ZONE_ID_UNKNOWN when the daylight saving time is not in effect. This is only true if the transition dates are undefined. This is true in the current implementation, but those transition dates are a bigger FIXME then the correct return value. - I am not sure if it is worth the trouble to be so correct for windows 9x. The NT return value is not impossible under win9x and unless there is an application that depends on it, Wine defaults to the NT behavior. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: MDI fix attempt
by Dmitry Timoshkov 27 Apr '04

27 Apr '04

"Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > Applying this patch makes MDI Window menu behave as follows: > > - if no child windows are present, no separator is added (or it is > removed if it was present before) > - if any child windows are present (and visible), a separator is added > after last item of the original Window menu (unless it was already there) Is there a real bug you are trying to fix? When I last time worked with MDI code including Window menu handling I did a lot of tests under Windows. Did you? -- Dmitry.

2 6

Re: Winetest: outstanding issues (USING)
by Dimitrie O. Paun 27 Apr '04

27 Apr '04

Now for the second installment: USING (Feri) ----------------------- A. winetest Winetest will have to support a new option -B <filename> This will add a new section to the report, just before the test results, called "Build Info". The body of this section will be read from <filename>, with each time indented (say 4 spaces), and a blank line to end it (for neatness). B. Dissect & gather Need only recognize the "Build Info" section as optional, and ignore it for now. Maybe dissect should do that as a rule, ignore sections it doesn't understand. This way we can easily add more data in the future, without needing to constantly patch dissect. Such sections would have all lines indented, and would end with a blank line. BTW Feri, can we indent the body of our current sections? Would that break stuff? It would be nice to, would make the report more readable. We should be more forgiving with the parsing, like HTML is. The idea would be: "we should look only for stuff that we need for the report, additional stuff should be ignored. Moreover, non-essential stuff should be optional, and if not present/parsed, don't display". -- Dimi.

4 8

Fwd: Re:SpecOpS Labs
by Ivan Leo Murray-Smith 27 Apr '04

27 Apr '04

I asked project davied if they know what use of LGPL code involves, and if the're using wine code, I got the following answer. The impression I have is that they are using major parts of wine. They claim they will fully comply with the LGPL. Here is the full email they sent me. > Good Evening Mr. Smith > > > Thanks for your email; We appreciate your taking the time to delve into > Project David. We feel certain that the closer that you look at the project > the more comfortable you will be with it. > > Our overall purpose of the project is to encourage consumers to use Linux. > Our David Linux/Win Bridge software is simply a product to facilitate the > transition to Linux. Our Linux/Win Bridge software is one of multiple > components, which comprise our OS platform. In the future we will release > another component, which is a set of tools that will encourage developers to > write native Linux applications. > > The David software is a joint development effort between De La Salle > University and SpecOpS Labs. Our Chief Technical Officer is Mr. Peter > Valdez. As you may know Mr. Valdez is the founder of Tivoli Systems, which > is now a multi billion-dollar flagship product of IBM. > > The code for our Windows/Linux Bridge is a hybrid of code, including our own > proprietary code, and code from several open source projects. For now we > are keeping the exact nature of our code under wraps until our first release > of David. We are not using pirated or stolen code from Microsoft or any > other source. As stated we are not disclosing the nature of our code or our > exact methodology for running Windows Apps on Linux, this is for competitive > and other reasons. However, a good deal of our success is attributed to our > innovative methodology in assembling together open source code, proprietary > code that we have written/purchased, and freeware. In the future, once we > disclose how we have done this, then Im sure a number of developers will be > kicking themselves in the rear end for not having thought of this > themselves. > > We do encourage the open source movement and we will comply with the GNU > LESSER GENERAL PUBLIC LICENSE. > > Our website is currently under construction, the data (*especially the > technical data) on the website for the most part is not current and in some > cases is up to 20+ months old. We are now in the process of doing a major > overhaul of the site, which we expect to be completed in a few weeks. *The > technical data on our web site concerning David, is outdated and in some > cases a competitive smoke screen. We appreciate your comments on the WINE > Project and we have no intention of misrepresenting the WINE. Therefore, we > are now consulting our English-technical writers and the Filipino - > designers/developers of David to ensure that there are no mistakes in the > translation. Until we can update the website we have disabled the links to > both our technical and competitive data. Hopefully, the development > community wont get wrapped around the axle about David, and will withhold > judgment until David is released. > > So far as our product goes we just completed our prototype, which has been > in the making for quite some time. Our first release will be issued before > the end of 2004; we expect to start Beta Testing in about 4-5 months. On 22 > April we held a press conference at De La Salle University. During the press > conference we demonstrated our prototype to more than 30 members of the > local and international media. During the demo we ran Macromedia Flash, and > MS Office on our Windows/Linux Bridge without a hitch. What you read in the > media was primarily the result of the press conference/demo. David is not a > hoax or vaporware, but we're not going to make any further claims about > David at this point, We prefer to let our software do our talking for us. > > > FYI: We are now a publicly traded company, our ticker symbol is SPLMF, you > can view it on any major financial website such as Merrill Lynch: > http://askmerrill.ml.com/markets_chart/1,2260,,00.html?q=SPLMF > > > > Thanks > > > > > Customer Service > SpecOpS Labs > Summit One Office Tower > Unit 23-H, 530 Shaw Blvd > Mandaluyong City, Metro Manila, Philippines > > Office 63 2 532-7854 > Fax 63 2 532-5875 >

7 10

winealsa fails the winmm test
by Francois Gouget 27 Apr '04

27 Apr '04

I'm not having much luck with sound this week-end :-( First there was the crash in ALSA_WaveInit() (an old bug apparently), but now the winmm test either gets stuck or crashes. When it gets stuck it's because I get: trace:wave:wodUpdatePlayedTotal dwPlayedTotal=21987 dwWrittenTotal=22050 delay=63 trace:wave:wodPlayer_NotifyCompletions still playing 0x4069fd1c (22050/21987) trace:wave:wodPlayer waiting 2ms (7,2) trace:wave:wodUpdatePlayedTotal dwPlayedTotal=21987 dwWrittenTotal=22050 delay=63 ... So the problem is that everything has been played but because snd_pcm_delay() keeps returning 63, dwPlayedTotal never reaches the 22050 that would signal the completion of the first tone. Now it seems like snd_pcm_delay() should return 0 after a while so this looks like an Alsa bug (0.9.6). Is this a known bug? Is there a way to work around it? (besides commenting out the call to snd_pcm_delay()) And when I don't get into the above infinite loop it's because I've crashed before with an Alsa assertion: trace:wave:wodPlayer waiting 7ms (7,4294967295) trace:wave:wodUpdatePlayedTotal dwPlayedTotal=11781 dwWrittenTotal=17184 delay=5403 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4069fd1c.17184[22050] trace:wave:wodPlayer_WriteMaxFrags 1065 dwLength=2433 toWrite=110 0010:Call ntdll.RtlAcquireResourceShared(4037c168,00000001) ret=404e0751 0010:Ret ntdll.RtlAcquireResourceShared() retval=00000001 ret=404e0751 0010:Call ntdll.RtlReleaseResource(4037c168) ret=404e08ae 0010:Ret ntdll.RtlReleaseResource() retval=00000000 ret=404e08ae 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 wine-kthread: pcm.c:5899: snd_pcm_mmap_commit: Assertion `frames <= snd_pcm_mmap_avail(pcm)' failed. The interesting things are that wwo->write points to snd_pcm_mmap_writei(). This assertion would seem to imply that we are writing too much stuff at once? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

2 1

2 Fatal Problems With Winesetuptk-0.73 (BOTH Sourceforge Release Formats)
by Kenny Love 27 Apr '04

27 Apr '04

In the Bugzilla system, including the search page, there is no mention of Winesetuptk, so I can't tell whether the following bugs are new to you. These two problems are of considerable import to aspiring Wine users, particularly if they are running Red Hat Linux 6.2 or equivalent or older (for the first item, Red Hat Linux 7.x or equivalent might also be affected). 1. The rpm'ed Winesetuptk binary currently posted on the Sourceforge site, winesetuptk-0-73.i586.rpm, aborts on startup on a Red Hat Linux 6.2 system with the message "winesetuptk: /lib/libc.so.6: version `GLIBC_2.3' not found (required by winesetuptk)". I suspect this means that the binary (maybe the Tcl/Tk/ITcl) is dynamically linked to glibc 2.3, but Red Hat Linux 6.2 can only be easily upgraded to glibc 2.1.3-21; even Red Hat Linux 7.3 easily upgrades only to glibc 2.2.5-44, so this might prohibit most Red Hat Linux installations older than 8.0 from running this binary. 2. The scripts in the Winesetuptk tarball currently posted on the Sourceforge site, /winesetuptk-0-73.tar.bz2, hang. When run "as scripts directly" on a Red Hat Linux 6.2 system with Tcl 8.0.5-35 and ITcl 3.0.1-35 installed, after the program opens a window stating "Autodetection in Progress", an error notice appears stating that map is not a legal argument to the string function ("Error: bad option "map": must be compare, first, index,"...). After the notice's "Ok" button is pressed, the error notice box disappears, but the program quietly hangs, ignoring attempts to close the remaining windows. Bash's kill command, probably unknown to the novice, is required to exit the comatose program. Also, on the launching shell window appears the message "CBase::AutoConf:GetWinInstalls: unable to grep /dos/c/msdos.sys: child process exited abnormally ". My /dos/c/ directory contains my dual-boot Windows 3.1 system. In the tcl8.3.2 subdirectory, the "changes" file lists, between the "8.1 final" and "8.1.1" headers, a "new features" entry dated 5/3/99 mentioning adding Jeff Hobbs' patches introducing, among others, a map argument to the string function. The Sourceforge Winesetuptk-0.73 release note states that at version 0.34b, all was successfully converted from requiring Tcl 8.4 to using Tcl 8.0, so this map call appears to be a small overlooked mouse with a show-stopping roar. I lack Tcl programming experience, but the stack trace (see below) and 'grep'-ing the source tree for potential "string_ map" calls seems to implicate "winesetuptk-0.73/Enable8.0Compatibility.tcl", line 42 as the culprit; it looks like there's no if-clause to handle $aCmd == "map". Here's the stack trace: bad option "map": must be compare, first, index, last, length, match, range, tolower, toupper, trim, trimleft, trimright, wordend, or wordstart while executing "string_ map {{${WinDir}} windows} {${WinDir}/system}" ("eval" body line 1) invoked from within "eval string_ $aCmd [list $aStr] $args" (procedure "string" line 26) invoked from within "string map [list {${WinDir}} $WinDir] $SystemDir" (object "::ObjBase" method "::CBase::AutoConf:GetWinInstalls" body line 74) invoked from within "AutoConf:GetWinInstalls $Drives" (object "::ObjBase" method "::CBase::AutoConf" body line 39) invoked from within "$pObjBase AutoConf" ("GEN_NEW" arm line 6) invoked from within "switch [$pObjBase AccessCfgData GET_KEY_VALUE_BY_NAME Cfg WhatToDo] { GEN_NEW { CMsgDialog ObjWaitMsg . .wait_msg "WineSetup" "Autodetection..." (object "::ObjScrFileLoc" method "::CScrFileLoc::SetWineData" body line 2) invoked from within "SetWineData" (object "::ObjScrFileLoc" method "::CScrFileLoc::SetResult" body line 58) invoked from within "::ObjScrFileLoc SetResult NEXT" (in namespace inscope "::CBaseScr" script line 1) invoked from within "namespace inscope ::CBaseScr {::ObjScrFileLoc SetResult NEXT}" invoked from within ".f_scr.b_next invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tkButtonUp" line 8) invoked from within "tkButtonUp .f_scr.b_next" (command bound to event) I'm going to try compiling the Winesetuptk-0.73 source from the tarball on my system; hopefully that will produce a >working< binary dynamically linked to glibc 2.1.3-21. Considering that most aspiring Wine users, (Remember: Many, perhaps most of those are new to Linux itself.), are currently steered by the Wine documentation to use the Winesetuptk program with its nice, friendly GUI, those who took the time-honored route of putting a Linux installation from second-hand CD's on an older, expendable PC (which often limits one to a 6.2/7.0 version or less because 2.4 kernels can thrash too much on old hardware to be useful) may be in for a big suprise when they try to graphically configure their wine.conf file. To summarize, the rpm binary release as-is probably won't start for Linux versions older than Red Hat Linux 8.0 or equivalent and the tarball release as-is hangs deviously when run "as scripts directly" on systems with Tcl 8.0, possibly 8.1.0. By the way, that rpm should have refused to install because the program required a higher version glibc than my Linux system possesses, shouldn't it? Thanks! Kenny A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing. G. B. Shaw

1 0

Alignment testing
by Hans Leidekker 27 Apr '04

27 Apr '04

Hi, kernel/tests/generated.c currently shows one failure when the executable is compiled with MinGW. Investigation shows that MinGW and GCC differ when it comes to alignment of doubles (i.e. a 64 bit wide type). I have constructed the test below that shows the difference between MinGW and GCC. My question is, could someone compile this with MSVC >= 6, run it, and report the outcome here? Thanks, -Hans

3 4

GetDriveTypeW crash
by Robert Reif 27 Apr '04

27 Apr '04

I'm having problems with several programs crashing in GetDriveTypeW. I recently did a fresh install from source with tools/wineinstall so it may be a config problem. Any ideas where to start? Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x404944b0). In 32-bit mode. 0x404944b0 (GetDriveTypeW+0xac [volume.c:110] in KERNEL32.DLL): movw 0x0(%edi),%ax 111 { Wine-dbg>bt Backtrace: =>0 0x404944b0 (GetDriveTypeW+0xac(root=0x0) [volume.c:110] in KERNEL32.DLL) (ebp=4081e8b8) 1 0x40493294 (GetVolumeInformationW+0x300(root=0x0, label=0x0, label_len=0x0, serial=0x0, filename_len=0x4081fb34, flags=0x4081fb38, fsname=0x0, fsname_len=0x0) [volume.c:683] in KERNEL32.DLL) (ebp=4081f7b8) 2 0x40493551 (GetVolumeInformationA+0x91(root=0x0, label=0x0, label_len=0x0, serial=0x0, filename_len=0x4081fb34, flags=0x4081fb38, fsname=0x0, fsname_len=0x0) [volume.c:780] in KERNEL32.DLL) (ebp=4081f7fc) 3 0x01004012 (PPView97.exe..text+0x3012 in PPView97.exe) (ebp=4081fb48) 4 0x01004c0c (PPView97.exe..text+0x3c0c in PPView97.exe) (ebp=4081fc8c) 5 0x0100577f (PPView97.exe..text+0x477f in PPView97.exe) (ebp=4081fdb0) 6 0x01005970 (PPView97.exe..text+0x4970 in PPView97.exe) (ebp=4081fec4) 7 0x01005aa8 (PPView97.exe..text+0x4aa8 in PPView97.exe) (ebp=4081ff2c) 8 0x404773ca (start_process+0xf2(arg=0x0) [process.c:785] in KERNEL32.DLL) (ebp=4081fff4) 9 0x4002921d (wine_switch_to_stack+0x11 in libwine.so.1) (ebp=00000000)

2 1

Re: Make dlls-kernel-tests-file.c work on Windows 95 and XP.
by Alexandre Julliard 27 Apr '04

27 Apr '04

Jakob Eriksson <jakov(a)vmlinux.org> writes: > +static int test_win9x_based() > +{ > + OSVERSIONINFOEX ver; > + > + ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > + ok( GetVersionEx ((OSVERSIONINFO *) &ver), " --- Can't get OS version.\n" ); > + if ((4 == ver.dwMajorVersion && 0 == ver.dwMinorVersion && 1381 == ver.dwBuildNumber) > + || ver.dwMajorVersion >= 5) > + { > + return 0; > + } > + > + return 1; You should not do version checks in tests, the checks should be based on the features we are testing. Otherwise the results are going to depend on the Windows version that Wine is configured for, which is the wrong thing to do since the behavior of the Wine code in that case does not depend on the version. -- Alexandre Julliard julliard(a)winehq.org

2 3

Hmm.. something strange in winetest reporting
by Jakob Eriksson 26 Apr '04

26 Apr '04

Check out http://test.winehq.org/data/20040425-1000/ OSR2 shell32:string. It says "0", but if you click, there seems to be some kind of error. Is it the test output somehow erratic, or is the log parser doing something bad? regards, Jakob

2 1

Re: msvcrt: compatibility fixes
by Alexandre Julliard 26 Apr '04

26 Apr '04

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > ChangeLog > Fix the _WCHAR_T_DEFINED/_WCHAR_T_DEFINED sentries for > compatibility with the MSVCRT ones. Unfortunately _WCHAR_T_DEFINED is also used by gcc in stddef.h. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: String constification
by Dmitry Timoshkov 26 Apr '04

26 Apr '04

"Francois Gouget" <fgouget(a)free.fr> wrote: > We find the same issues with an added twist: now that we can use > literals we can write things like: > > const char* str = "String literal"; > > However this is slightly different from: > > static const char* str[] = "String literal"; > > The difference is that in the first case sizeof(str) returns 4 (on 32 > bit machines<g>) while in the latter we get 15. Some of our code relies > on this so care must be taken when converting the latter to the former. My understanding of this is that in the first case you declare a const pointer and hope that a compiler is smart enough to place a pointed by it object into a read only section, while in the second case you explicitly say to a compiler to place the whole object into a read only section. I prefer to not rely on a compiler's good will. -- Dmitry.

4 5

Re: RPCRT4: make the on-wire protocol Windows compatible
by Steven Edwards 26 Apr '04

26 Apr '04

Hiya Filip, You should leave this part out. I dont think Alexandre will remove it for you. +#ifndef __REACTOS__ __TRY { - if (func) func(&msg); + if (func) func(msg); } __EXCEPT(rpc_filter) { /* failure packet was created in rpc_filter */ } __ENDTRY +#else + if (func) func(msg); +#endif Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

Re: Remove debugmsg from guides
by Ivan Leo Murray-Smith 26 Apr '04

26 Apr '04

> Please don't do that, we've been over this a thousand times, > let's not rehash it. Do either or, otherwise you end up > confusing Alexandre's script, etc. Inlining is prefered > for a lot of reasons, so if you're using a decent mail client > (and you seem to be), just inline it and don't look back :) I'm not using an email client, my ESP only allows that if I connect via their dial-up service. That's why I can't have text/plain attachments. Ivan.

1 0

Re: Remove debugmsg from guides
by Dimitrie O. Paun 26 Apr '04

26 Apr '04

On Mon, 26 Apr 2004, Ivan Leo Murray-Smith wrote: > attaching as text/plain can't be done for various reasons, so I'll both attach > and inline. Please don't do that, we've been over this a thousand times, let's not rehash it. Do either or, otherwise you end up confusing Alexandre's script, etc. Inlining is prefered for a lot of reasons, so if you're using a decent mail client (and you seem to be), just inline it and don't look back :) -- Dimi.

1 0

Re: RFH: RPC patch
by Ivan Leo Murray-Smith 26 Apr '04

26 Apr '04

Running server and client with wine CVS current returns Hello Implicit RPC World! but I can't test with your patch because it doesn't cleanly apply against the current CVS code. Ivan.

1 0

service.cgi: script generation
by Dimitrie O. Paun 26 Apr '04

26 Apr '04

Currenly we send a script to run and execute all published versions that we have. This is currently problematic, because an error in one causes the abort the entire script. Moreover, releases may no arrive at the server at the same time, and if we're going to receive the poll event in between them, we'll miss some of them. What we need to do is to ask the client to execute one thing at a time. Problem is that we need to keep track of what the client did execute already. Here's a way to do it without storing state on the server side, which is problematic. We need to introduce three new cookies: build_id: the current build ID that we execute. It's going to be something like '200405031000' current: the name of the test that was just executed history: a comma separated list of filenames that where already executed by the client for this current build. It's going to look like so: 'wine-200405031000-paul-mingw.zip,wine-200405031000-kevin-mingw.zip' The algorithm is simple: if $build_id != $current_build_id $build_id = $current_build_id $history = "" else $history = $history . "," . $current $current = pick_next_test($history) # send script to run $current, and to set the values of the # three cookies to the values in our variables where: pick_next_test picks the next test to run from the pool of tests avaiable for our current build, so that it doesn't appear in $history Comments? -- Dimi.

1 0

Re: Font selection - please review
by Shachar Shemesh 26 Apr '04

26 Apr '04

Hi Dirk, First of all, thank you for the reference. Regarding the missing flag to TranslateCharsetInfo - My VisualStudio 6 MSDN DVD (Latest that came up for that version - dated October 2001) does not have this flag mentioned. This means either that the flag was not present at that time, or that it was present but they forgot to mention it (has happened to me before). The latest MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unico…) does mention it, and claims it's available on Windows 2000 (like you said). I guess this is anyone's guess what this means as far as when you can use it. Fortunetly for Wine, we don't care when it was introduced. If Wine has it, we can use it. At least for code written by us, that rule is fine. So, thank you very much for the good advice. Are you a wine user that needs this flag, or did you just happen to see my email when you were investigating a Win32 problem? Shachar Dirk Luetjens wrote: > Hello Shachar Shemesh, > > sorry for the lost context. Your mail I replyed to, is available at > > http://www.winehq.com/hypermail/wine-patches/2002/11/0221.html > > I know, that the wine project is totally unrelated to any windows dll. > I thought it would be better to mention, that this additonal flag for > TranslateCharsetInfo is not available in a specific windows version, > since the wine project tries to implement the WIN32 interface, and it > should behave as close as possible to the original one. Judging from > the code in > > http://source.winehq.org/source/objects/font.c#L1849 > > this additional flag is not yet implemented in wine. I can not tell > you when it was introduced into WIN32 itself. The MSDN says something > about WIN2000, but it isn't available on my WIN2k installation. > > Dirk > > > Shachar Shemesh wrote: > >> Hi Dirk, >> >> Judging from the email address you used to send me this email, we are >> talking about a fairly old post. Can you please direct me to the some >> context regarding what was my post exactly? A link with the post in >> question would be very helpful. >> >> Also, I hope you do realize that my post was on a Wine mailing list, >> which means that the functions there are totally disjointed from any >> particular Microsoft version or DLL. >> >> Many thanks, >> Shachar >> >> Dirk Luetjens wrote: >> >>> Hi Shachar Shemesh, >>> >>> I came across your post while researching a problem I had during >>> application development under windows. >>> >>> While digging in the MSDN I found another function that deals with >>> this problem: TranslateCharsetInfo >>> >>> --- >>> TranslateCharsetInfo function translates based on the specified >>> character set, code page, or font signature value, setting all >>> members of the destination structure to appropriate values. >>> --- >>> >>> and for the flag parameter: >>> >>> --- >>> TCI_SRCLOCALE Windows 2000: Source (that is, lpSrc) is the LCID or >>> LANGID of the keyboard layout. If it is a LANGID, the value is in >>> the low word. >>> --- >>> >>> The destination of the translation is a CHARSETINFO structure, where >>> one entry is the charset. >>> >>> I had problems using this parameter, since it isn't implemented in >>> the gdi version I use (VS6, gdi32.dll 5.00.2195.6898). I can only >>> find the definition in the newer .NET studio headers. But perhaps >>> this is a possible inclusion point for your function. >>> >>> Best regards >>> Dirk Luetjens >>> >> >> > > -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

1 0

Re: winmm wave test
by Robert Reif 26 Apr '04

26 Apr '04

Francois Gouget wrote: > Some Windows sound drivers allow wild frequencies such as the 2MHz > one. > Is this a windows driver bug? Is the test really valid and it's just finding a real bug in the windows driver for that specific sound card? I know it makes the test fail on bad windows drivers but is that bad?

2 4

email add
by kosta 26 Apr '04

26 Apr '04

1 0

Re: Add some functions to msvcrt.dll
by Dmitry Timoshkov 26 Apr '04

26 Apr '04

"kata 198" <kata198(a)hotmail.com> wrote: > Changelog: > Add some functions to msvcrt.dll If you could make your patch behave according to current locale that would be really nice. Otherwise it's not acceptable. Also, please make sure that your formatting style is at least consistent, and even better conforms to the formatting style of the file you are editing. -- Dmitry.

1 0

RFH: MDI Window menu fix
by Krzysztof Foltman 25 Apr '04

25 Apr '04

I've just finished fixing the behaviour of Window menu in MDI applications. However, I'm not sure if it won't cause some other MDI applications to work incorrectly. So, if you have some time and MDI apps to play with (regardless if they worked correctly before or not), check this out and tell me if I've fixed or broken the Window menu. http://www.winehq.org/hypermail/wine-patches/2004/04/0414.html Krzysztof

1 0

Re: abnt2 keyboard patch
by Mauro Carvalho Chehab 25 Apr '04

25 Apr '04

Rafael, With your patch, the '\' key on the main keyboard will stop to work on the ABNT2 Keyboard, at least on the ABNT2 keyboards I've tested (some low valued keyboards and also Compaq keyboard). On ABNT2 keyboards, before the 'z' key there is the '\' key and the layout has to reflect that. That was the situation before 200303xx version. That changes was required in order to support that key. Had you tested it? If it works on your keyboard, may be you has some ABNT2 variant. I think it would be better to find another solution for the numeric keyboard that doesn't break the main keyboard. Mauro Chehab > Date: Fri, 16 Apr 2004 10:52:01 -0300 > From: Rafael Ávila de Espíndola <rafael.espindola(a)ic.unicamp.br> > To: wine-devel(a)winehq.org > Subject: Re: abnt2 keyboard patch > > > That's why I said that it's an X11 bug and we can do nothing about it. > > > > Please resubmit the patch without that part. > Attached. I will contact xfree and try to fix the rest of the problem. > > Thanks. > > > Dmitry. > Rafael >

2 1

RFH: RPC patch
by Filip Navara 25 Apr '04

25 Apr '04

Hi, for about week and half I was working on a patch that makes Wine RPC runtime communicating with the Windows one. Now I'm almost done with the work and I need help from someone who can test the patch under Wine. (I was doing all my testing under regular Windows.) If someone will be willing to help me testing it, the patch is at www.volny.cz/xnavara/rpc/ along with a test programs. Regards, Filip

1 0

Wine bug with MFC/C++?
by greensh＠knology.net 25 Apr '04

25 Apr '04

It appears that Wine cannot use tmpfs... so far my testing only works using swap :o( which I do have enabled at home and it crashes. At work I have a 500MB swap space and the same exact program does not crash there. It's not convenient for me to run swap at home, so does anyone know a fix for this? The code seems to require approx 500MB free memory. Since I only have 500MB RAM, I setup tmpfs on /tmp. But wine doesn't seem to use any of it. Shaun

1 0

winetest.exe output from Windows 95
by Jakob Eriksson 25 Apr '04

25 Apr '04

By killing processes left and right, I managed to get a 50 - megabyte log. Maybe in the future we should link in bzip2 in winetest.exe to compress logs before submitting? regards, Jakob

2 2

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