- wine-devel - winehq.org

Re: Mysterious icon-change
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

I get the IE icon to stay the same in quick launch, but all the desktop icons are messed up. For example, I have m$ cart trial installed, and the link to my computer (You don't have it on the desktop in win2k3 so I linked it) has the m$ cart icon, midtown madnesss trial has the icon of starlancer, motocross madness 2 had the icon of age of empires expantion, monster truck madness trial has the icon of age of empires the conquerors, age of empires has the icon of max paynem and the few icons are OK. Now this is a test box where (For a while) I can install/format/break configuration/change OS as much as I like, but someone in a production environment (Or even on a pc used for normal use from time to time) may find this irritating. Apart from this, the directx tests are very impressive. I'm posting the test results to wine-tests-results.

1 0

Re: Default printer and patch management
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

For all wine files that contain code written by others: >a) Just keep them "secret" until I get paid, at which point I send them >in all together. Pros: Simple, Cons: people might duplicate my work. Good idea >b) Notify the Wine community of what the patches do/are but keep their >contents secret. LGPL violation, if you give your customer a LGPL'ed binary of wine, you must give them (Or at least offer them) access to the source, and you can't legally stop him/them from sending the code to wine-patches (Even if he/they may not have any interest in doing so) >c) Post them all to wine-devel but under a license that prevents them >being merged unless you get a special exception from me. That way people >can see, peer review the patches etc but they don't get committed. Of >course, as this is just supposed to be insurance anyway, that seems a >bit worthless. Obvious and explicit LGPL violation. >d) Say "screw it", submit as usual and just hope I'm dealing with >trustworthy people (unfortunately no contract in this case, the job >isn't really big enough to warrant one). Probably in your interest to opt for A, you can never be sure. Of course, if the code you've written is just say a dll that's linked to/by wine,and you're the only author of that file/dll/whatever, you can even keep if proprietary and choose options b or c or just keep the code totally secret(That's what Transgaming and Codeweavers do). Alternatively, you can ask the copyright holders of the files you've modified for a special license that allows commercial use, in this case you can keep the code closed, and opt for b or d, or keep the code totally secret. Have a good look at http://www.gnu.org/licenses/lgpl.txt

1 0

compiler warnings
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

The current code compiles with a few warnings, in the attachment. BTW you can see how code degenerates rapidly when it's not free software any more, probably 10% of all the output when compiling winex 3.2 is compiler warnings.

1 0

Re: Prevent wildcards from being accepted in filenames (NT mode)
by Dmitry Timoshkov 27 Nov '03

27 Nov '03

"Shachar Shemesh" <wine-patches(a)shemesh.biz> wrote: > + /* If wer'e in NT mode - don't allow wildcards in file name */ > + if( (strchrW(name, '?') || strchrW(name, '*')) && (GetVersion()&0x80000000)==0 ) (GetVersion() & 0x80000000)==0) construct is very inefficient. It forces compiler generate both a bit mask test and a comparison operation. While many modern processors have very effective bit test instructions, and we have to tell to the compiler that we want only a bit test. Simple !(GetVersion() & 0x80000000) is much better IMO. -- Dmitry.

7 8

More spare time = New Winetests build
by Jakob Eriksson 27 Nov '03

27 Nov '03

winetests has still not made it to CVS so one month later I have another build for you: Tests built with MSVC 7 from CVS 20031127. (Testing shell cross built with mingw32.) http://vmlinux.org/jakov/Wine/ And as Brian Vincent put it: "All you have to do is download winetests.exe and just run it. All of the collected results get displayed in a browser window with the option of submitting them to the wine-tests-results mailing list." Don't be afraid it the screen turns blank for a second. It's normal. regards, Jakob .

1 0

winearts & KDE 3.2-beta1
by Kevin Koltzau 27 Nov '03

27 Nov '03

I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo ebuild), and found a problem with compiling winearts under KDE 3.1 "artsc-config --cflags" gives me -I/usr/kde/3.1/include/artsc but under KDE 3.2-beta1 I get -I/usr/kde/3.2/include/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include which causes a problem because this value is passed to makedep during compilation, which fails with "Unknown option '-pthread'"

2 1

Debug channel list
by Mike Hearn 27 Nov '03

27 Nov '03

Here's a more readable version of what I just posted to wine-patches. There are quite a few, aren't there? Full marks to anybody who can actually describe what they all monitor :) accel adpcm advapi animate aspi atom avicap avifile bidi bitblt bitmap cabinet capi caret cdrom cfgmgr32 class clipboard clipping combo comboex comm commctrl commdlg computername console crtdll crypt curses cursor d3d d3d_shader d3d_surface datetime dc ddeml ddraw ddraw_fps ddraw_geom ddraw_tex debugstr devenum dialog dinput dll dma dmband dmcompos dmfile dmfiledat dmime dmloader dmscript dmstyle dmsynth dmusic dosfs dosmem dplay dplayx dpnhpast driver dsound dsound3d edit enhmetafile environ event eventlog exec file fixup font fps g711 gdi global glu graphics header heap hook hotkey icmp icon imagehlp imagelist imm int int21 int31 io ipaddress iphlpapi jack joystick key keyboard listbox listview loaddll local mapi mci mcianim mciavi mcicda mcimidi mciwave mdi menu menubuilder message metafile midi mmaux mmio mmsys mmtime module monthcal mpeg3 mpr msacm msdmo msg mshtml msi msimg32 msisys msrle32 msvcrt msvideo mswsock nativefont netapi32 netbios nls nonclient ntdll odbc ole oledlg olerelay opengl pager palette pidl powermgnt print process profile progress propsheet psapi psdrv qcap quartz ras rebar reg region relay resource richedit rundll32 sblaster scroll seh selector server setupapi shdocvw shell shlctrl snmpapi snoop sound static statusbar storage stress string syscolor system tab tape tapi task text thread thunk tid timer toolbar toolhelp tooltips trackbar treeview ttydrv twain typelib uninstaller updown urlmon uxtheme ver virtual vxd wave wc_font win win32 wineboot winecfg wineconsole wine_d3d winevdm wing winhelp wininet winmm winsock winspool wintab wintab32 wnet x11drv x11settings xdnd xrandr xrender xvidmode

1 0

Re: Fun projects?
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

>The easiest way is simply to convert the Gimp into a >Windows program by compiling it with WineLib >That means that in order to use Photoshop >plugins in the Gimp you'd need a special build of the Gimp Special build? Wouldn't it be easier to use the native version of gimp for windows?

2 1

