- Wine-Devel - list.winehq.org

One step forward two steps back
by Alan Chandler Feb. 12, 2001

Feb. 12, 2001

I noticed that when using winedbg, in konsole of kde, I got an error trying to create the debug terminal. I checked and realised that I did not have xterm installed. So I installed it. Now, when I start winedbg it briefly creates the xterm and almost immediately closes and exits. I don't even get to a first breakpoint before starting the programme, although xterm does have time to complain that it can't find font vga and that its using fixed. What am I doing wrong? TIA Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

2 2

Re: Should Wine use alloca or not?
by Alexandre Julliard Feb. 12, 2001

Feb. 12, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Sure, but the "char buffer[10*PAGE_SIZE]" have the same problem haven't it? > We are not talking about allocation large amounts of space anyway, > but being able to allocate a buffer for ANSI <=> UNICODE translation > on the stack would be useful and most strings are not that large. If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: annoying EndDialog "feature"
by Alexandre Julliard Feb. 12, 2001

Feb. 12, 2001

Andreas Mohr <amohr(a)codeweavers.com> writes: > Windows definitely does NOT do it this way, of course > (well, I'd be surprised if it actually did ;-). > This is just a (crude, if you want) hack to make it work. > And I figured sending WM_NULL shouldn't hurt. That's in the "famous last words" category... please check how Windows does it and try to do it the same way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Should Wine use alloca or not?
by Patrik Stridvall Feb. 12, 2001

Feb. 12, 2001

> > So perhaps we should debate whether we should use alloca or not. > > I'll throw my reasons in: > > -alloca with unknown length argument resolves to a function > call, so isn't as > effiecient as just moving the stack pointer. It does? Even on x86? Why? I'm certainly not an expert on this, but AFAIK you can just dynamically move the stack pointer (SP) register, the base pointer (BP) register will know where the stack frame of the function is anyway. > -it does not fail gracefully, it segfaults (according to the > gcc docs). That is the problem of all cases of runs out of stack. Of course if you allow allocations of more than one page you must have multiple guard pages, but then one page allocation should be enough for most uses in Wine. BTW, haven't void foo(void) { char buffer[10*PAGE_SIZE]; } the same problem. > -Its not available on all platforms True, but does any intresting platform for Wine lack it? > -Over/underwriting stack memory leads to very hard to debug problems > (corrupted stack). Dynamic memory may catch this with page protection. Sure, but the "char buffer[10*PAGE_SIZE]" have the same problem haven't it? We are not talking about allocation large amounts of space anyway, but being able to allocate a buffer for ANSI <=> UNICODE translation on the stack would be useful and most strings are not that large. > -It may not play well with exceptions, and even when it does, > it slows them > down horribly (lists of stack allocated memory must be kept > in order to > unwind the stack correctly). Where we may be mixing c++ and > windows style > exceptions this could be especially bothersome. I (or you) must have missed something but, AFAIK the BP register and not the SP register is used for unwinding. As far as C++ is concerned nobody should expect destructors to be called of alloca:ed memory just like it doesn't on malloc:ed memory. > -Its easy to get it wrong when memory is allocated in a code > block, because > the standard says the memory can be freed at the end of the > block or the > function. Its easy to forget this and use the memory outside > of the block, > which will fail on some implementations. Of course you must be careful with what you do. The same goes for the "char buffer[]" case. > Thats why I say 'style-wise' I don't use it (I do have real > reasons). There > are too many potential problems lurking there for my liking. > I see it as an > optimisation, if required it should be added later, commented > and only once > the need to use it has been demonstrated by profiling. Well, I think for example that stack allocating buffers for ANSI <=> UNICODE translation might be a good idea.

1 0

Re: winebuild ppc
by Ulrich Weigand Feb. 12, 2001

Feb. 12, 2001

Josh DuBois wrote: > @@ -3396,7 +3428,7 @@ > HANDLE OwningThread; > HANDLE LockSemaphore; > ULONG_PTR SpinCount; > -} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; > +} __attribute__ ((aligned (4))) RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; Why? The default alignment of this struct is 4 anyway (as all its members have a default alignment of 4 ...) The only situation where a RTL_CRITICAL_SECTION could conceivably be not aligned to 4 would be if if were embedded into a packed struct. In this case, however, the aligned attribute wouldn't help either AFAIK. (Additionally, the gcc'ism will annoy Patrik ;-/) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 1

Should Wine use alloca or not?
by Patrik Stridvall Feb. 12, 2001

Feb. 12, 2001

