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

Re: Unicode, i18n support

by Dmitry Timoshkov

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On March 31, 2002 05:30 am, Dmitry Timoshkov wrote: > > One more thing that should be addressed IMO as the part of the unicode > > support in Wine: file APIs. For instance in the current state all russian > > file names created by windows programs are completely unreadable in Linux > > because they are created in code page 1251 but native russian encoding > > in Linux is KOI8-R (code page 20866). Therefore all file APIs should > > work with unicode natively, and convert file names to code page specified > > somewhere in the config file (like [x11drv]/TextCP) on create, and vice > > versa on reading file names from disk. > > > But even that is changing in Linux, where filenames should use UTF8. Wouldn't > that suffice? Do you mean that all syscalls that accept filename as parameter, can handle UTF8 encoded file names? Starting from what version of kernel? I'm afraid that will help to Linux only based installations of Wine, and in any case all functions in Wine implementing file APIs should internally use unicode. -- Dmitry.

March 31, 2002

Re: CreateProcess design

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > what should we do. I think Alexandre long term option is to really get > rid of the options on the command line and use the WINEOPTION(S) env > var (we could still have a wrapper script to do the conversion) > > should we adopt this right away or clean up the command line option ? The basic idea is to have two separate programs; a 'wine' that does all the command-line processing, and a 'wineloader' that simply executes a new process from CreateProcess. Then all the option handling can be moved out of kernel and into that wine program. Winelib apps will then need to do their own command-line handling, the kernel will simply pass them the unmodified cmdline (though it should still be possible to launch a Winelib app through the 'wine' program to make it handle wine options). > as a consequence, you no longer can use any CUI program in the > user/graphical mode, including winedbg - it still work as a unix console > though I've added a quick hack to fix this for now. -- Alexandre Julliard julliard(a)winehq.com

March 31, 2002

Re: problems with the alt button and window switching

by Alexandre Julliard

Rizsanyi Zsolt <rizsanyi(a)myrealbox.com> writes: > That is the key state has been changed. And when I return to the wine window > (by keyboard or mouse) it acts like if the ALT button were depressed. This is supposed to be handled by the KeymapNotify event handler. It's quite possible that it is broken right now though. -- Alexandre Julliard julliard(a)winehq.com

March 31, 2002

WineLib newbie question

by Boris Buegling

Hi all. I'm wondering how difficult it is to port an application to Linux with WineLib. There are quite a few N64 emulators with source code on Windoze and I want to port one of them to Linux, because there is no decent native emulator, First, is it possible that things which don't work well with Wine, work when they are ported using WineLib ? Second, how much work is involved ? Regards, -- Boris Buegling <boris(a)icculus.org> "Sleep less - live longer." - "Ok good, 1 down... Now all I need is beer, video games and hacking to be linked to living longer and I'm set." "If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science."

March 31, 2002

Re: Unicode, i18n support

by Dimitrie O. Paun

On March 31, 2002 05:30 am, Dmitry Timoshkov wrote: > One more thing that should be addressed IMO as the part of the unicode > support in Wine: file APIs. For instance in the current state all russian > file names created by windows programs are completely unreadable in Linux > because they are created in code page 1251 but native russian encoding > in Linux is KOI8-R (code page 20866). Therefore all file APIs should > work with unicode natively, and convert file names to code page specified > somewhere in the config file (like [x11drv]/TextCP) on create, and vice > versa on reading file names from disk. But even that is changing in Linux, where filenames should use UTF8. Wouldn't that suffice? -- Dimi.

March 31, 2002

Re: Unicode, i18n support

by Shachar Shemesh

Francois Gouget wrote: > Bug 98 - Unicode, i18n support is quite vague. How could I flesh it >out? > >For instance I am thinking that we could convert this into a >metabug and have one sub bug for each control that still needs to >be unicodified. So: > * which are the common controls that still need to be unicodified? > * are there other controls that need to be unicodified > * do common dialogs need work? > > As usual the goal is to make the individual tasks more visible so as >to give inspiration to potential contributors, and so that we have a >better idea of our progress and what remains to be done. > > > Another issue, which would fall more in the i18n part is BiDi >support. What is the scope of this? Does it require modifications of >all the controls like unicode? > >http://www.winehq.com/hypermail/wine-devel/2002/03/0236.html > > Shachar, it sounds like you started working on this, should I say so >when I create a bugzilla task for this? Even better, can I assign the >task to you? (it can always be reassigned later, it's just a more >flexible way of doing things). > Sure, assign it away. In general, I am not sure what my exact role is going to be, as it seems IBM may be picking up this glove, and they have a month and a half and two men fore on me (not to mention full time vs. off hours). If you do assign it, use "winebugzilla.at.sun.consumer.org.il" as my email address, please. Shachar > > >-- >Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Broadcast message : fin du monde dans cinq minutes, repentez vous ! > > >

March 31, 2002

Re: Unicode, i18n support

by Dmitry Timoshkov

"Francois Gouget" <fgouget(a)free.fr> wrote: > Bug 98 - Unicode, i18n support is quite vague. How could I flesh it > out? > > For instance I am thinking that we could convert this into a > metabug and have one sub bug for each control that still needs to > be unicodified. So: > * which are the common controls that still need to be unicodified? I believe that all standard USER controls are already coverted to unicode. > * are there other controls that need to be unicodified Probably controls provided by comctl32 need some additional work. > * do common dialogs need work? Probably. One more thing that should be addressed IMO as the part of the unicode support in Wine: file APIs. For instance in the current state all russian file names created by windows programs are completely unreadable in Linux because they are created in code page 1251 but native russian encoding in Linux is KOI8-R (code page 20866). Therefore all file APIs should work with unicode natively, and convert file names to code page specified somewhere in the config file (like [x11drv]/TextCP) on create, and vice versa on reading file names from disk. > Another issue, which would fall more in the i18n part is BiDi > support. What is the scope of this? Does it require modifications of > all the controls like unicode? GetCharacterPlacement and GetFontLanguageInfo should be properly implemented first. Then only minor tweaks will be required to add support for BiDi to common controls such as Edit. -- Dmitry.