Re: Winealsa : add support for Alsa 1.0
by Dimitrie O. Paun 27 Nov '03

27 Nov '03

On November 27, 2003 06:21 am, Sylvain Petreolle wrote: > Is this second attempt better ? > (not tested with alsa 0.9) Why don't you define the snd_pcm_hw_params_* macros for alsa 0.9. For example, this bit: - snd_pcm_format_t format = snd_pcm_hw_params_get_format(hw_params); - snd_pcm_access_t access = snd_pcm_hw_params_get_access(hw_params); + snd_pcm_format_t format; + snd_pcm_access_t access; + snd_pcm_uframes_t buffer_size, bufsize_min, bufsize_max; + int dir=0, channels, channels_min, channels_max; + long int period_size, periods_min=0, periods_max=0; + +#if (SND_LIB_MAJOR == 0) + format = snd_pcm_hw_params_get_format(hw_params); + access = snd_pcm_hw_params_get_access(hw_params); +#else + snd_pcm_hw_params_get_format(hw_params,&format); + snd_pcm_hw_params_get_access(hw_params,&access); +#endif Could have been coded like so: +#if (SND_LIB_MAJOR == 0) +# define snd_pcm_hw_params_get_format(hw_params,format) do{ *format = snd_pcm_hw_params_get_format(hw_params);} while(0) +# define snd_pcm_hw_params_get_access(hw_params,access) do{ *access = snd_pcm_hw_params_get_access(hw_params);} while(0) ... more snd_pcm_hw_params_* definitions +#endif ... - snd_pcm_format_t format = snd_pcm_hw_params_get_format(hw_params); - snd_pcm_access_t access = snd_pcm_hw_params_get_access(hw_params); + snd_pcm_format_t format; + snd_pcm_access_t access; + snd_pcm_uframes_t buffer_size, bufsize_min, bufsize_max; + int dir=0, channels, channels_min, channels_max; + long int period_size, periods_min=0, periods_max=0; + + snd_pcm_hw_params_get_format(hw_params,&format); + snd_pcm_hw_params_get_access(hw_params,&access); Eliminates a lot of #ifdefs, cleaner code, etc. -- Dimi.

2 1

Wine lecture slides
by Shachar Shemesh 27 Nov '03

27 Nov '03

Hi all, The updated slides for the lecture I'll be giving on Sunday are at http://www.shemesh.biz/wine/slides.pdf. I tried to incorporate all of the feedback from you guys. I would, still, appretiate any further feedback you may wish to give. I also have specific questions, if anyone knows the answers: - What is the current status of "--with-nptl" on RH9? Is it positively necessary to include that when running ./configure? I know it's not necessary when running wineinstall. - Can someone please verify my knowledge of Corel's wine history Hmm, that list turned out shorter Corel-wine: As far as I could discern from the good ol' web, Corel started it's Wine initiative in 1999 as an alternative to actually porting WordPerfect and friends to Linux. They created a branch called "Corel-wine", which was also open source (wine was X11 at the time, so they did have the choice). At some point, corel-wine died. Why did it die? When did that happen? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 2

MSVC build log of wine conformance tests
by Jakob Eriksson 27 Nov '03

27 Nov '03

MSVC build log of wine conformance tests: http://vmlinux.org/jakov/Wine/build_log_MSVC_CVS_2003-11-27.txt All in all, 14 tests compile and 7 do not. AFAIK I use an up to date VC++ 7. (I reinstalled Windows though, so I _might_ have missed something.) regards, Jakob

1 0

Re: Winealsa : add support for Alsa 1.0
by Alexandre Julliard 27 Nov '03

27 Nov '03

Sylvain Petreolle <spetreolle(a)yahoo.fr> writes: > this patch is an attempt to provide Alsa 1.0 support into winealsa. > > the file audio_09.c is the current audio.c for alsa 0.9 with small > modifications to > ensure compatibility with the new alsa API. I don't think we want yet another duplicate of that code. Please try to support both in the same file, there aren't that many differences. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: RFH: *ReAlloc* mess
by Juan Lang 27 Nov '03

27 Nov '03

NetApiBufferReallocate: - does not allocate memory when NULL is the original pointer passed in - frees memory when the new size is 0 HTH, --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Descrepancy between Windows and GLIBC version of [v]snprintf
by Daniel Gehriger 26 Nov '03

26 Nov '03

Hi, I found a problem with the _snprintf() / _vsnprintf() functions. Wine seems to use the forward these function calls to their native implementation (eg. in GLIBC). The problem is that they behave differently under Windows and GLIBC: Both function take a parameter to specify the maximum number of characters to write. Under Windows, if the formated string is equal in length to or exceeds the specified number, the terminating NULL will NOT be written to the buffer. Under Linux, the terminating NULL is ALWAYS written. The test program below produces the following output (only when linked dynamically, of course) : Under Windows: 0000000001**** Under Wine: 000000000 When compiled on Linux: 000000000 --------------------------------------------------------- #include <stdio.h> #include <memory.h> int main() { char buffer[16]; memset(buffer, 0, 16); memset(buffer, '*', 15); int len = _snprintf(buffer, 10, "%010d", 1); printf("%d : %s\n", len, buffer); return 0; } --------------------------------------------------------- Regards, Daniel

3 3

PRIVATE flag sends dllwrap for a loop.
by Steven Edwards 26 Nov '03

26 Nov '03

Hello, This is a problem I have had for a while building WINE dlls for use on Windows and ReactOS. When linking the dlls dllwrap always complains that it cant find the symbol private that is added to the .def file. When I remove this symbol and rebuild my import libs and dlls I dont have any problems so lets disable it for now. Changelog: Disable PRIVATE name on for exports in def files. Index: spec32.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/spec32.c,v retrieving revision 1.72 diff -u -r1.72 spec32.c --- spec32.c 3 Nov 2003 22:19:44 -0000 1.72 +++ spec32.c 20 Nov 2003 18:21:56 -0000 @@ -900,7 +900,9 @@ fprintf( outfile, " @%d", odp->ordinal ); if (!odp->name) fprintf( outfile, " NONAME" ); if (is_data) fprintf( outfile, " DATA" ); +#if 0 if (odp->flags & FLAG_PRIVATE) fprintf( outfile, " PRIVATE" ); +#endif fprintf( outfile, "\n" ); } } __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 3

Re: netapi32: implement Netbios()
by Juan Lang 26 Nov '03

26 Nov '03