> Jon Griffiths wrote: > > > > I don't know anything about the Win32 print API, but style > wise I tend to > > stay away from alloca(). It screws up exception handling > because it messes > > with the stack, and is machine dependant. Maybe > LocalAlloc() would be a > > better choice? > > > > According to the Microsoft web site, LocalAlloc is deprecated in favor > of HeapAlloc and friends. Yes, LocalAlloc is for 16 bit source code compabillity and shouldn't be used by Win32 code. > Can anyone comment on whether using alloca will mess up Wine? (Jon's > comment seems to imply that he avoids alloca on general principles, > rather than for Wine-specific reasons.) Does Wine use exceptions? Wine uses exceptions (sort of), but I don't think alloca will interfer. IIRC the only thing alloca does on x86 is to move the stack pointer to allocate space. The general problem with using alloca is that not all platforms supports alloca, however I think all reasonable platforms that has enough power to support Wine is likely to have it so I don't see any real reason not to use it. Currently Wine uses it indirectly since the files generated by flex/bison uses it. That said Alexandre has at least once rejected patches from me that used alloca, so he doesn't seem to like it. I don't remeber him saying why though. So perhaps we should debate whether we should use alloca or not. Alexandre, can you explain why you have rejected patches with alloca? Have you any better reason that better safe than sorry? Not that it is a bad reason but still...

2 1

AFM-Handling problem
by Joerg Mayer Feb. 12, 2001

Feb. 12, 2001

Moin, Marcus last patch to add default paths for afm files triggered a bug: Inside my font dirs, there is a directory that contains gzipped afm files. After I unzipped these files, wine started up again. Not nice. Ciao Jörg PS: This is the directory *after* decompression of the .afm.gz files: jmayer(a)alice:/usr/X11R6/lib/X11/fonts/Type1 > ls UTBI____.afm c0419bt_.afm c0632bt_.afm cour.afm cursor.pfa lcdxro.afm UTBI____.pfa c0419bt_.pfb c0632bt_.pfb cour.pfa encodings.dir lcdxro.pfa UTB_____.afm c0582bt_.afm c0633bt_.afm courb.afm fonts.dir lcdxrr.afm UTB_____.pfa c0582bt_.pfb c0633bt_.pfb courb.pfa fonts.scale lcdxrr.pfa UTI_____.afm c0583bt_.afm c0648bt_.afm courbi.afm lcdxmo.afm lcdxso.afm UTI_____.pfa c0583bt_.pfb c0648bt_.pfb courbi.pfa lcdxmo.pfa lcdxso.pfa UTRG____.afm c0611bt_.afm c0649bt_.afm couri.afm lcdxmr.afm lcdxsr.afm UTRG____.pfa c0611bt_.pfb c0649bt_.pfb couri.pfa lcdxmr.pfa lcdxsr.pfa jmayer(a)alice:/usr/X11R6/lib/X11/fonts/Type1 > -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

2 1

The Muncher project.
by Josh Walker Feb. 12, 2001

Feb. 12, 2001

I aplolgize for the spelling. I never was any good at english. The muncher project is the implmentation of wine into a very very unique distro of linux and used as a true windows clone. I know, it's not a good name for a project, but it's the best I could come up with after spinning around in a desk chair for five minutes. I also know that this isn't the first time anyone has come up with the idea either, but this is differnt. I have an implentation scheme. I came up with the idea while working on an mp3 player for my car (which also runs linux) There are two HDs in my car stereo. The first is a small 512M drive running linux with all the core compents to make xmms work. The second drive is the mp3 drive, an 8GB removable with FAT32 on it so I can swap it into a windows box too. The mall Linux drive does all the work. It struck me one day that wouldn't it be cool at have a real windows interface for wine. I mean, you can hack the system as much as you can, but when it comes to it, the explorer start bar and all of the activeX do-hickies like control panel and My computer are owned by microsoft. So I devised a plan to make Linux look, run, smell, feel, and act like windows. The goal is to fool my mom by swapping the OS and seeing if she notices. The system works muck like the mp3 player in my car. Two partitons, one is the linux "Macrokenrel" which does all the behind the scenes stuff and the a fat32 partition, which holds the windows files and that the user only sees. The Macrokenel will be a linux partition that has the ability to boot, starts the devices, and then run the neccary core files. The big ones are X, FVWM95, the gnome desktop (Just the desktop, no icons, or panels, no virtual displays, nothing crazy... yet), and wine. Using glade, I will write little replacements for the ActiveX compents that are missing, (My computer, Control panel, etc) GTK will handle the windows "theme" as far as widgets go and fvwm95 is small, sleek, and gives you the right window dressings and a start button. I have here a compiled list of what I plan to add. CORE: Main Kernel -> Linux 2.4.1, USB and harware support big plus/framebuffer for startup screen http://www.kernel.org/ Dos support -> DosEMU 1.0.1 with FreeDOS .98, depending on dos support under wine http://www.dosemu.org/ http://www.freedos.org/ Windows support -> Wine, the latest http://www.winehq.org/ Graphic Display -> Xfree86 4.0.2 more graphics cards, the better font server http://www.xfree86.org DirectX -> Transgameing Explorer(GUI) -> modded FVWM95/Gnome desktop combo ftp://mitac11.uia.ac.be/html-test/fvwm95.html http://www.gnome.org Explorer(filelister) -> gmc (was Midnight Commander, swallowed by Gnome) http://www.gnome.org Explorer(Browser) -> Mozilla (activeX compent, full browser) http://www.iol.ie/~locka/mozilla/mozilla.htm http://www.mozilla.org/ DO-HICKIES & THINGAMABOBS: These are small apps that are written in gtk (possably quick glide apps) that mimic the function of native windows apps. My Computer -> GTK do-hickie that looks like My Computer Launches gmc and the contol panel do-hiokie. System -> GTK do-hickie that will list devices that are valid in /dev in a windows format, intermixed with kernal modules and stuff from kudzu. Network Neighborhood -> LinNeighborhood/Samba http://www.bnro.de/~schmidjo/ Trash -> Gnome's trash Display Properties -> GTK do-hickie that edits xf86config, xscreensaver, and fvwmrc is a windows fimilar way Dial-up Networking -> working for an ISP, I know this thing foreward and backwards do-hickie that writes chat/pppd scripts, easy! Control Panel -> Ugh! Do what WinME does. Make it simple unless you want complex. Start with date/time, internet options, display, printers, and totaly ignore add/remove programs for now. Complex will have date/time, display, fonts, internet options keyboard, modems, mouse, network, passwords, printers regonal settings, scedualed tasks, system Date/Time -> simple GTK app internet options -> working for an ISP know this foreward amd backwards too edits chat/pppd scripts Printers -> Wrapper for redhat's printtool w/ tweaks add/remove programs -> not gonna touch this with a 10 foot pole. maybe later fonts -> links to the font dirs in X keyboard -> edits keyboard properties and Xkeyboard settings who's config file escapes me for the moment. modems -> chat script tweaking mouse -> gtk app that pays with mouse bindings network -> know this back and foreward too, grabbs info from the loaded kernel modules passwords -> password wrapper for xdm, gdm, *dm password thingies regonal settings -> sets loocale varible sceduled tasks -> wrapper for editing the chrontab It's a big task, but I have faith in myself. I'm going to be build a "base system" tomarrow (Ceryix 133, 40M ram, Sound Blaster, Matrox graphics card, and a 814M HD) Feel free to comment. I have no web page on the porject yet, I don't want to call attention to myself in case it turns out to be a bigger project that I intended. Maybe we can use a form of this as a DirectX-compatible only OS that can just run games. Look out X-box ^_^ -Halkun

1 0

Small DDraw problem
by Lionel Ulmer Feb. 12, 2001

Feb. 12, 2001

Hi all, After seeing the reports on cemw of Grim Fandango not working anymore, I decided to check it out. Install worked fine, but the game did not work. It stopped just after doing a SetCooperativeLevel. After some checkings, the error came from there (file dlls/ddraw/ddraw/main.c) : HRESULT WINAPI Main_DirectDraw_SetCooperativeLevel(LPDIRECTDRAW7 iface, HWND hwnd, DWORD cooplevel) { (....) if ((This->cooperative_level & DDSCL_EXCLUSIVE) && (cooplevel & DDSCL_EXCLUSIVE)) return DDERR_EXCLUSIVEMODEALREADYSET; (....) } Grim Fandango did the following : fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000051) - DDSCL_FULLSCREEN DDSCL_ALLOWMODEX DDSCL_EXCLUSIVE (...) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000011) - DDSCL_FULLSCREEN DDSCL_EXCLUSIVE I wonder if this test is really needed ? My interpretation of the 'DDERR_EXCLUSIVEMODEALREADYSET' error was that ANOTHER application already used this flag, not that it was already set for the current application. Anyway, removing this test fixed Grim Fandango. It now starts fine, except for some palette problems. If you agree, I will submit a patch that removes this test :-) Lionel PS: I found out that Grim Fandango eats up my X auto repeat (I need to do a 'xset r on' after)... I thought that this was removed in recent Wine versions ?

4 3

Explorer/shell question.
by Rob Landley Feb. 12, 2001

Feb. 12, 2001

I don't personally use windows, but I have a lot of friends who do. I just showed a friend 98lite.net (which has apparently gone commercial in the last year or two; I was actually looking for the list of instructions the used to have on how to replace the 98 I.E. based explorer with the 95 filesystem only explorer and delete I.E. from the system). Unfortunately, the 95 explorer, being MS intellectual property, can't be included with 98lite, they have to have a copy of 95 (pre OSR 2.5) lying around. I vaguely remembered this list discussing cloning the filesystem explorer months and months back, so my next thought was to wander over to winehq and see if you guys had cloned the filesystem explorer in such a way it could potentially be cleaned up and used to browse the filesystem so I.E. can be deleted. I didn't find one here, so I'm guessing the outcome of said discussion was "no, we aren't going to do that", but it seemed to be a question worth asking anyway. So: has anybody simply cloned the 95 explorer yet? Would the clone run under windows itself? How deeply does it have its tentacles into the guts of the rest of the system? Where would I go to look for such a thing? Rob __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

3 2