- Wine-Devel - list.winehq.org

Re: winealsa: improve sound quality for IDsDriverImpl
by Jerry Jenkins Oct. 1, 2003

Oct. 1, 2003

> > If the behavior is subject to change, there is no way you can test > that at configure time. This needs to be a run time check. > You're right. So I put some code in configure.ac, try to compile & run it when configure is executed. If everything is OK, a macro will be defined in config.h.

3 6

Re: Translating WINE using dedicated tools
by Ivan Leo Murray-Smith Oct. 1, 2003

Oct. 1, 2003

> and winehq web site This is if Jeremy Newman wants to have the site translated. As I didn't want to translate anything before being sure it would be accepted I've emaild him various times to know if/how winehq should be translated, and I never got an answer.

1 0

Re: Translating WINE using dedicated tools
by Ivan Leo Murray-Smith Oct. 1, 2003

Oct. 1, 2003

Once wine has final docs this would be great, the wine docs will change before 1.0 (The wine-user docs are config-file orientated, and many other things may change before 1.0), the wine-devel docs don't really need translating as most developers know English, and the wine programs and dlls can be translated manually without any difficulty, but once we have a final version of wine user docs and winehq web site this tool could be very useful.

1 0

Re: I/O port access broken (SEH broken)
by Uwe Bonnes Oct. 1, 2003

Oct. 1, 2003

>>>>> "Andreas" == Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: Andreas> Hi all, sounds like the recent architectural changes were a bit Andreas> too much: now I get Andreas> Unhandled exception: privileged instruction in 32-bit code Andreas> (0x0040348b). In 32-bit mode. 0x0040348b Andreas> (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx Wine-dbg> Andreas> with a parallel port flash tool I'm trying to use, whereas Andreas> before it used to work with both direct I/O port access and Andreas> ppdev. Andreas> In other words: exception handling about I/O port access has Andreas> been broken. Another related problem: I need inport/outport in some private VXD reimplementation too. The reimplementation resided in my win32/device.c file. Do I need to do LoadLibrary(winedos) GetProc(xxx,"Inport") in my code now? 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

Re: "Start menu" (continued ...)
by Rolf Kalbermatter Oct. 1, 2003

Oct. 1, 2003

Robert van Herk <robert(a)robertvanherk.nl> >As I understand, right now there are various "standards" on how to write >menus for Linux, that are incompatible. That would mean that writing a >"grand unified ;-)" start menu client as I discussed before is currently >impossible. > >What could be made already though, is a Wine deamon that talks to >shell32.dll internally and input/outputs with pipes to some linux >client, in order to serve the start menu items. This would link the >Windows start menu to Linux, in a tidy way. So the idea is that the >Windows program's output could be piped to some Linux client that >actually creates the menu dynamically, so it stays in continuous >synchronization with your Start menu directory. > <snip> > >Would such a system be appreciated by the you people? Or do you think I >should wait untill a better standarization is available? Or do you think >creating a Windows deamon and a Linux client is too much overkill for >such a feature? > >Also, if this feature would be handy, does anyone have expirience with >the KPanelAppMenu? I can't get the thingy to work yet... Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? Also the Wine start menu will usually contain mostly Windows or Winelib apps, I suppose. The Unix desktop would have to treat those entries accordingly, makeing proper distinction between them and native unix apps/scripts or whatever which of course shouldn't be a real problem. Maybe this has been discussed already in depth and I missed it? Rolf Kalbermatter

2 1

WWN back issues unavailable
by Ferenc Wagner Oct. 1, 2003

Oct. 1, 2003

Hi, I am not sure whom to tell, that In the bottom of the WWN Back Issues page on WineHQ the "Next 12 Issues" link does not really work. Feri.

1 0

Re: RtlGetVersionNumbers
by Alexandre Julliard Oct. 1, 2003

Oct. 1, 2003

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > i don't know why this function was changed when it was moved, but it > breaks > some versions of msvcrt. This puts it back the way it was. There's no reason not to use the version that the user specified. If you are using XP native dlls and they break with a lower version, then you need to specify the Windows version as XP in your config file. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Start menu (especially for Alexandre Julliard)
by Dan Kegel Oct. 1, 2003

Oct. 1, 2003

Francois Gouget wrote: > <rant> > The Linux desktop menus are a total mess. FreeDesktop came up with a > broken standard (vfolders) to 'unify' KDE and Gnome (which were already > pretty similar and relatively easy to work with). > > But what we need is a truly standard way to create menus for all desktop > environments on any Linux distribution. Something like the Debian > menuing system, maybe with improved support for internationalization and > other bells and whistles. > </rant> Well, as it happens, Debian appears to be embracing the FreeDesktop.org "Desktop Menu Specification" (http://www.freedesktop.org/Standards/menu-spec) at least judging by http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00800.html Oh, and who's listed as one of the authors? A certain Francois... IMHO wine should stay far, far away from inventing anything new here, and simply obey the freedesktop.org menu spec (plus, perhaps, a legacy scheme or two until they die off). - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: PATCH: stop crashes in desktop mode
by Alexandre Julliard Sept. 30, 2003

Sept. 30, 2003

Alex Pasadyn <ajp(a)mail.utexas.edu> writes: > This patch just puts in a simple check that traps this condition so > Wine doesn't crash. I don't know enough about what that code is > supposed to be doing to fix it properly. (This is certainly better > enough on my system though as it longer crashes!) If someone wants to > describe what "should" happen there I can look into really fixing it. The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process. -- Alexandre Julliard julliard(a)winehq.com

7 14

"Start menu" (continued ...)
by Robert van Herk Sept. 30, 2003

Sept. 30, 2003

Hi all... As I understand, right now there are various "standards" on how to write menus for Linux, that are incompatible. That would mean that writing a "grand unified ;-)" start menu client as I discussed before is currently impossible. What could be made already though, is a Wine deamon that talks to shell32.dll internally and input/outputs with pipes to some linux client, in order to serve the start menu items. This would link the Windows start menu to Linux, in a tidy way. So the idea is that the Windows program's output could be piped to some Linux client that actually creates the menu dynamically, so it stays in continuous synchronization with your Start menu directory. The Linux client cannot be made unified yet, but I suppose I could at least write a client for KDE. It wouldn't be to messy to add other clients later for other desktop enviroments, since the deamon does not have to change in order to do so. That is, only the neccesairy thingies change. From looking at the help files I suppose KPanelAppMenu could do the trick. Would such a system be appreciated by the you people? Or do you think I should wait untill a better standarization is available? Or do you think creating a Windows deamon and a Linux client is too much overkill for such a feature? Also, if this feature would be handy, does anyone have expirience with the KPanelAppMenu? I can't get the thingy to work yet... Grtz, Robert

2 1