Hi Uwe et al.. Uwe said: > Saying a little more may help. > > What's needed to test you patch? What programs show > improvement? Good questions. I have little test programs that I've been using, but NetBIOS is hard to test without knowing something about your network configuration, so they're not much use for netapi32/tests. I don't know of any programs that work now that didn't, except what I'm working on: I'm trying to implement the Network Neighborhood. I've been tweaking WINE's SMB code to use Netbios() rather than implementing the netbios-over-tcpip stuff directly. That work isn't done yet, watch this space for more :) There was an article a while back linked here about some HP management program (for their NAS appliance) that didn't discover their box under WINE because of lack of NetBIOS support. I suspect this may now work, but I don't know. > Any configuration items needed in a .ini file or the > registry? Needed? No, should work as-is. You may configure some things in the registry if you need to. Many are configured in the same way as Win98's reg, but not all. I didn't know a good place to document these; comments in winedefault.reg??? > And thanks for your work :-) You're very welcome :) --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Re: netapi32: implement Netbios()
by Uwe Bonnes 26 Nov '03

26 Nov '03

>>>>> "Juan" == Juan Lang <juan_lang(a)yahoo.com> writes: Juan> Apologies for the size of the patch, I didn't see any useful way Juan> to shrink it. Juan> ChangeLog: implement rather a lot of Netbios() Juan> I could say a bit more than that, but it wouldn't mean much to Juan> most people. Where there was nearly none, now there is some. Saying a little more may help. What's needed to test you patch? What programs show improvement? Any configuration items needed in a .ini file or the registry? Just some thoughts. And thanks for your work :-) 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

debugger problems
by Chris Morgan 26 Nov '03

26 Nov '03

I'm trying to debug a crash in some changes to the jack audio driver and can't seem to have the wine debugger show me the actual source code of the crash. I start up the debugger and get this: oaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\winamp\Winamp.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x408c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40840000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40980000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x40900000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40c40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40bd0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x40c80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40e10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEJACK.DRV' (0x410e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41130000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41120000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41270000) In 32-bit mode. Wine-dbg> I run and get a crash: Backtrace: =>0 0x41101541 (WINEJACK.DRV..data+0x14541) (ebp=42b87748) 1 0x410e6cbf (WINEJACK.DRV..text+0x5cbf in WINEJACK.DRV) (ebp=42b877cc) 2 0x410e7e10 (WINEJACK.DRV..text+0x6e10 in WINEJACK.DRV) (ebp=42b87804) 3 0x410e9111 (WINEJACK.DRV.wodMessage+0x131 in WINEJACK.DRV) (ebp=42b8783c) 4 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b878ac) 5 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b878dc) 6 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87948) 7 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87974) 8 0x41121362 (MSACM.DRV..text+0x362 in MSACM.DRV) (ebp=42b879a8) 9 0x4112158b (MSACM.DRV..text+0x58b in MSACM.DRV) (ebp=42b87a14) 10 0x411225e7 (MSACM.DRV.wodMessage+0xe7 in MSACM.DRV) (ebp=42b87a4c) 11 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b87abc) 12 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b87aec) 13 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87b58) 14 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87b84) 15 0x42a69ca6 (DSOUND.DLL.DirectSoundCreate8+0x5d6 in DSOUND.DLL) (ebp=42b87c44) 16 0x425f90eb (OUT_DS.DLL..text+0x10eb in OUT_DS.DLL) (ebp=00000000) 0x41101541 (WINEJACK.DRV..data+0x14541): movb %al,0x0(%edx) Wine-dbg>list Enter path to file '': What am I doing wrong here? Chris

3 3

Re: Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

> Hmm. I'd be wary of trusting a page with such obviously manipulated > screenshots (check out the different background colours/fonts of some of > the labels), and "Write in HERE or die LMAO!" as the link to the > guestbook :-) I think they manipulated the screenshots to avoid someone hosting them and saying "I took this screenshot on my pc". Also, if you look on google you can find links to pages that talk about neptune, nashville and so on.

1 0

Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

Lists (And screenshots) of lots of stuff m$ never released, like windows neptune, Whistler Advanced Server, Cairo, Nashville (Windows 96), windows titanium, windows 99, and more. http://ad-iso.mine.nu/~air101/

2 1

PE stack trick not working on lowmem machines
by Marcus Meissner 26 Nov '03

26 Nov '03

Hi, On SuSE 8.2, i586 glibc, loader/wine-* crash due to the 256 MB static array in main(). The test machine has just 64MB RAM and 200MB swap. If I start decreasing the array it works, up to 201MB. $ /lib/ld-linux.so.2 ./wine-kthread ./wine-kthread: error while loading shared libraries: ./wine-kthread: cannot map zero-fill pages: Cannot allocate memory $ So ld.so really wants to get 20xMB memory but fails. -> Not good on low memory machines. (Not sure if we should fix it.) Btw, why don't we use -Wa,--noexecstack ? Ciao, Marcus

3 3

Re: Reject wildcards in directory names
by Rolf Kalbermatter 26 Nov '03

26 Nov '03

Alexandre Julliard <julliard(a)winehq.org> wrote: > > As for the invalid characters, [Create|Remove]File[A|W] only check > > for '?', '*', which I just copied for [Create|Remove]Directory[A|W]. > > I take it you will accept a patch that also extends the checks in > > [Create|Remove]File*? > > Yes, and of course it should use a common routine to do the checks, so > that it's consistent everywhere. Also the Create and Remove cases > should be handled differently IMO, a Remove should succeed if the > specified file exists, even if it contains illegal characters. I would actually agree with Alexandre here, but W2K at least behaves differently. My tests show that RemoveDirectory just as CreateDirectory rejects all paths which contain one of the wildcards ": * ? \" < > |" with error 123 completely independent where that character occurs (not just in the path element which is created). And as far as I can say DeleteFile just as much behaves also this way. So should we attempt to be smarter than Windows in this case? Rolf Kalbermatter

5 12

Re: winehq name
by Alexandre Julliard 26 Nov '03

26 Nov '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I know we've discussed this before, but I feel things > have changed and it's worth another try :) Namely, > have the winehq.org name be the default one. It seems > virtually everybody (except you) prefer the .org name > over the .com name, it's way more community friendly, > and it seems to be the default one on WineHQ for a > while, without any negative side effects. It's not that I prefer the .com name, frankly I couldn't care less, it's just that I think it's silly to change a perfectly good name that everybody was used to, simply to achieve some questionable ideal of "purity" of the domain name; and even more silly to have to change all references to try to reduce the confusion that would never have happened if we hadn't changed it in the first place. But I don't really care enough to keep fighting about it, so I put your patch in... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/programs/winedbg debug.l
by Dimitrie O. Paun 26 Nov '03

