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

Re: RegEdit problems

by Dimitrie O. Paun

On Thu, 29 Apr 2004, Krzysztof Foltman wrote: > Is anybody working on it, or should I try it ? Using native regedit is > not an option, as our goal is to avoid being a BSA victim completely. I was working on it a bit, but I got sidetracked. I have a patch in the tree for a while now, but I haven't had time to clean it up and submit. The code needs a lot of cleanups, so feel free to hack on it and fix whatever problem bothers you, I'll continue my stuff after you finish. -- Dimi.

April 29, 2004

Re: Re: CVS Invalid path for c:\\Windows

by brettholcomb＠charter.net

Arrghh! I'll do that. Thank you. Can the message be updated to tell us to look at the dosdevices directory. > > From: Alexandre Julliard <julliard(a)winehq.org> > Date: 2004/04/29 Thu AM 02:02:21 GMT > To: "Brett I. Holcomb" <brettholcomb(a)charter.net> > CC: wine-devel(a)winehq.com > Subject: Re: CVS Invalid path for c:\\Windows > > "Brett I. Holcomb" <brettholcomb(a)charter.net> writes: > > > Yes. I just did again and it doesn't work. Same error. Something got > > broken again I guess. > > Path entries from the config file are no longer used. Check the > contents of your ~/.wine/dosdevices directory. > > -- > Alexandre Julliard > julliard(a)winehq.org >

April 29, 2004

Re: Conversion between Clipboard Formats

by Dmitry Timoshkov

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > Does WINE support automatic type conversion between certain kinds of > clipboard formats? For e.g. between CF_TEXT and > CF_UNICODETEXT and similar types of conversions? Yes, it does. However support not for all synthesized formats has been implemented at the moment, and some recent clipboard changes have broken some clipboard functionality, so the clipboard test I wrote for crossover doesn't pass anymore on current Wine CVS. I'll try to fix the failures and send the patch to wine-patches at some point. See dlls/x11drv/clipboard.c,X11DRV_CLIPBOARD_RenderSynthesizedFormat() for details. -- Dmitry.

April 29, 2004

Re: Ukrainian translation

by Dmitry Timoshkov

"Ylia K" <k_ilya(a)ukr.net> wrote: > I could not find any data or program in Wine src to generate it. > Abreviated month in ukr.nls differed from locale's one. > How are *.nls generated? Actually it doesn't matter how they were generated. Have a look at this patch, changelog says it all: ChangeSet ID: 1029448819517089905756624 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 02/08/15 17:00:22 Modified files: dlls/kernel : locale_rc.rc dlls/kernel/nls: afk.nls ara.nls arb.nls are.nls arg.nls ari.nls ark.nls arm.nls aro.nls arq.nls ars.nls art.nls aru.nls bel.nls bgr.nls brf.nls cat.nls cht.nls cor.nls cym.nls dan.nls dea.nls dec.nls del.nls des.nls deu.nls ena.nls enb.nls enc.nls eng.nls eni.nls enj.nls enl.nls ens.nls ent.nls enu.nls enz.nls esa.nls esb.nls esc.nls esd.nls ese.nls esf.nls esg.nls esh.nls esi.nls esl.nls esm.nls esn.nls eso.nls esp.nls esr.nls ess.nls esu.nls esv.nls esy.nls esz.nls euq.nls fin.nls fos.nls fra.nls frb.nls frc.nls frl.nls frs.nls gae.nls gdh.nls gdv.nls heb.nls hrv.nls hun.nls ind.nls isl.nls ita.nls its.nls jpn.nls kor.nls lth.nls lvi.nls msl.nls nlb.nls nld.nls nls.nls non.nls nor.nls plk.nls ptb.nls ptg.nls rom.nls rus.nls sky.nls slv.nls sqi.nls srb.nls srl.nls sve.nls svf.nls tha.nls trk.nls ukr.nls wal.nls zhh.nls zhi.nls Added files: dlls/kernel/nls: arh.nls arj.nls arl.nls ary.nls aze.nls azl.nls chs.nls csy.nls div.nls ell.nls enp.nls enw.nls eox.nls eti.nls far.nls frm.nls glc.nls guj.nls hin.nls hye.nls kan.nls kat.nls kkz.nls knk.nls kyr.nls mar.nls mki.nls mon.nls msb.nls pan.nls san.nls swk.nls syr.nls tam.nls tel.nls ttt.nls urd.nls uzb.nls uzl.nls vit.nls zhm.nls Removed files: dlls/kernel/nls: README cze.nls esperanto.nls est.nls grc.nls koj.nls vie.nls zhs.nls Log message: Updated all locale tables to match exactly what Windows returns. Renamed a few files to follow the proper naming conventions. Added a number of new locales. Patch: http://cvs.winehq.com/patch.py?id=1029448819517089905756624 -- Dmitry.

April 29, 2004

Re: RegEdit problems

by Mike Hearn

