August 2004 - Wine-Devel - list.winehq.org

Re: list view completely mangled in WINE

by Tobias Burnus

Hello, Tobias Burnus wrote: > The patch improves the situation a lot! Even Save List works now! > Thanks! I have another strangeness with multi-select lists (e.g. the lists in Diamond but this might affect other lists as well): * I go to a line, press shift and then the arrow keys. If I use arrow down, I can select as many lines as I want. If I use arrow up, I can only select two lines: The line I'm in and the one below, the others further below are unselected as I move upwards. * Multi-select with ctrl doesn't work using the keyboard. Select a line, press ctrl, move up/down to another line and press space. Expected: This line is selected as well. Actual result: Nothing happens (Not a bug, but a missing handy feature: In Windows, double clicking between two column headers (cursor: <-|->) adjusts the column-width so that everything fits. In WINE nothing happens. (Work-around: go to the same place and adjust manually.)) Regards, Tobias, who hopes that the submitted patches get applied to CVS.

Aug. 5, 2004

Is check for WS_THICKFRAME style really needed for sizing?

by Santosh Siddheshwar

Hi, Is the check for windows WS_THICKFRAME style really needed to decide whether a window can be resized or not? I have a scenario where this style is not set but the user can still size the window. This is being done by dispatching WM_SYSCOMMAND messages with SC_SIZE command but WINE is preventing these messages from being effectively handled by returning from the SysCommandSizeMove (winpos.c) method, without doing anything, if the window in question doesnt have this style set. Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

Aug. 5, 2004

warning when configuring wine-20040716 on OpenBSD 3.5+

by Angelos D. Keromytis

configure: WARNING: sys/sysctl.h: present but cannot be compiled configure: WARNING: sys/sysctl.h: check for missing prerequisite headers? configure: WARNING: sys/sysctl.h: see the Autoconf documentation configure: WARNING: sys/sysctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/sysctl.h: proceeding with the preprocessor's result configure: WARNING: sys/sysctl.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/sysctl.h... yes

Aug. 5, 2004

Fwd:Novell client

by Ivan Leo Puoti

new ad request.

Aug. 4, 2004

Re: Wine and locales

by Shachar Shemesh

David Lee Lambert wrote: >>I don't agree. Mixing default codepages across simultaneously running >>programs is not possible on Windows, and sounds horribly difficult to >>implement. Clipboard handling and cross-file using are two examples of >>things that are likely to go horribly wrong if we tried. >> >> > >If a program does a an ANSI call, it gets changed to Unicode. If that >data gets passed back to another program using an ANSI call, it gets >converted to the target codepage, as much as possible. If Wine is doing >console output to a non-Unicode codepage, it gets converted there too. > > Ok, you convinced me. Implement that in a way that Alexandre will deem fit for commit, and I won't object too loudly. I do believe that you will not succeed with the first part, however. >I'm not sure about mixing codepages under Windows, but input-method >switching is easy. > > True, but irrelevant. >>Having one setting applicable to all running processes sounds good >>enough. I don't object to a config setting overriding what LC_CTYPE >>says, but I don't see a use for it either. >> >> > >Let's say I want to run an Arabic dictionary program and Spanish >dictionary program as I'm typing a report in Word. Furthermore, the >arabic dictionary program would use ANSI calls and expects to run on >Arabic windows (with MS-ARAB encoding); the Spanish program would use >LATIN1. Word uses wide-character calls. How would I run all these >programs at the same time under Wine? > > Forget that. How would you run that under Windows? As far as I know, you can't do it there either. Coming from a country where a large portion of the population are native Russian speakers in a country where the dominant language is Hebrew, I'm pretty sure that I'd hear about it if it were possible. >(I'm not saying I actually have such a set of programs. Actually, I own >a copy of a standalone program that allows typing of Arabic programs on >Western windows, and also have access to systems where Office XP with the >Arabic and US-International input methods is installed.) > > Yes. That's because they either use the Unicode interface, or implement their own rendering engine. In short, I think what you're trying is impossible under Windows. I can also see some immediate implications to trying to do it in Wine. If it's important to you, you're welcome at it. It will not enter my personal todo list, however. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 4, 2004

Re: winedos: dos debugger support

by markus.amsler＠oribi.org

Quoting Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>: > What does this patch do? Does it do what I believe it does?? :-) > (finally provide useful debugging for DOS programs launched by Wine?) Yeahp. For Debugging .com files you also have to apply the EXEC fix patch [1]. For line editing support, apply BUFFERED INPUT patch [5]. Tested Debuggers (for more see [2]): - Microsoft's debug.exe - ddeb.exe (my favorite) [3] - debug.com (with source) [4] Markus [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0044.html [2] http://www.programmersheaven.com/zone5/cat188/ [3] http://www.programmersheaven.com/zone5/cat188/26391.htm [4] http://www.programmersheaven.com/zone5/cat188/2025.htm [5] http://www.winehq.org/hypermail/wine-patches/2004/08/0043.html

Aug. 4, 2004

Re: Wine and locales

by David Lee Lambert