26 Nov '03

On November 25, 2003 11:10 pm, Alexandre Julliard wrote: > Modified files: > programs/winedbg: debug.l > > Log message: > Fixed one more HeapReAlloc call. Good catch! I didn't lie when I said all calls were reviewed, it's just that I didn't search .l files... -- Dimi.

1 0

RE: wine/ windows/win.c windows/message.c programs ...
by Robert Shearman 26 Nov '03

26 Nov '03

> -----Original Message----- > From: wine-cvs-admin(a)winehq.com [mailto:wine-cvs-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: 26 November 2003 04:09 > To: wine-cvs(a)winehq.com > Subject: wine/ windows/win.c windows/message.c programs ... > > Log message: > Fixed declarations of BroadcastSystemMessage and > TranslateAccelerator > in winuser.h. Added GetWindowModuleFileName. > +LONG WINAPI BroadcastSystemMessageA(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +LONG WINAPI BroadcastSystemMessageW(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +#define BroadcastSystemMessage WINELIB_NAME_A(BroadcastSystemMessage) Should this not be WINELIB_NAME_AW? Rob

1 0

Strange problem with wine
by Gerhard W. Gruber 25 Nov '03

25 Nov '03

I'm using a build that is about one month old, but I don't think that this is the problem. I will update in the next few days and then I will see if this goes away. OK. I have written this small tool which you can download at http://sourceforge.net/projects/launchmen. The Linux port uses a normal fork() and then executes the specifed application when the entry is selected from the menu. It works for every application but only with wine/Agent I have to select the entry twice to make it run. When I select the entry wich should run wine with Agent nothing happens. When I look into the process list the first time I can see this: 1506 ? S 0:00 /usr/local/bin/wine /home/user/wine/D/home/agent/agent.exe 1507 ? S 0:00 \_ wineserver 1508 ? S 0:00 \_ wineserver Which is strange because I have two wineservers running. When I launch exactly the same commandline from the shell everything is normal. I see one Agent, one wineserver and Agent comes up fine. In the case of my application I can see the above list and Agent doesn't start. Only when I launch Agent a second time from my app then it starts fine. When I exit Agent then and look again I can still see the old Agent hanging, but as long as this one is there my app can launch Agent normally. When I kill this Agent and wineserver the same happens again and I have to start it twice. Any ideas what this could be? Since I only have this problem with wine I thought I ask if somebody could say something about this. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

1 0

Re: unicows update and PE memory format
by Rolf Kalbermatter 25 Nov '03

25 Nov '03

Message: 4 Subject: Re: PE stack trick not working on lowmem machines From: Mike Hearn <mike(a)theoretic.com> To: Alexandre Julliard <julliard(a)winehq.org> Cc: Marcus Meissner <meissner(a)suse.de>, wine-devel(a)winehq.com Date: Mon, 24 Nov 2003 21:00:33 +0000 On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote: > > Btw, why don't we use -Wa,--noexecstack ? > > It doesn't help with prelink AFAICT. Is it really too late to get some kind of hook into prelink to stop it interfering with Wine? It seems daft that we need such a big hack when surely a flag in the elf headers would work just as well with co-operation from the rtld. --__--__-- >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: >Now here's the puzzle - GetProcAddress is never called. Neither are >these functions imported from the DLL in the PE header. In fact, >unicows.dll does not even appear in the PE header (which makes sense - >on NT you don't even want to install it). This means that unicows.lib >manages to call GetProcAddress, without actually calling GetProcAddress. > >Some tracing leads me to suspect (I have not done enough research to >determine yet) that it accesses the PE header of kernel32 directly. It >appears that unicows.dll enountered the exact same problem we have vis a >vis GetProcAddress, and have happily hacked their way around it using >direct memory access. What I see them do is call "GetModuleHandle" on >"kernel32.dll", and then use the resulting handle as a struct/array >pointer, and access offsets into it. This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly. An HMODULE on Win32 is nothing else than the base address of a loaded module image, and with some offset calculations using Macros from winnt.h you can get at anything in that image including the export table and from there you can then search GetProcAddress. One possible problem is that the unicows GetProcAddress implementation might not search the function in the export table by name but rather by ordinal and our ordinal or ordinal base is different from what Unicows expects. Rolf Kalbermatter

2 1

Re: Small fontdlg fix.
by Shachar Shemesh 25 Nov '03

25 Nov '03

Rein Klazes wrote: > HPEN hOrigPen; > HFONT hOrigFont; > COLORREF rgbPrev; >- WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'}; >+ WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'}; > > This is wrong. "YyZz" are only added if it's a western encoding. This already happens (a patch I submitted earlier this year, and forgot to add my copyright to the file). With this patch, if you view a font in it's Western encoding, you get a sample that says "AaBbYyZzYyZz". If you view a font in another encoding (say, Hebrew, because that's the only one that was fed in), you get "AaBbYyZz��", instead of "AaBb��", like it is on Windows 2000, and like it makes sense (we want to spare some space). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 3

Re: [PATCH] wininet.dll compile time defines
by Vincent Béron 25 Nov '03

25 Nov '03

Le mar 25/11/2003 à 00:37, Alex Tribble a écrit : > Hi, > When upgrading to Fedora Core 1 (the new RedHat release, sort of), > wine stopped compiling for me. I was getting errors while parsing > <openssl/ssl.h>, et al. -DOPENSSL_NO_KRB5 makes these go away. > > Any thoughts? Please CC me, as I'm not subscribed to the devel list. The patch http://cvs.winehq.com/patch.py?id=10182 (applied yesterday in CVS) fixes the issue. Vincent

1 0

Re: Mach-O Support for imageSize in NtHeader
by Alexandre Julliard 25 Nov '03

25 Nov '03

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Here is my second try for a replacement of the _end symbol. I think > that since there is no support of it we need a kind of emulation > function, which I thought should be located in the wine_port lib. So I > add a mach-o.c port file, with the needed function. But should it be > done this way? No, the static char _end[] thing should be enough, you don't have to store anything in there (which won't do what you want anyway). The only thing that matters is the address of the _end symbol. -- Alexandre Julliard julliard(a)winehq.com

2 1

unicows update and PE memory format
by Shachar Shemesh 25 Nov '03

25 Nov '03

Hi list, Here is a quick update. It seems that I won't be able to use the forwarding inside the spec file. I'm not sure exactly why that is, but I think the unicows.lib link time library tries to load stuff by doing "GetModuleHandle", and then fetching relative values from that place. Is there a plausable assumption about PE memory layout? Is this something that Win32 properly defines? Do we have such a format for winelib dlls? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 5

RFH: *ReAlloc* mess
by Dimitrie O. Paun 25 Nov '03

25 Nov '03

Hi folks, I need some help to figure out how the following realloc functions behave: GlobalReAlloc LocalReAlloc Local32ReAlloc16 NetApiBufferReallocate SysReAllocStringLen So, I need to know: -- do they allocate memory when a NULL is passed in? -- do they free memory when the size is passed in as 0? Help with this matter is much appreciated! -- Dimi.

1 0

Re: Update comctl spec
by Alexandre Julliard 24 Nov '03

24 Nov '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Export more functions by name. This will break the import libraries. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Compile Bug: dlls/wininet/cookie.c .. and its cause
by Alexandre Julliard 24 Nov '03

24 Nov '03

Ivan Gyurdiev <ivg2(a)cornell.edu> writes: > I have no clue what the FAR macro does, but wouldn't it be better to > just rename the wine FAR macro to something different if you dont want > it to conflict w/ the other FAR macro? It's a Windows thing, we can't change it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: heap: fix RtlHeapReAllocate()
by Dimitrie O. Paun 24 Nov '03

24 Nov '03

On November 21, 2003 03:21 pm, Eric Pouech wrote: > this will not compile on Win9x. You have to take care of: Good point, sorry about that, I was being lazy. To force people to do the dyn load, we shouldn't import ntdll, no? ChangeLog RtlHeapReAllocate() should not allocate memory. Add small test to make sure it doesn't return. Don't import ntdll for tests, we need to load it dynamically. Index: dlls/ntdll/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/heap.c,v retrieving revision 1.25 diff -u -r1.25 heap.c --- dlls/ntdll/heap.c 10 Oct 2003 00:12:17 -0000 1.25 +++ dlls/ntdll/heap.c 20 Nov 2003 21:00:39 -0000 @@ -1231,11 +1231,11 @@ HEAP *heapPtr; SUBHEAP *subheap; - if (!ptr) return RtlAllocateHeap( heap, flags, size ); /* FIXME: correct? */ + if (!ptr) return NULL; if (!(heapPtr = HEAP_GetPtr( heap ))) { set_status( STATUS_INVALID_HANDLE ); - return FALSE; + return NULL; } /* Validate the parameters */ Index: dlls/ntdll/tests/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/tests/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- dlls/ntdll/tests/Makefile.in 8 May 2003 03:47:24 -0000 1.9 +++ dlls/ntdll/tests/Makefile.in 24 Nov 2003 07:19:04 -0000 @@ -3,12 +3,12 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = ntdll.dll -IMPORTS = ntdll CTESTS = \ env.c \ error.c \ generated.c \ + heap.c \ large_int.c \ path.c \ rtl.c \ --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ dlls/ntdll/tests/heap.c 2003-11-24 02:17:07.000000000 -0500 @@ -0,0 +1,49 @@ +/* + * Unit test suite for heap functions + * + * Copyright 2003 Dimitrie O. Paun + * + * 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 <stdarg.h> +#include <stdlib.h> + +#include "ntstatus.h" +#include "windef.h" +#include "winbase.h" +#include "wine/test.h" +#include "winnt.h" +#include "winnls.h" +#include "winreg.h" +#include "winternl.h" + +PVOID (WINAPI *pRtlReAllocateHeap)(HANDLE,ULONG,PVOID,ULONG); + +static void test_realloc( void ) +{ + void *mem = NULL; + + mem = pRtlReAllocateHeap(GetProcessHeap(), 0, mem, 10); + ok(mem == NULL, "memory allocated"); +} + +START_TEST(heap) +{ + HMODULE mod = GetModuleHandle("ntdll.dll"); + if (!mod) return; + pRtlReAllocateHeap = (void *)GetProcAddress(mod, "RtlReAllocateHeap"); + if (pRtlReAllocateHeap) test_realloc(); +} -- Dimi.

3 3

Compile Bug: dlls/wininet/cookie.c .. and its cause
by Ivan Gyurdiev 24 Nov '03

24 Nov '03

Macro __WINESRC__ is defined for dlls/wininet/cookie.c in the Makefile. The file cookie.c includes wine/debug.h. wine/debug.h includes windef.h. windef.h defines the macro FAR to __ONLY_IN_WINELIB() __ONLY_IN_WINELIB() defines to do_not_use_this_in_wine if __WINESRC__ The file dlls/wininet/cookie.c also includes dlls/wininet/internet.h dlls/wininet/internet.h includes openssl/ssl.h for my machine openssl/ssl.h includes openssl/kssl.h openssl/kssl.h has the following code using the FAR macro: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; #endif #ifndef FAR #define FAR #endif ... Line 136: krb5_octet FAR *key; This is on a Fedora core system, which applies a patch to openssl that changes the original openssl-devel regarding this, but I think the issue's with wine, and is still there. The original openssl-devel looks like this: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; define FAR #endif Either way, the point is the FAR macro is being used in kssl.h, and it's defined in windef.h, as do_not_use_this_in_wine, resulting in this: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cookie.o cookie.c In file included from /usr/include/openssl/ssl.h:179, from internet.h:36, from cookie.c:39: /usr/include/openssl/kssl.h:136: error: syntax error before '*' token /usr/include/openssl/kssl.h:149: error: syntax error before '*' token /usr/include/openssl/kssl.h:150: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:152: error: syntax error before '*' token /usr/include/openssl/kssl.h:153: error: syntax error before '*' token /usr/include/openssl/kssl.h:155: error: syntax error before '*' token /usr/include/openssl/kssl.h:157: error: syntax error before '*' token /usr/include/openssl/kssl.h:159: error: syntax error before '*' token /usr/include/openssl/kssl.h:167: error: syntax error before '*' token In file included from internet.h:36, from cookie.c:39: /usr/include/openssl/ssl.h:909: error: syntax error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: error: syntax error before '}' token make[2]: *** [cookie.o] Error 1 make[2]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls/wininet' make[1]: *** [wininet] Error 2 make[1]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls' make: *** [dlls] Error 2 ===================================================================== I am not subscribed to this list. If you'd like to email back write to ivg2(a)cornell.edu. Also, some unrelated questions: does anyone know what causes this: err:module:NE_LoadBuiltinModule loaded .so but dll winealsa.drv still not found (the file is there... oss is there too, and works great) ....or why keyboard focus is always lost (characters appear in the console, kb doesn't work in application) when playing most games under a window manager like gnome or kde, but not under twm? This bug has been there forever and is really annoying.

3 2

Re: winmm: move MCI settings from system.ini to the registry
by Andreas Mohr 24 Nov '03

24 Nov '03

Hi, On Mon, Nov 24, 2003 at 12:10:20PM -0500, Dimitrie O. Paun wrote: > On November 22, 2003 03:02 am, Eric Pouech wrote: > > I won't have too much time to look at this in details right now, so if > > someone wants to jump in, I'll be happy to give him (her ?) a hand. > > To be honest, > My interest in doing this work is to get rid of system.ini from the > Wine tree. While I agree that there's more to do, it's just not up > my alley :) So, this version of the patch still maintains support > for system.ini, just like the old code does, but it also adds support > for registry, which should allow us to move stuff there. To be honest, I'm not sure why one would want that. After all the system.ini settings are an essential part of a Windows environment, and removing the whole file will break many (admittedly older) programs, if I'm not mistaken... (nevermind the duplication of the parameters, which does exist) Andreas Mohr