On Thu, 29 Apr 2004 07:18:07 +0200, Krzysztof Foltman wrote: > Is anybody working on it, or should I try it ? Using native regedit is > not an option, as our goal is to avoid being a BSA victim completely. There were people working on it a few months ago, but that seems to have slackened off lately. Go for it. If you're intending to do several patches for it you may wish to investigate arch. It'll let you branch WineHQ, commit your work as you complete it, and submit to wine-patches via a handy script. It'll let you keep your patches clean and separate from each other. </commercial> thanks -mike

April 29, 2004

Conversion between Clipboard Formats

by Santosh Siddheshwar

Hi, Does WINE support automatic type conversion between certain kinds of clipboard formats? For e.g. between CF_TEXT and CF_UNICODETEXT and similar types of conversions? Any inputs would be appreciated 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. *********************************************************************

April 29, 2004

Re[2]: Ukrainian translation

by Ylia K

-----Original Message----- From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Ylia K" <k_ilya(a)ukr.net> Date: Mon, 26 Apr 2004 23:52:14 +0900 Subject: Re: Ukrainian translation > "Ylia K" <k_ilya(a)ukr.net> wrote: > > > * dlls/kernel/nls/ukr.nls, dlls/comctl32/rsrc.rc, dlls/commdlg/rsrc.rc, dlls/user/resources/user32.rc, dlls/shell32/shres.rc, > > dlls/comctl32/comctl_Uk.rc, dlls/commdlg/cdlg_Uk.rc, dlls/shell32/shell32_Uk.rc, dlls/user/resources/user32_Uk.rc : > > > > Ilya Korniyko <k_ilya(a)ukr.net> > > > > Ukrainian translation: full translation of comclt32, commdlg, shel32, user dlls, fixes in ukr.nls > > You shouldn't touch ukr.nls since it has been auto generated. > > -- > Dmitry. > I could not find any data or program in Wine src to generate it. Abreviated month in ukr.nls differed from locale's one. How are *.nls generated? ---------------- Best Regards, Ilya Korniyko ----- Получите бесплатный почтовый ящик на http://www.freemail.ukr.net

April 29, 2004

Re: d3d8 CVS doesn't compile

by Lionel Ulmer

> There should only be three headers. In mingw w32api they ship > glext.h,gl.h and glu.h in a GL subdirectory. Is anything else needed > for Wine? Well, in the X11 world, there are also glx.h and glxext.h (the latter needed if we want to use GLX extensions). Lionel -- Lionel Ulmer - http://www.bbrox.org/

April 29, 2004

Re: RFH: winetest testing

by Ferenc Wagner

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: >> The output redirection didn't work from a GUI app: the libc >> streams weren't initialized and thus the output disappeared. >> Wouldn't DETACHED_PROCESS result the same? It's not crucial >> for winetest itself, but making it a console app helped >> debugging tremendously. > > I think the stream (handle) point of view worked, but > somehow msvcrt doesn't initialize stdin/err/out when the > app is in GUI mode. Pretty much so. The output simply didn't appear, even if the GUI app was started from a console. No errors here. > It may work if the app would close 0,1,2 and reopen them > on standard handles Do you mean StdHandles a la Windows? I'm not sure a GUI app has them. Even if it had, there's no way to convert them into libc handles or streams AFAIK. >> In short, I've got the impression that things are working >> out now (by using some black magic -- ie. winetest being a >> CUI -- which I don't understand), so maybe we could simply >> leave it for now. Or do I miss serious issues? > > the only point is that we don't have a consistent basis > across platforms were we start the tests from: > - all tests programs are CUI exec > - but, we don't know if it's attached to a console or not A CLI program is attached to a console unless created with fancy flags, isn't it? Presently I only ask for the window to be hidden, nothing else. > - if attached to a console, we don't know whether other > processes are outputting to the same console (which could > impact the tests...) I never thought of this. If this really can be a problem, we must solve it, thanks for bringing it up. However I seem to recall that the console test pops up a separate console, so maybe isn't affected after all. Other test shouldn't care... But I will soon look into this (may take a couple of days, though). -- Feri.

April 29, 2004

Re: SetCalendarInfoA and SetCalendarInfoW implementations

by Stefan Leichter

Am Mittwoch, 28. April 2004 22:38 schrieb Wililam: > I have implemented the SetCalendarInfoA and SetCalendarInfoW API > functions in dlls/kernel/time.c. I am aware that you generally do not like > it when more than 1 thing is changed, but SetCalendarInfoA is not much more > than a > call to SetCalendarInfoW. I am also curious as to why both functions were > listed > as stdcalls rather than stubs when they were both stubs in the source file. > > I have enclosed the patch for the file against the latest source package. > > Here is the ChangeLog entry (I didn't patch the ChangeLog file): > > * dlls/kernel/time.c > William Lahti <computerman413(a)ezrs.com> > > - Implemented the SetCalendarInfoA and SetCalendarInfoW APIs. > > Sincerely yours, > > William Lahti Hello, for my limited understanding you need to convert lpCalData from ascii to unixode in SetCalendarInfoA before calling SetCalendarInfoW Bye Stefan

April 29, 2004