September 2002 - Wine-Devel

Re: Listview updates (G0)

by Sylvain Petreolle

Thus can we consider the result of : grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs here " ? > Which means that notify_dispinfoT is broken. This way we find the > bug, > which is my point exactly against adding this zero memory calls. Not > only > they bloat the code, making it slower, harder to read, etc., but most > importantly they hide exactly this types of bugs. We can not go ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Sept. 29, 2002

Re: Fix to protect users from selves.

by Andreas Mohr

On Sun, Sep 29, 2002 at 09:03:24PM +0200, Sylvain Petreolle wrote: > Me to... This name is absolutely correct and could be used by another > program. > I verified it : I created a file called !$!$.txt and a directory on my > desktop under Windows NT. Yep, exactly. Please research the exact names/content of certain registry keys instead that some people suspected to be necessary to prevent Explorer from setting the World on fire. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Sept. 29, 2002

Re: Fix to protect users from selves.

by Sylvain Petreolle

Me to... This name is absolutely correct and could be used by another program. I verified it : I created a file called !$!$.txt and a directory on my desktop under Windows NT. --- Dmitry Timoshkov <dmitry(a)baikal.ru> a écrit : > "Guy L. Albertelli" <galberte(a)neo.lrun.com> wrote: > > > files/file.c > > - Prevent Explorer.exe from renaming directories to !$!$... > > I'm strongly against adding such kludges in the Wine source. > > -- > Dmitry. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Sept. 29, 2002

Re: Debugger no more starting

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> The event-handle is passed to the winedbg command line: >> trace:seh:start_debugger Starting debugger format_size 58 >> (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) >> trace:seh:start_debugger >> h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100 Alexandre> The problem is that your debugger path points to a Unix Alexandre> script, and the new exe loadorder support no longer starts Alexandre> Winelib apps that way. The winedbg script should be used only Alexandre> when starting from the Unix command line, from inside Wine Alexandre> you need to specify a .exe or .exe.so instead. If your Alexandre> WINEDLLPATH is set correctly (which should be the case when Alexandre> running inside the source tree) you should be able to simply Alexandre> use "winedbg.exe" without any path. Thanks, that did the trick. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 29, 2002

Printing with CUPS

by Mason Kidd

I'm having trouble printing using CUPS. When I try and print in notepad I get a dialog saying: Cannot print the Untitled file. Be sure that your printer is connected properly and use Control Panel to verify that the printer is configured properly. My setup is Redhat 7.3 with the following CUPS packages: cups-libs-1.1.14-15 cups-drivers-hpijs-1.1-0.20020313.3 cups-devel-1.1.14-15 cups-drivers-pnm2ppa-1.1-0.20020313.3 cups-1.1.14-15 cups-drivers-1.1-0.20020313.3 I have tried both wine-20020409 and the latest CVS. I am printing to a HP Laserjet 1100 using the "HP LaserJet 1100, Foomatic + gimp-print" driver. This is setup to print using IPP to a print server that is also running CUPS(same version). I have not modified any of the printing or fonts options in the wine config file, since the instructions say it is automatic. I am printing from Notepad. Doing a trace of the PSDRV, it reads all of the AFM files and detects the fonts ok. Also, during ParsePPD it finds all of the paper sizes correctly. But then I get a message: trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'hplj1100' trace:psdrv:PSDRV_FindPrinterInfo No 'FontSubTable' for printer 'hplj1100' And then when it tries to print: trace:psdrv:PSDRV_CreateDC (WINEPS hplj1100 LPT1: (nil)) trace:psdrv:PSDRV_UpdateDevCaps ImageableArea = 0,0 - 0,0: PageSize = 0x0 trace:psdrv:PSDRV_UpdateDevCaps devcaps: horzSize = -2147483648mm, vertSize = -2147483648mm, horzRes = 0, vertRes = 0 Which doesn't seem right. It then selects the pen and brush, and looks like it will print, and the it calls DeleteDC. I have attached the full trace, with +psdrv and +commdlg. I have a full trace at: www.mrkidd.com/~mrkidd/print.trace.txt It really seems like it is almost working, but something is wrong with the paper size. How can I find why it sets everything up and then deletes the DC? Anyone have any ideas? Mason Kidd

Sept. 29, 2002

Re: Debugger no more starting

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > The event-handle is passed to the winedbg command line: > trace:seh:start_debugger Starting debugger format_size 58 > (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined > bg %ld %ld) > trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100 The problem is that your debugger path points to a Unix script, and the new exe loadorder support no longer starts Winelib apps that way. The winedbg script should be used only when starting from the Unix command line, from inside Wine you need to specify a .exe or .exe.so instead. If your WINEDLLPATH is set correctly (which should be the case when running inside the source tree) you should be able to simply use "winedbg.exe" without any path. -- Alexandre Julliard julliard(a)winehq.com

Sept. 29, 2002

Re: Wine ToDo's

by Eric Pouech

> Aspect or Component: > > * More DLL Separation > * BiDi support > * Review of Wine Server Protocol > * Finalize Server Protocol > * PAM (Pluggable Authentication Modules) > * Visual C++'s native COM support > * Add DWARF2 support > * Speed up PDB support > * Create replacement of browser component (Internet Explorer/I I don't think it's a good idea to add Dwarf II support to winedbg (see http://perso.wanadoo.fr/eric.pouech/wine_and_gdb.html for the details) it would be much more valuable to add the MSC/PDB infor support to gdb A+