1 0

Re: documentation/samples/generic.ppd
by Marcus Meissner 24 Nov '03

24 Nov '03

On Mon, Nov 24, 2003 at 02:32:49AM -0500, Dimitrie O. Paun wrote: > > I can't help but feel that this file does not belong in the > Wine tree, but in the print system packages (cups, etc.). > > cvs rm -f documentation/samples/generic.ppd > > ChangeLog > Remove generic.ppd, it does not belong in the Wine tree. This is the generic fallback PPD file which can be used LPR style printing, where we do not get access to a PPD easily. Ciao, Marcus

2 1

IS_STRING_ITEM( lpitem->fType ) but no lpitem->text
by Uwe Bonnes 24 Nov '03

24 Nov '03

Hallo, Peter Heckert <ph_newsalias(a)arcor.de> posted on c.e.m.w a problem with Sigma Photo Pro 2. Sigma Photo Pro 2 can be downloaded at http://www.sigma-photo.co.jp/english/downloads/downloads.html It seems that IS_STRING_ITEM( lpitem->fType ) is set while there is no lpitem->text. Appended hack lets Sigma Photo Pro 2 run until exit, where it crashes again. Can anybody look at that problem? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.169 diff -u -r1.169 menu.c --- wine/controls/menu.c 18 Nov 2003 19:42:31 -0000 1.169 +++ wine/controls/menu.c 23 Nov 2003 21:52:38 -0000 @@ -936,7 +936,7 @@ /* it must be a text item - unless it's the system menu */ - if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )) + if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )&& lpitem->text) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); @@ -1361,7 +1361,7 @@ } /* No bitmap - process text if present */ - else if (IS_STRING_ITEM(lpitem->fType)) + else if (IS_STRING_ITEM(lpitem->fType) && lpitem->text) { register int i; HFONT hfontOld = 0;

