wine-devel April 2003

wine-devel@winehq.org

121 participants
314 discussions

Fwd: ALTGR Problem
by Sylvain Petreolle 13 Apr '03

13 Apr '03

Welcome to the club ;-) ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: dos games, vesa and wine
by Jukka Heinonen 13 Apr '03

13 Apr '03

Enrico Horn wrote: > I tried my dos4gw games with dos32a and they "work"(except some warning dos32a > prints) but you have to run these games like this to get an result: > wine -- dos32a game.exe > thats is because the stub which loads the dos extender doesnt work and i have > no idea why. Neither dos4gw stub loader nor dos4gw itself work. Making these work would be nice, but since there are free, compatible DOS extenders available that work rather well with Wine, I'm not particularly interested to figure out what is wrong with them. I have toyed with an idea of trying to contact dos4gw authors (if I can find them) and ask them if they could help, but I'm just too lazy for this kind of stuff. > the games i use all make use of vesa > they want 640x480x256 > ddraw traces show a primary surface that is 8bit paletted. > is there any problem drawing this thing? > where is this done? > is there a routine that regularly updates the screen with content of this > surface? > i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and > havent found anything but i am not expert at this and just poke around > randomly where i see an interest. That mode should work with DOS VESA emulation. It could be that those programs use VESA features that are not supported or that VESA emulation is faulty. It is also possible that those programs are waiting for timer interrupt which is not delivered in protected mode (I have a good idea how to do this, but we shall see when I have time to implement it). See dlls/winedos/int10.c and dlls/winedos/vga.c. It is unlikely that DOS display problems are due to x11drv bugs. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

LdrGetDllHandle with FlashMX demo
by Darren Cook 13 Apr '03

13 Apr '03

Hi, When trying to run the FlashMX Demo version I got about 120 lines of: fixme:module:LdrGetDllHandle Unknown behavior, please report It then dies with "Failed to initialize Vbox! (0010-0069-0090)". I wasn't sure whether to report it in bugzilla or here as I'm not sure if you consider this a bug. So I thought I'd try here first. I'm using this version of wine: wine-20030408-1rh8winehq.i686.rpm (plus stdole32.tlb, copied from winXP machine). FlashMX demo was copied over from a winXP installation (I couldn't get the installer to run under wine). I also have a full version of FlashMX which works (well, some rough edges :-), also by copying over from winXP. If you need more information, or want me to try in debug mode, etc. let me know (I'm not subscribed to the list). Darren

2 1

Re: OLE storage SetFilePointer fix
by Marcus Meissner 13 Apr '03

13 Apr '03

On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote: > Hi all, > > the OLE storage code basically disabled itself, by doing a > READ_HEADER; > in STORAGE_get_pps_entry(). > This READ_HEADER uses -1 as block number for STORAGE_get_big_block() > (in order to retrieve the storage header block). > And if you look at the SetFilePointer() in STORAGE_get_big_block(), > you might notice that (n+1)*BIGSIZE for some strange reason evaluates > to 0, for n == -1. > Thus, SetFilePointer() seeks to position 0 to read the storage header. > > And now I'm terribly sorry to tell you that STORAGE_get_big_block() > did a > if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET )) > { > WARN(" seek failed (%ld)\n",GetLastError()); > return FALSE; > } > > Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to > position 0, eh? > > In other words: > - fix blatantly wrong SetFilePointer() calls The 16bit storage code is probably not safe to work with, for instance saving is probably not working. It should call forward to the 32bit storage code, which I think is more correct. Ciao, Marcus

1 0

Re: OLE storage SetFilePointer fix
by Alexandre Julliard 12 Apr '03

12 Apr '03

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... You know, nobody prevents you from implementing a better patch tracking system, and if it makes my life easier I'll be more than happy to use it. Or if you don't want to write code, you could volunteer to manually keep track of all submitted patches and resubmit the lost ones. But of course that's a lot more work than simply complaining about it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: video mode changes
by Lionel Ulmer 12 Apr '03

12 Apr '03

