November 2002 - Wine-Devel - list.winehq.org

"not enough space in GDI heap" / forking vstlib programs

by Kjetil S. Matheussen

Hello, as I just announced I'm developing a vst-server, that loads and runs windows vst plugins. But after loading and unloading a lot of plugins, I get lots of "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" errors. I understand that the cause of this error is caused by a memory leak in a windows program. However, in the vst-server, there is no way to control memory leaks in the plug-ins, as those are made by various groups and persons. So is there a way around this error. Doing a fork for each new plug-in perhaps? Is that safe? I want to do that also to avoid having a plug-in crash the vst-server. --

Nov. 29, 2002

Re: wglCreateLayerContext?

by Mike Hearn

Yes, it only calls it with Layer 0. I guess it's just a flexibility thing - the functions we use allow us to choose a layer but we never do. I guess it could just be a passthrough implementation with a ERR if an app ever requires anything other than layer 0? On Fri, 2002-11-29 at 15:43, Lionel Ulmer wrote: > > No idea, I don't even know what they are. The application I'm trying to > > get working is a little open source project I've been involved with for > > the last few years (pythianproject.org) written in Delphi. The OpenGL > > initialization code was produced by the Delphi JEDI organisation which > > probably means it's been reused a fair few times in various Delphi > > OpenGL projects. > > Can you give me the actual parameters used by the application ? Because if > it only ever uses plane '0', Wine can implement it pretty quickly by just > calling the standard CreateContext function. > > Lionel -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Nov. 29, 2002

Re: wglCreateLayerContext?

by Lionel Ulmer

> No idea, I don't even know what they are. The application I'm trying to > get working is a little open source project I've been involved with for > the last few years (pythianproject.org) written in Delphi. The OpenGL > initialization code was produced by the Delphi JEDI organisation which > probably means it's been reused a fair few times in various Delphi > OpenGL projects. Can you give me the actual parameters used by the application ? Because if it only ever uses plane '0', Wine can implement it pretty quickly by just calling the standard CreateContext function. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 29, 2002

somebody help me identify this bug please

by ezra daniel

Hello, At work I use Lotus Notes under Wine. I downloaded compiled and installed the new wine version 20021125 and I am no longer able to type accecented valves, like á é í ó ú. Ñ can be typed though correctly. With the other version 20021031 I could type accented valves.In fact I went back to using the older version and worked again so it is obvious it is a problem in the new wine version. Though I am a newbie and know nothing of developing, but I would like to submit the bug to the proper person so it fixes it back again but I dont know which section of wine or person deals with this character typing problem. Can anyone point me in the right direction? Thanks in advance. -daniel http://www.debian-gnu.com _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

Nov. 29, 2002

Re: final int21 move

by Jukka Heinonen

This patch series starts to look more like what it should be. Previous bugs seem to have been fixed and dependencies between winedos and other dlls have been reduced close to minimum. However, I still find some things that I don't particularly like: - The series is actually one big patch divided into multiple files and not a series of incremental changes. The first patch in series breaks DOS3Call and error reporting of some functions and these are only fixed in later patches. - Old int21 functions contain some obvious bugs that really should be fixed at the same time the code is migrated to winedos. - Move to winedos should not only migrate code but it should also try to rewrite code so that it has better comments, it is more readable and it uses simpler constructs. This patch series really messes up already complicated code. Intendations are irregular and weird. Many newlines are missing. Some internal functions use INT21_ prefixes and some don't. Functions that were implemented as separate helper functions are moved inside int21 main switch case. Three nested levels of switches are used without even proper indentation. And that comment about shooting people is tasteless and really doesn't belong to Wine. I just don't find the quality of this patch acceptable. I don't decide these things but my personal opinion is that I would rather rewrite this patch series than see it accepted in its current state. I wouldn't mind if Nog or someone else works on int21 migration (that's why I haven't posted int21 patches already) but I don't see why I ought to lower my quality requirements due to this fact. -- Jukka Heinonen <http://www.iki.fi/jhei/>

Nov. 29, 2002

Re: cabinet.dll broken?

by Tapio Kautto