2 2

Re: wine/dlls/kernel process.c
by Marcelo Duarte 24 Nov '03

24 Nov '03

Em Seg 17 Nov 2003 17:18, Alexandre Julliard escreveu: > ChangeSet ID: 10093 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/11/17 14:18:19 > > Modified files: > dlls/kernel : process.c > > Log message: > Fixed regression in loading of builtin apps from the system dir when > the native doesn't exist. > > Patch: http://cvs.winehq.com/patch.py?id=10093 > > Old revision New revision Changes Path > 1.34 1.35 +1 -1 wine/dlls/kernel/process.c This patch do not work for me. I run: wine --debugmsg +file -- c:\\windows\\system\\vfp300.esl c:\\modullus.300\\modullus.exe See, the file is searched in all directories of the PATH, and not found: trace:file:CreateFileW L"C:\\windows\\system\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L".\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\system\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\system\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"e:\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"e:\\test\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\test\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"f:\\msvcrt.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"f:\\msvcrt.dll" (GLE 2) trace:file:CreateFileW L"C:\\windows\\system\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\kernel32.dll" (GLE 2) trace:file:CreateFileW L".\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\WINDOWS\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"c:\\windows\\system\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"c:\\windows\\system\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"e:\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"e:\\test\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"e:\\test\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"f:\\kernel32.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"f:\\kernel32.dll" (GLE 2) trace:file:CreateFileW L"C:\\windows\\system\\ntdll.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\\windows\\system\\ntdll.dll" (GLE 2) trace:file:CreateFileW L".\\ntdll.dll" QUERY_ACCESS FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L".\\ntdll.dll" (GLE 2) -- Marcelo Duarte

1 0

Re: Compiler problems
by Ivan Leo Murray-Smith 24 Nov '03

24 Nov '03

Current code builds on my system.

2 1

Re: Regressions....
by Marcelo Duarte 24 Nov '03

24 Nov '03