March 31, 2002

Unicode, i18n support

by Francois Gouget

Bug 98 - Unicode, i18n support is quite vague. How could I flesh it out? For instance I am thinking that we could convert this into a metabug and have one sub bug for each control that still needs to be unicodified. So: * which are the common controls that still need to be unicodified? * are there other controls that need to be unicodified * do common dialogs need work? As usual the goal is to make the individual tasks more visible so as to give inspiration to potential contributors, and so that we have a better idea of our progress and what remains to be done. Another issue, which would fall more in the i18n part is BiDi support. What is the scope of this? Does it require modifications of all the controls like unicode? http://www.winehq.com/hypermail/wine-devel/2002/03/0236.html Shachar, it sounds like you started working on this, should I say so when I create a bugzilla task for this? Even better, can I assign the task to you? (it can always be reassigned later, it's just a more flexible way of doing things). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

March 31, 2002

Re: DIB engine

by David Hammerton

On Sat, Mar 30, 2002 at 04:57:09PM -0800, Francois Gouget wrote: We make use of Shared Memory Pixmaps to reduce the copying (in WineX).. So we have app memory which stores the image in the mode requested by the app, this then gets copied into a SHMPixmap of the depth supported by X so X can do whatever it wants to (render to it or whatever) and it then gets copied back when needed, same method.. One of the big savers here is that the ShmPixmap means we dont have to be sending stuff between X server/client, saves alot of time.. As for X supporting multiple depths - I investigated this and talked to some of the X coders, its still not "wonderfully" supported.. ehm, it lacks alot of the most common modes - eg 8bit paletted - its not really worth it from what I can see.. The X developers suggested that if I wanted to go down this road to first write an X extension, ShmPixmaps were nicer and almost as fast... Maybe you would have been able to see this if AoE2 didn't crash on Gav ;-). Cheers David > > But, as far as I can remember, the other big problem comes from the > > 'exception handler' that is needed to detect direct write from the Windows > > program to the DIB (or maybe I am thinking about something completely else > > :-) ) to be sure that the X pixmap and the Windows DIB are always in sync > > one with the other. And that cannot be solved easily with X Pixmaps at all > > (maybe hacking around with XShmPixmaps). > > Yes this endless copying is a performance killer. But even if you are > not concerned about performance there are issues as I mentioned above. > I think Transgaming did some work on optimizing this to limit the > number of copies this but I don't remember the details. Some of it is > already in Wine, I don't know if they have more stuff in WineX / coming > to Wine. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Demander si un ordinateur peut penser revient ? demander > si un sous-marin peut nager. -- David Hammerton Programmer, TransGaming Technologies http://www.transgaming.com/

March 31, 2002

Re: DIB engine

by Francois Gouget

On Sun, 31 Mar 2002, Lionel Ulmer wrote: > > 1. Have X export the required API > > --------------------------------- > > > > XFree86 4 has all the needed code, for all bit depths and layouts we > > care about. We could try to have the X guys export this in the form of > > an API ala Xft. Wine could then link with this library to implement the > > DIB engine (or dlopen that library). > > Well, when I look at the bug report, I see this : > > '* the X bitmap has to be in the format of the X display. So if X is > running in 15bpp, a 32bpp DIB is converted to 15bpp, the operation is > performed in 15bpp, and the bitmap is then converted back to 32bpp. > Obviously this implies that each operation occurs a loss of color > resolution (fortunately they should not accumulate).' > > This is, AFAIK, not a problem anymore on XFree 4 (at least on the drivers > based on the 'fb' driver) as they support all Pixmap depth whatever the > depth of the current screen. For example, on my 16bpp display, 'xdpyinfo' > gives me this : Yes but Wine will refuse to create a pixmap in a bit depth other than that of the X display. So we still incur the loss. Maybe that could be fixed but last time I played with this X was not happy about getting non 16bpp pixmaps. But I'm not an expert on this and did not have muh time to play with it so it is entirely possible that I just did things the wrong way. > So it should support almost all 'usual' formats (except the funky non 555 / > 565 formats or BGR ones that are pretty rare). As far as I can remember, my > Solaris box at work does also support a lot of Pixmap formats even on a > 32bpp screen. There may be problems with the palette for the 'depth 8' > format though. Well, I believe the current code already has issues with this: * start with a paletized DIB, copy it to X and copy it back. A pixel which had index 5 initially may end up being index 10 just because both indexes have the same color. The image should look the same but the index may be significant for the application (maybe 5 is the code for transparency). * copy a DIB to X and change the palette. I am not sure this is handled very well. Can it even be handled properly? Wouldn't we have to find all DIBs we have copied to X and update them all? > But, as far as I can remember, the other big problem comes from the > 'exception handler' that is needed to detect direct write from the Windows > program to the DIB (or maybe I am thinking about something completely else > :-) ) to be sure that the X pixmap and the Windows DIB are always in sync > one with the other. And that cannot be solved easily with X Pixmaps at all > (maybe hacking around with XShmPixmaps). Yes this endless copying is a performance killer. But even if you are not concerned about performance there are issues as I mentioned above. I think Transgaming did some work on optimizing this to limit the number of copies this but I don't remember the details. Some of it is already in Wine, I don't know if they have more stuff in WineX / coming to Wine. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

March 31, 2002