Could cabinet be set to: "cabinet" = "native,builtin" automatically by wineinstall as long as it does not work the way expected? Tapio On Thursday 28 November 2002 12:59, Patrik Stridvall wrote: > > I'm trying to install MS Office 2000 on wine-20021125. > > > > I get an error from Office installer: > > > > Internal error 2352. Please contact Product support. > > > > I found an advice to repair my cabinet.dll in Microsoft Support pages. > > > > The file is in ~/c/windows/system, and it's readable. Does > > anyone else have > > problem with this? > > Well. It might be that since very recently, Wine has builtin > stub implementation of cabinet.dll. > > Of course it shouldn't be used automatically if have a cabinet.dll, > since I guess most people (including you) have a: > > [DllOverrides] > ; default for all other dlls > "*" = "native, builtin, so" > > entry in their config file. > > You can force cabinet to native with > wine --dll cabinet=n > though.

Nov. 29, 2002

Re: wglCreateLayerContext?

by Mike Hearn

Well, the case 'iLayerPlane == 0' would be easy as it's the main plane.. But do tell me how you plan to do OpenGL underlay and overlay planes using GLX ? No idea, I don't even know what they are. The application I'm trying to get working is a little open source project I've been involved with for the last few years (pythianproject.org) written in Delphi. The OpenGL initialization code was produced by the Delphi JEDI organisation which probably means it's been reused a fair few times in various Delphi OpenGL projects. Would it simply be easier to alter the application? I wasn't aware that X was unable to do this kind of thing. thanks -mike

Nov. 29, 2002

small updates to debugger.sgml

by Tony Lambregts

Before I could feel right about adding "Advanced Debugging Techniques" to the documnetation I needed to update the documentation on the debugger. There is still one section that is out of date (that I am aware of). The section that I am refering to is as follows > Program hangs, nothing happens > > Switch to UNIX shell, get the process-ID using ps -a | grep wine, and > do a kill -HUP <pid> (without the < and >). Wine will then enter its > internal debugger and you can proceed as explained above. Also, you > can use --debug switch and then you can get into internal debugger by > pressing Ctrl-C in the terminal where you run Wine. > This is _wrong_ since neither work. I have added a fix me message in front of this since I am unable to come up with anything usefull to replace it. If anyone has a usefull suggestion I would appreciate it. Change log: Update the debugger documentation for current usage. Files: /documnetation/debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.13 diff -u -r1.13 debugger.sgml --- debugger.sgml 1 Oct 2002 18:13:09 -0000 1.13 +++ debugger.sgml 29 Nov 2002 06:08:53 -0000 @@ -271,8 +271,9 @@ <para> This file describes where to start debugging Wine. If at any point you get stuck and want to ask for help, please read the - file <filename>documentation/bugreports</filename> for - information on how to write useful bug reports. + <emphasis>How to Report A Bug</emphasis> section of the + <emphasis>Wine Users Guide</emphasis> for information on how to write + useful bug reports. </para> <sect2> @@ -311,8 +312,7 @@ <para> Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information - gathered to the newsgroup or the relevant developer as - feasible. + gathered to the bug report as feasible. </para> <orderedlist> @@ -362,17 +362,26 @@ If you have found a misbehaving function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is - a <function>TRACE(<channel>,"(...)\n");</function> at - the beginning of the function. Rerun wine with + a <function>WINE_DEFAULT_DEBUG_CHANNEL(<channel>);</function> + at the beginning of the file. Rerun wine with <parameter>-debugmsg +xyz,+relay</parameter> added to the commandline. </para> + <para> + Occasionally there are additional debug channels defined at the + begining of the file in the form. + <function>WINE_DECLARE_DEBUG_CHANNEL(<channel>);</function> + If so the offending fuction may also uses one of these alternate + channels. Look through the the function for + <function>TRACE_(<channel>)(" ... /n");</function> and add any + additional channels to the commandline. + </para> </listitem> <listitem> <para> Additional information on how to debug using the internal debugger can be found in - <filename>debugger/README</filename>. + <filename>programs/winedbg/README</filename>. </para> </listitem> <listitem> @@ -386,29 +395,25 @@ </listitem> <listitem> <para> - If even that isn't enough, add more debug output for - yourself into the functions you find relevant. See - <filename>documentation/debug-msgs</filename>. You might + If even that isn't enough, add more debug output for yourself + into the functions you find relevant. See The section on Debug + Logging in this guide for more information. You might also try to run the program in <command>gdb</command> instead of using the WINE-debugger. If you do that, use <parameter>handle SIGSEGV nostop noprint</parameter> to disable the handling of seg faults inside - <command>gdb</command> (needed for Win16). If you don't use - the <parameter>--desktop</parameter> or - <parameter>--managed</parameter> option, start the WINE - process with <parameter>--sync</parameter>, or chances are - good to get X into an unusable state. + <command>gdb</command> (needed for Win16). </para> </listitem> <listitem> <para> - You can also set a breakpoint for that function. Start wine - with the <parameter>--debug</parameter> option added to the - commandline. After loading the executable wine will enter - the internal debugger. Use <parameter>break - KERNEL_LSTRLEN</parameter> (replace by function you want - to debug, CASE IS RELEVANT) to set a breakpoint. Then use - <command>continue</command> to start normal + You can also set a breakpoint for that function. Start wine + useing <command>winedbg</command> instead of + <command>wine</command>. Once the debugger is is running enter + <command>break</command> <parameter>KERNEL_LSTRLEN</parameter> + (replace by function you want to debug, CASE IS RELEVANT) + to set a breakpoint. Then + use <command>continue</command> to start normal program-execution. Wine will stop if it reaches the breakpoint. If the program isn't yet at the crashing call of that function, use <command>continue</command> again @@ -425,6 +430,7 @@ <title>Program hangs, nothing happens</title> <para> + <emphasis>Fix me - this is out of date </emphasis> Switch to UNIX shell, get the process-ID using <command>ps -a | grep wine</command>, and do a <command>kill -HUP <pid></command> (without the < and >). Wine will @@ -449,8 +455,7 @@ </para> <para> Since the failure happens usually directly before setting up - the Messagebox you can start wine with - <parameter>--debug</parameter> added to the commandline, set a + the Messagebox you can start winedbg and set a breakpoint at <function>MessageBoxA</function> (called by win16 and win32 programs) and proceed with <command>continue</command>. With <parameter>--debugmsg