Hi, I have some comments on this patch : > + if (devmode->dmFields & DM_BITSPERPEL) > + { > + if (devmode->dmBitsPerPel != GetSystemMetrics(SM_WINE_BPP)) > + continue; > + } This may cause problems... It's not per-se a problem in your patch, but from what I know Windows applications expect to have '32' on a 24/32 display and Wine stores here '24'. So you may 'refuse' some modes that should be valid. (again, if ever you have a graphic card still supporting 24/24 mode, please tell me so that I can torture your XFree libraries to find a valid way of checking the difference between 24/24 and 24/32) > + SYSMETRICS_Set( SM_CXSCREEN, devmode->dmPelsWidth ); > + SYSMETRICS_Set( SM_CYSCREEN, devmode->dmPelsHeight ); This are actually 'User' internal functions ? In that case, why not just do the resolution change in the X11 driver and let User itself handle the sysmetric change ? I.e. call these in the 'ChangeDisplaySettingsExW' function and not in the low-level graphic driver. Now my most important grief : did you think about all the people who 1) use Desktop mode and 2) disable XVidMode in their config file ? For those, applications may now abort saying 'Vidmode not supported' (whereas it was working just fine before because we accepted all modes that are smaller than the actual screen size). So I would say that if no VidMode is present or if the User driver function does not exist in the driver, the old 'stub' API should remain as it is. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 3

Re: winedos / Improve tracing
by BiGgUn 12 Apr '03

12 Apr '03

Why didn't you use TRACE instead of DPRINTF ? Stephan

1 0

Toolbar debug message
by BiGgUn 12 Apr '03

12 Apr '03

Hi How can i see debug messages from toolbar.c ? Neither '--debug-msg trace+toolbar' nor '--debug-msg +toolbar' works. The '+loaddll' option claims that i use the _builtin_ version of comctl32. I do not have no more ideas :( Stephan

2 1

Wine 0.9 TODO v0.8
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

Hi folks, The next version of the 0.9 TODO is way past due (again!), and today is as good as any other day for a brand new release: http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html ChangeLog * Jer finished the WineHQ redesign (A1) * Brian completed the screenshot galery (A4) * Adam is our new Slackware maintainer (A6) * Andreas updated the User & Development Guide (B1,B3) * I took on the Packaging Guide and Winelib docu (B2,B4,B8) * New task: more modular doc building (B12) * I've updated and integrated Jaco's winecfg into the tree (C2) * John did more work on the DLL registration (C5) * Shachar got a working version of wineboot into the tree (C7) * I finished messing with wrc (D5) * I got winegcc to a working state (D6) * Marcus made the printing system detection dynamic (E3) * Eric improved WinHelp some more (E6) Please note that this version has been in the making for almost 4 month! Lot's of stuff changed, feedback is much appreciated. -- Dimi.

3 2

Re: PATCH: video mode changes
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

On April 12, 2003 12:16 am, Alex Pasadyn wrote: > + if (TRACE_ON(x11drv)) > + { > + MESSAGE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);MESSAGE("\n"); > + MESSAGE(" bpp=%ld\n",devmode->dmBitsPerPel); > + MESSAGE(" width=%ld\n",devmode->dmPelsWidth); > + MESSAGE(" height=%ld\n",devmode->dmPelsHeight); > + MESSAGE(" freq=%ld\n",devmode->dmDisplayFrequency); > + } Please don't use MESSAGE. Use TRACE instead, it will do the right thing. This piece can be rewritten as: TRACE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);TRACE("\n"); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); Also, it will be a lot nicer if you rewrite _dump_DM_dields to return a string, so you can write: TRACE("\tDM_fields=%s\n", debug_DM_fields(devmode->dmFields)); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); The debug_DM_fields() function would than look like so: static const char* debug_DM_fields(DWORD fields) { BOOL first = TRUE; char buf[128] = "", *p = buf; #define DEBUG_FIELD(x) if ((fields) & DM_##x) { p += sprintf(p, "%s%s", first ? "" : " ,", #x); first = FALSE; } DEBUG_FIELD(BITSPERPEL); DEBUG_FIELD(PELSWIDTH); DEBUG_FIELD(PELSHEIGHT); DEBUG_FIELD(DISPLAYFLAGS); DEBUG_FIELD(DISPLAYFREQUENCY); DEBUG_FIELD(POSITION); #undef DEBUG_FIELD return wine_dbg_sprintf("%s", buf); } -- Dimi.

2 1

← Newer
1
...
15
16
17
18
19
20
21
...
32
Older →

Jump to page:

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 April 2003