On Wed, Aug 04, 2004 at 11:20:57AM +0300, Shachar Shemesh wrote: > David Lee Lambert wrote: > >On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote: > >>"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > >>I don't see how the settings would be different, surely LC_CTYPE is > >>always going to control the ASCII->Unicode mapping on Unix, so why > >>shouldn't it do that on Wine? If the issue is that users change their > >>setup without understanding the results, then surely adding even more > >>config parameters that they need to get right is not going to improve > >>the situation. > > > >1. ANSI->Unicode translation for programs that use the ANSI calls, as > >has been discussed in this thread. > > > Ok. > > >2. Unicode->codepage translation on standard output, and > >codepage->Unicode translation on standard input. ... > > > Why should we set it differently than 1? (1) is when a program talks to what it thinks is a version of Windows according to the author's understanding of a the codepage. (2) and (3) are how are how Wine talks to the rest of the system. What codepage should be used under a utf8 locale, such as most of the setups on Redhat WS 9? There are no Windows programs that actually pass utf8 data to the Xxxx*A calls; if a program wants to use Unicode, it will use the wide character APIs. (MS Word, PAF 5, IE 6...) (I know I said UTF16 before. I haven't actually tried a UTF16-only setup, and UTF16 is not compatible with the C library because it uses \0 in normal text, etc.) > Name one such filesystem, please. EXT and reiser never cared, as far as > I know. VFAT has to translate names stored in UTF-16. Are you saying the > kernels<2.4 didn't have the "iocharset" option? I have some files stored on a Windows ME box with names containing accented characters, which show up fine in Explorer and the MS-DOS prompt on that system and on other WinME systems accross the network. In Linux the filenames appear to be encoded in CP437 when I use 'smbmount' whith no options. The manpage says that iocharset= (Linux side) and codepage= (Server side) are only supported in kernel 2.4 and above. However, on my system that runs kernel 2.4.x, the problem persists even when I pass options "iocharset=utf8,codepage=cp437" I get a message about CP437 not being supported, even though I have a kernel module cp437.o . By the way, Explorer and command.com only allow me to enter directories with 8-bit-character-names on the local system. Under Linux, I can enter said directory using tab completion, even though the characters don't show up. > > This is all through > >GetLocaleInfo(), whose first argument is an LCID returned by either > >GetUserDefaultLocale or GetSystemDefaultLocale. > > > You can also pass "LOCALE_SYSTEM_DEFAULT" instead, but that doesn't > matter. In any case, there are "user overrides" here, which we may, one > day, want to implement. Everything is laid out in the table that started > this thread. > > >5. The MultiByteToWideChar() and WideCharToMultiByte() functions, which > What do we need to do with these? They get an explicit codepage to > convert to/from. Funny though it may sound, these functions are not > affected by locale. Right. > I don't agree. Mixing default codepages across simultaneously running > programs is not possible on Windows, and sounds horribly difficult to > implement. Clipboard handling and cross-file using are two examples of > things that are likely to go horribly wrong if we tried. If a program does a an ANSI call, it gets changed to Unicode. If that data gets passed back to another program using an ANSI call, it gets converted to the target codepage, as much as possible. If Wine is doing console output to a non-Unicode codepage, it gets converted there too. I'm not sure about mixing codepages under Windows, but input-method switching is easy. > Having one setting applicable to all running processes sounds good > enough. I don't object to a config setting overriding what LC_CTYPE > says, but I don't see a use for it either. Let's say I want to run an Arabic dictionary program and Spanish dictionary program as I'm typing a report in Word. Furthermore, the arabic dictionary program would use ANSI calls and expects to run on Arabic windows (with MS-ARAB encoding); the Spanish program would use LATIN1. Word uses wide-character calls. How would I run all these programs at the same time under Wine? (I'm not saying I actually have such a set of programs. Actually, I own a copy of a standalone program that allows typing of Arabic programs on Western windows, and also have access to systems where Office XP with the Arabic and US-International input methods is installed.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 4, 2004

winedos: TSR (was MCB implementation)

by markus.amsler＠oribi.org

Hi, Quoting Steven Edwards <steven_ed4153(a)yahoo.com>: > Do you have to run FreeCOM? You could run ReactOS cmd.exe. Its based on > FreeCOM but works on Wine already. Perhaps. The main goal isn't running FreeCOM, my goal is TSR (Terminate and Stay Resident) support. I thought, the easiest way to get TSR working, is to start a DOS shell (not a win32 shell), and from there start the TSR programm. After receiving the TSR interrupt, you just haven't to free memory and interrupts, and it stays resident in the DOS Memory.(windows cmd.exe spawns also command.com if you run a TSR programm). So I need a DOS shell. First I tried Windows command.com, without success, it makes heavy use of the BIOS Rom (and is propriatary too). With FreeCOM I had more luck, some TSR's are working more or less. Now, what should happen, if you start a TSR programm in a win32 shell (like wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR somehow in win32 (shell or ntdll) or no TSR support in win32 shells? Any other ideas? Markus

Aug. 4, 2004

Re: dosmem: MCB implementation

by Steven Edwards

Hi, --- markus.amsler(a)oribi.org wrote: > I'm trying to run freecom[1] of the freedos project in wineconsole. > After changing comspec in user.reg and some ugly hacks to > kernel/dosmem.c it > runs (dosmem_paragraph.patch). But it will never run cleanly without > proper MCB > support (it does its own MCB-chain walking, like a lot of other > programms). Do you have to run FreeCOM? You could run ReactOS cmd.exe. Its based on FreeCOM but works on Wine already. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 4, 2004

rsabase and itunes

by Michael Jung

Rob, I've seen the press release concerning the CrossOver Office iTunes preview and I've noticed that it depends on libcrypto. Im just wondering if your effort with rsabase is related to this? Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

Aug. 4, 2004