Nov. 29, 2002

Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates

by Dustin Navea

----- Original Message ----- From: "Dimitrie O. Paun" <dpaun(a)rogers.com> To: "Dustin Navea" <speeddymon(a)sbcglobal.net>; "Wine Developers" <wine-devel(a)winehq.com> Sent: Friday, November 29, 2002 5:41 AM Subject: Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates > On November 29, 2002 12:31 am, Dustin Navea wrote: > > Grrr, Im really starting to not like Linux's PPPoE support... > > I know, PPPoE can blow chunks sometimes. I've switched to cable, > and I'm not going back! :) A long time ago in an apartment complex not too far away ;) I had cable and got evicted and had to cancel it. If I had Time Warner in this complex instead of US Online I would have gotten cable, but this was all that I could get and plus it _lowered_ my total phone bill by about $15 a month, long story I will tell later.. > > so until next Wednesday I will probably just lurk on the lists > > Don't worry -- the treeview patch I've submitted is not supposed > to fix anything just yet. Oh man, sooo many things to do, so > little time... > lol, I hear ya, it looks like it is a step in the right direction at least, I will have to admit that at first glance I had thought you removed some essential stuff, but then I looked more carefully, so I should shut up now ;) -Dustin

Nov. 29, 2002

Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates

by Dimitrie O. Paun

On November 29, 2002 12:31 am, Dustin Navea wrote: > Grrr, Im really starting to not like Linux's PPPoE support... I know, PPPoE can blow chunks sometimes. I've switched to cable, and I'm not going back! :) > so until next Wednesday I will probably just lurk on the lists Don't worry -- the treeview patch I've submitted is not supposed to fix anything just yet. Oh man, sooo many things to do, so little time... -- Dimi.

Nov. 29, 2002