Em Sáb 15 Nov 2003 13:28, você escreveu: Hi, Recently I found plus a regression when trying to install my application, using the installer of the M$, with updated cvs. See the error: [mduarte@mduarte setup]$ wine config Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: err:seh:setup_exception stack overflow 304 bytes in thread 000c eip 4045ec30 esp 405c0ed0 stack 0x405c0000-0x405c4000 [mduarte@mduarte setup]$ Somebody can give tips to discover the problem to me? Running +relay is too slow in my machine, but I hava a 1.2MB log. I have little time that I can dedicate to the Wine, but go to try to make this today and tomorrow. Here is the part of +relay where the error occurs and system hangs: 000c:Call ntdll.RtlInitAnsiString(405c3c6c,406867c0 "Software\\Wine\\Wine\\Config\\Tweak.Fonts") ret=405e32a4 000c:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=405e32a4 000c:Call ntdll.RtlAnsiStringToUnicodeString(40018bf8,405c3c6c,00000000) ret=405e32ad 000c:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=405e32ad 000c:Call ntdll.NtOpenKey(405c3d78,000f003f,405c3c74) ret=405e32d3 000c:Ret ntdll.NtOpenKey() retval=c0000034 ret=405e32d3 000c:Call ntdll.RtlNtStatusToDosError(c0000034) ret=405e32b7 000c:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=405e32b7 000c:Ret advapi32.RegOpenKeyA() retval=00000002 ret=4066f28c 000c:Call kernel32.LoadLibrary16(40686903 "GDI.EXE") ret=4066f2a3 err:seh:setup_exception stack overflow 460 bytes in thread 000c eip 4045ec30 esp 405c0e34 stack 0x405c0000-0x405c4000 Thanks in advance. > Em Qua 05 Nov 2003 22:30, Marcelo Duarte escreveu: > > Hi all, > > > > Some days ago, I have some problems with my application developed in > > Visual Foxpro 3, that before the end of separation of kernel, runs with > > some issues, but runs. The problems resides in a call to dlls and > > library (in VFP, the comand SET LIBRARY calls a especial type of DLL) and > > the 3 forms is accepted: 1) SET LIBRARY TO FOXTOOLS > > 2) SET LIBRARY TO FOXTOOLS.FLL > > 3) SET LIBRARY TO "FOXTOOLS.FLL" > > In wine, after the end of separation fase, in the new wine-20031016, only > > the (3) is accepted, and accutually (the last CVS) the forms 1, 2 and 3, > > appear to be running, and I will investigate.... > > But, the usage of external DLLs is broken. > > Exist the comand DECLARE, wich declares a function in a dll, and as > > example, I use this: > > DECLARE INTEGER GetLogicalDriveStrings IN WIN32API; > > INTEGER nLen, STRING @sBuf > > > > and call: > > nLen = GetLogicalDriveStrings(MAX_DRIVES, @sBuf) > > > > When the calls fire, the programs terminates, a messagebox appear with > > text "Invalid indentifier" and some others erros and wine returns the > > following errors: > > > > [mduarte@mduarte MODULLUS.300]$ wine modullus > > fixme:font:WineEngAddFontResourceEx :stub > > fixme:font:WineEngAddFontResourceEx :stub > > [mduarte@mduarte MODULLUS.300]$ wine: Unhandled exception (thread 000b), > > starting debugger... > > WineDbg starting on pid a > > Loaded debug information from ELF 'wine' ((nil)) > > Breakpoint 1 at 0x4000d484 (_end+0x400a660) > > Loaded debug information from ELF '/usr/local/lib/libwine.so.1' > > (0x40028000) No debug information in ELF '/lib/libc.so.6' (0x4003f000) > > No debug information in ELF '/lib/libdl.so.2' (0x40184000) > > No debug information in ELF '/lib/libm.so.6' (0x40187000) > > Loaded debug information from ELF '/lib/ld-linux.so.2' (0x40000000) > > Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' > > (0x401aa000) > > Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' > > (0x40216000) > > No debug information in ELF '/lib/libnss_files.so.2' (0x4001a000) > > Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' > > (0x40420000) > > Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' > > (0x40680000) > > Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' > > (0x407ab000) > > Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' > > (0x4081b000) > > Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so' > > (0x40847000) > > Loaded debug information from ELF '/usr/local/lib/wine/comdlg32.dll.so' > > (0x40869000) > > Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' > > (0x408e1000) > > Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' > > (0x4095d000) > > Loaded debug information from ELF '/usr/local/lib/wine/rpcrt4.dll.so' > > (0x409cc000) > > Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' > > (0x40a11000) > > Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' > > (0x40a64000) > > Loaded debug information from ELF '/usr/local/lib/wine/version.dll.so' > > (0x40af9000) > > Loaded debug information from ELF '/usr/local/lib/wine/lz32.dll.so' > > (0x40b12000) > > Loaded debug information from ELF '/usr/local/lib/wine/mpr.dll.so' > > (0x40b28000) > > Loaded debug information from ELF '/usr/local/lib/wine/winmm.dll.so' > > (0x40b41000) > > Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' > > (0x40ba6000) > > No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40561000) > > No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40c21000) > > No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x4030b000) > > No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x40571000) > > No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40c38000) > > No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40c46000) > > No debug information in ELF '/usr/lib/libGL.so.1' (0x40d0e000) > > No debug information in ELF '/usr/X11R6/lib/libXmu.so.6' (0x40ebb000) > > No debug information in ELF '/usr/X11R6/lib/libXt.so.6' (0x40ed1000) > > No debug information in ELF '/usr/X11R6/lib/libXi.so.6' (0x40f23000) > > No debug information in ELF '/lib/libpthread.so.0' (0x40f2b000) > > No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x40f7c000) > > No debug information in ELF > > '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4056a000) > > No debug information in ELF > > '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40f85000) > > Loaded debug information from ELF '/usr/local/lib/wine/wineoss.drv.so' > > (0x410c0000) > > Loaded debug information from ELF '/usr/local/lib/wine/msacm.drv.so' > > (0x410fb000) > > Loaded debug information from ELF '/usr/local/lib/wine/msacm32.dll.so' > > (0x41112000) > > Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' > > (0x41250000) > > Loaded debug information from ELF '/usr/local/lib/wine/ctl3d32.dll.so' > > (0x41371000) > > No debug information in 32bit DLL 'C:\windows\system\VFP300.ESL' > > (0x400000) No debug information in 32bit DLL 'NTDLL.DLL' (0x401c0000) > > No debug information in 32bit DLL 'KERNEL32.DLL' (0x40450000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' > > (0x40830000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' > > (0x407c0000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406a0000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40850000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' > > (0x409e0000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40980000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a30000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40a70000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' > > (0x40900000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40880000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' > > (0x40b20000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40b00000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\MPR.DLL' (0x40b30000) No debug information > > in 32bit DLL > > 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b50000) No debug information in 32bit > > DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40bc0000) No debug information in > > 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x410d0000) No debug > > information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41120000) No > > debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41100000) > > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' > > (0x41260000) No debug information in 32bit DLL > > 'C:\WINDOWS\SYSTEM\CTL3D32.DLL' (0x41380000) Unhandled exception: page > > fault on write access to 0x55bd0565 in 32-bit code (0x00405732). > > In 32-bit mode. > > 0x00405732 (VFP300.ESL..text+0x3732 in VFP300.ESL): movl > > %edx,0x0(%eax) Wine-dbg>WineDbg terminated on pid a > > > > The winedbg crahes.... > > > > The wine-20030911 runs fine. > > Can someone help me how to correct, or where to find the problem? -- Marcelo Duarte

1 1

configure features summary patch
by Chris Morgan 23 Nov '03

23 Nov '03

Lionel was wondering why just print out the status of openGL, why not of other optional features. I tried to get all of the important ones, comments and suggestions welcome. This patch is intended to replace the previous one. Chris

1 0

Segmentation fault with "./pgm" but not with "wine ./pgm"
by Sundial Services International Inc 23 Nov '03

23 Nov '03

After updating Linux (glibc) the following problem has surfaced: [#1] If a Win32 executable is run from the shell with "./pgmname" the program does not run but produces the message "segmentation fault." (If there is a traceback or log then I don't know how to get it.) [#2] However: if the program is run with "wine ./pgmname" the program runs normally. Perhaps the most basic problem I have here is that, in scenario #1 when all I get is "segmentation fault," I don't know how to get more info, a traceback or a log. System is RHLinux 8.0, Wine 20030318, which ran just fine in both scenarios until an update was applied which included glibc. Incidentally, I rebuilt Wine from source and even rebooted the machine (sigh, thus ending 100-odd days of uptime) with no effect on the prob. Obviously if I knew how to see the real failure-message I could probably shoot it.

2 1

Re: Fixes to wininet.dll
by Uwe Bonnes 23 Nov '03

23 Nov '03

>>>>> "Jens" == Jens Briesofsky <jeb(a)swym.net> writes: Jens> My first set of patches contributed to wine, the results of my Jens> struggle getting Climateprediction.net to work... Perhaps consider writing test cases for yoyr finding to. Look at ../wininet/test/ how that is done. 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

configure patch to be clear about the state of opengl support
by Chris Morgan 23 Nov '03

23 Nov '03

Someone on irc had trouble with opengl, it wasn't clear whether opengl support was enabled or not. Thought I might throw out a patch to make things more explicit. Chris

1 0

Re: Japanese default GuiFont
by Shachar Shemesh 23 Nov '03

23 Nov '03

Hi, Are you the same guy who does maintains the ODBC driver for Postgresql? Shachar Hiroshi Inoue wrote: -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

1 1

WineX relation to Wine
by Gerhard W. Gruber 22 Nov '03

22 Nov '03

I was wondering what is the relation of Wine to WineX? There is a CVS access to WineX, at least part of it, which is covered under the GPL. What I was wondering about is, wether this code is the same as wine or is it more advanced? Or is this code only the sutff which is also contained in Wine and all the other stuff is (more or less) closed, so that you can not use it for Wine. I was thinking about subscribing to WineX, at least a test for this three month account, to see if the games, I'm interested in, will work. But then I wonder what this would mean if I do some work for Wine. Is this a problem? Can Wine and WineX co-exist as an installation and for development? I know that I was not exactly busy for wine right now, but I try to get pICE in a state where it will be usefull for wine development, because this is my primary goal, but if this will be a problem after being subscribed to WineX I would rather not subscribe and stick with Wine instead. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

6 13

Compiling Wine: tokenize.c problem
by Paul Barclay 22 Nov '03

22 Nov '03

I hope this is the right list for this. Version 20031118 redhat 9 After running ./tools/wineinstall everything goes ok until i get the following: . . . . make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/mshtml' make[2]: Entering directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o tokenize.o tokenize.c tokenize.c:46: `TK_ABORT' undeclared here (not in a function) tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0].tokenType') tokenize.c:46: initializer element is not constant tokenize.c:46: (near initialization for `aKeywordTable[0]') tokenize.c:47: `TK_AFTER' undeclared here (not in a function) tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1].tokenType') tokenize.c:47: initializer element is not constant tokenize.c:47: (near initialization for `aKeywordTable[1]') tokenize.c:48: `TK_ALL' undeclared here (not in a function) . . . . tokenize.c:296: `TK_ILLEGAL' undeclared (first use in this function) tokenize.c:305: `TK_BITOR' undeclared (first use in this function) tokenize.c:308: `TK_CONCAT' undeclared (first use in this function) tokenize.c:313: `TK_COMMA' undeclared (first use in this function) tokenize.c:317: `TK_BITAND' undeclared (first use in this function) tokenize.c:321: `TK_BITNOT' undeclared (first use in this function) tokenize.c:336: `TK_STRING' undeclared (first use in this function) tokenize.c:341: `TK_DOT' undeclared (first use in this function) tokenize.c:348: `TK_INTEGER' undeclared (first use in this function) tokenize.c:353: `TK_FLOAT' undeclared (first use in this function) tokenize.c:370: `TK_ID' undeclared (first use in this function) make[2]: *** [tokenize.o] Error 1 make[2]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls/msi' make[1]: *** [msi] Error 2 make[1]: Leaving directory `/home/pbarclay/downloads/wine-20031118/dlls' make: *** [dlls] Error 2 Could somebody offer a way to fix this? Thanks PB ________________________________________________________________________ E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ________________________________________________________________________

1 0

Re: help with linking needed
by Ralf Juengling 22 Nov '03

22 Nov '03

> I have successfully compiled sources of a Windows application, but > when starting up, it tries to locate and link to a windows dll > to access some C library functions: > > ... > err:module:import_dll No implementation for cw3230.DLL._strlen imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strncpy imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strtok imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._tolower imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._toupper imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:LdrInitializeThunk Main exe initialization failed, status > c0000135 > > First of all: Where does the name "cw3230.DLL" come from -- Wine didn't > install such a dll on my system? Okay, I found the answer to this myself, it is quite embarrassing: Amid the sources that I got there was also the executable compiled on a Windows system by a Borland compiler. Since the winelib-generated make file creates a shared library and not an executable, the spurious native Windows executable was not overwritten by my built. The wineapploader script then started wine with the native Windows executable instead of the shared library "memview.exe.so", and the missing DLL reported above is probably Borlands C runtime library or part of it. So forget about the other questions in my previous posting. Now the problem is that the applicaiton doesn't start but immediately fails with a Segmentation Fault. The problem seems to be in the function GetFullName in files/dos_fs.c; here are the last four lines of a startup trace: 0009:trace:nls:WideCharToMultiByte cp 65010 L"memview.exe" -> "memview.exe" 0009:trace:dosfs:DOSFS_FindUnixName (/local/builts/phaeaco-20031119/src/memview,L"memview.exe") -> L"memview.exe" (L"MEMVIEW.EXE") 0009:trace:heap:RtlFreeHeap (0x401e0000,00000002,401e0918): returning TRUE 0009:trace:dosfs:DOSFS_GetFullName returning /local/builts/phaeaco-20031119/src/memview/memview.exe = L"Z:\\LOCAL\\BUILTS\\PHAE~WVJ\\SRC\\MEMVI\ EW\\MEMVIEW.EXE" Segmentation fault (Note: I had renamed the file "memview.exe.so" to "memview.exe"). I haven't looked into and tried to fix GetFullName yet but will do so next week. Of course, I hope somebody who knows the code well will come up with a fix before I try. :-) Thanks for the Wine, Ralf

1 0

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