Sept. 29, 2002

Re: Accept -g3 stabs info (sketchy?)

by Eric Pouech

> BTW, I did manage to crash things in gdb proxy mode. Running > Delphi 5 (my unrealistic fantasy is to get integrated debugging > working in Delphi), I hit (in programs/winedbg/gdbproxy.c): > > 1853 i = write(gdbctx->sock, gdbctx->out_buf, gdbctx->out_len); > > 1854 assert(i == gdbctx->out_len); > 1855 /* if this fails, we'll have to use POLLOUT... > 1856 */ > > I'm looking into fixing this myself, but don't hold your breath. well, it means that we need to implement the pollout stuff for writting our buffer back... not very complicated, but not the easiest stuff to start with > Also: I've printed out the 100+ page Dwarf II spec. It's > probably /way/ beyond my abilities to implement Dwarf II > for winedbg but I figure it'd be an interesting learning > experience to try, and I noticed that this is on the TODO > list. DwarfII shouldn't be on the TODO list. IMO, it's way better to integrate PDB (and the like) symbol manipulation in gdb and use the proxy version of winedbg > Another, more realistic, side-project I'm considering is > to implement tab-completion and up-down arrow > command-history in winedbg. - for the up/down, it's already in there... (in fact, use the emacs form of command ctrl-P ctrl-N - if you really want up/down, you just need to change the mode of the console (in winedbg.c) (or move this settings as a configuration option) - implementing tab completion would require quite of work + reimplement tab processing + reimplement lexical analysis => I'm not sure it's worth it... for most commands you have shortcuts which speed up things A+

Sept. 29, 2002

Re: Accept -g3 stabs info (sketchy?)

by Greg Turner

On Sunday 29 September 2002 08:53 am, Eric Pouech wrote: > however, it's strange that your gdb like debuggers crash in -gstabs2 > mode no crashes, just some weirdness. using -gstabs2, I get relative paths all over the place, including lots of "../../xxx.c" paths, laid out in an inconsistent manner. Sometimes it's just looking for "xxx.c", etc. It becomes very hard to satiate all of these. I've seen posts from other people (can't seem to find any examples now) who seem to have the same problem (i.e., "I run ddd and it says 'cant find main.c'"). When I use -gstabs3, the problem vanishes, and both native debuggers and winedbg seem much happier. Probably a gcc3.2-specific problem. BTW, I did manage to crash things in gdb proxy mode. Running Delphi 5 (my unrealistic fantasy is to get integrated debugging working in Delphi), I hit (in programs/winedbg/gdbproxy.c): 1853 i = write(gdbctx->sock, gdbctx->out_buf, gdbctx->out_len); > 1854 assert(i == gdbctx->out_len); 1855 /* if this fails, we'll have to use POLLOUT... 1856 */ I'm looking into fixing this myself, but don't hold your breath. I'll submit another patch to handle 'k' and 'B' symbols as you describe. I'm glad to see your way works, I considered that, but I thought it was too good to be true :) Now that I look at what I was doing, the union doesn't get copied over so it's probably even more incorrect than I thought. Also: I've printed out the 100+ page Dwarf II spec. It's probably /way/ beyond my abilities to implement Dwarf II for winedbg but I figure it'd be an interesting learning experience to try, and I noticed that this is on the TODO list. Again, don't hold your breath, chances of even limited success at this point in my learning curve are VERY slim! Another, more realistic, side-project I'm considering is to implement tab-completion and up-down arrow command-history in winedbg. It looks like to achieve this I'd need to split the code for reading lines into interactive and noninteractive modes... got any smart advice on this? Is there any good reason /not/ to do it? -- gmt "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

Sept. 29, 2002

Debugger no more starting

by Uwe Bonnes

Hallo, since some time for me the debugger doesn't start when a program crashes. As there was a lot of reorganization, my non-standard setup (try to run wine in place) and due to lack of time to verify (workload, holidays) I can't tell when exactly the breackage occured. The exception (here in a simple test program, doing an int21 in 32 bit mode), the exception is thrown. win32/exception.c:start_debugger_atomic() creates the event 088f7250: queue_exception_event() = 0 { handle=0 } 088f7250: create_event( manual_reset=1, initial_state=0, inherit=1, name=L"") 088f7250: create_event() = 0 { handle=100 } wine: Unhandled exception, starting debugger... ... The event-handle is passed to the winedbg command line: trace:seh:start_debugger Starting debugger format_size 58 (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100 088f7250: *signal* signal=14 088f7250: create_file( access=80000000, inherit=0, sharing=00000001,create=3, attrs=00000000, drive_type=4, f ... We select on that handle: 088f7250: select( flags=4, cookie=0x412d05e0, sec=0, usec=0, handles={100} ) ... After winedbg startup, winedbg tries to set this event 088f75a0:Ret kernel32.DebugActiveProcess() retval=00000001 ret=404e1f04 088f75a0:Call kernel32.SetEvent(00000064) ret=404e33b6 088f75a0: event_op( handle=100, op=1 ) 088f75a0: event_op() = INVALID_HANDLE 088f75a0:Ret kernel32.SetEvent() retval=00000000 ret=404e33b6 but the event is invalid and winedbg shuts down immediately: 088f75a0:Call kernel32.ExitProcess(00000000) ret=404ca18f Any idea, what's going wrong? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 29, 2002