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

Re: Menu Item problem(was Notepad not remaining language selection)

by Francois Gouget

On Tue, 26 Feb 2002, Sylvain Petreolle wrote: > Hi, > > I have implemented 2 procedures to set the > language used by Notepad at startup. > > Now it selects language by using string key "Language" > under HKCU\\Software\\Wine\\Notepad. > > Restore of the language functions now. > But I'm new in Windows coding so I don't know which > procedure is called when I click on an item in the > Language menu.So saving the language in the registry > is not called.The procedure is ready to use but never > called. Actually, does thi skind of functionality belong in Notepad? Doesn't Wine have some notion of the current language used by the user? Maybe even inherited from LANG? Why should notepad have its own notion of which language the user is using? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Feb. 26, 2002

Menu Item problem(was Notepad not remaining language selection)

by Sylvain Petreolle

Hi, I have implemented 2 procedures to set the language used by Notepad at startup. Now it selects language by using string key "Language" under HKCU\\Software\\Wine\\Notepad. Restore of the language functions now. But I'm new in Windows coding so I don't know which procedure is called when I click on an item in the Language menu.So saving the language in the registry is not called.The procedure is ready to use but never called. Could someone help ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Feb. 26, 2002

Re: About that eeevil library naming decision...

by David Elliott

On 2002.02.25 15:05 Andreas Mohr wrote: > On Mon, Feb 25, 2002 at 11:47:31AM -0800, Alexandre Julliard wrote: > > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > > > > > Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the > > > naming scheme. That'd be pretty reasonable and cleaner/better than > > > the current approach IMHO, as it'd clearly separate core/dll > functionality > > > in a good way. > > > > The separation will be done by putting dlls in a separate directory > > (usually /usr/lib/wine) which is a lot cleaner than creating 150 files > > in /usr/lib, no matter how they are named. > > But some people DON'T separate it. > (for various reasons, which might only be evident in the future) > > Furthermore, having tons of hopelessly chaotically named libraries > is everything but clean. > Andi... if Wine DLLs eventually go into a /usr/lib/wine then you cannot possibly argue that anybody in their right mind would put them in /usr/lib. I don't see any distributors putting the libraries in /usr/lib/xmms/* into /usr/lib, do you? > > Wine dll path won't be added to /etc/ld.so.conf. But in any case the > > plan is that dlls in /usr/lib/wine are named without the lib prefix to > > make it clear you can't link to them. > Fact is that a LOT of people/distributors still add it to ld.so.conf. > We are not talking about libraries that people would want to link to in the normal UNIX sense. We are basically talking about what amounts to "plugins" for the wine emulator (in some sense). Therefore when wine is able to load the DLLs from a specific wine library directory then nobody is going to install them into /usr/lib, if they do then that is their own damn problem for being stupid. > Anyway, I didn't know about the "omit lib" plan yet. > That'd actually be a rather usable choice, since that'd really eliminate > the conflicts. > > But are you sure that you can just omit the lib prefix on *all* supported > environments ? > Does it really matter? If they are in a seperate plugins type directory then who cares if the "lib" is ommitted or not. -Dave

Feb. 26, 2002

Re: DTR Flow Control

by Mike McCormack

Original message from: lawson_whitney(a)juno.com > >On Mon, 25 Feb 2002, Michael Cardenas wrote: > >> Attached is the output of +relay,+file,+comm. .. >May we see a > >wine --version, please? Michael, How about showing us the source you are using, so we can help you debug it? thanks in advance ;-) Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Feb. 26, 2002

Re: Bootprocedure again

by lawson_whitney＠juno.com

On Mon, 25 Feb 2002, David Elliott wrote: > Err, by "the code to do this" I was still referring to the code that does > the bootup procedure. And I don't believe that it should be linked to the > emulator. It can and will have to be linked to winelib (thus making it a > winelib program) but it should definitely not be linked in with the > emulator portion of wine. The emulator may use a CreateProcess to call it > during startup, but I would prefer a shell script. In case you haven't been watching lately, a winelib program is not any more an elf executable. It is an elf-format PE executable, and AFAIK, it is meant to be run by the emulator. WINEPRELOAD makes it easy to run one from a script, or another *NIX executable. Right, though, it isn't linked to the emulator, I sort of misspoke there. > Yeah.. I think that this is a reasonable solution and we let the > distributors figure it out from there. > > -Dave > Lawson This letter is brought to you by /usr/local/bin/toj2, which pine runs in lieu of sendmail: #! /bin/sh WINE=/usr/local/bin/wine [[ "$(dirname $0)" == "." ]] && wpl="${PWD}/toj2.so" || wpl="${0}.so" WINEPRELOAD="$wpl" $WINE ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

Feb. 26, 2002

Re: DTR Flow Control

by David Elliott

On 2002.02.25 16:38 lawson_whitney(a)juno.com wrote: > On Mon, 25 Feb 2002, Michael Cardenas wrote: > > > > > Attached is the relevant part of the output of +file,+comm. > > > > It looks like the app is using ClearCommError to check for the number > of > > bytes recieved. I've read that the TIOCOUTQ ioctl is buggy and not very > > reliable, but I'm not sure if that's been fixed or not in newer > kernels. > > > My comms apps have been banging on ClearCommError for that since August > 1997, but without the overlapped nonsense. It works for me or I > wouldn't have gotten your letter. This app appears to ask for > rts/cts flow control - at least that is what we give it. Dumb > question: is there a modem cable or null-modem cable involved? If so, > is it a good one, with wires for each signal (properly crossed for a > null-modem cable), or is it a 3 wire Windows cable? Wine actually does > use (cause the serial driver to use) rts/cts flow control if the app > asks for it, and it won't work on a 3 wire cable. I don't believe > Windows actually does hardware flow control at all, no matter what the > app asks for. > Hmm.. I am pretty sure that Windows 9x and NT do use RTS/CTS flow control. The standard win3.11 drivers don't IIRC, but 95 and above and NT always do if you have the hardware flow control radio box checked in the properties for the modem (and the app doesn't override it itself). [SNIP] One thing I would like to mention is that I think almost all Gateway 2000 486 computers have an incorrectly wired 25-pin serial port. DTR is not on the correct pin on the 25-pin D connector but is on the correct pin on the 10pin connector that is on the motherboard (which to my knowledge is the same for almost every motherboard that uses this type of serial connection). If you upgraded the motherboard in one of these old cases and did not use the new serial ports that came with the new mobo this may cause you some trouble. Fortunately my USR v.Everything has a DIP switch setting to turn off DTR control. The downside is that with DTR turned off you cannot just drop DTR to hang up but must instead use +++ATH. Fortunately I got rid of that 486 board many computers ago. (Un)fortunately I no longer use the v.Everything modem for much since I have a cable modem. It's almost a shame too, it's a really nice modem, connects with everything under the sun. -Dave

Feb. 26, 2002

Re: Bootprocedure again

by David Elliott

First of all, it'd be nice if you used "Reply All" so I wouldn't have to comb through the list to respond.. but no biggie really. On 2002.02.24 09:03 Gerhard W. Gruber wrote: > David Elliott wrote: > > > To really follow the UNIX philosophy you want to put it in a seperate > > application. Save yourself a lot of trouble trying to figure out where > to > > place a hook in wine and simply write it into a completely seperate > > program. You can then have wine actually run that program with a > > CreateProcess call or similar at whatever point. The code to do this > > should NOT be in the wine emulators source code itself, nor do I > believe > > it should be linked in with it. > > But one argument was that it would be to performance intensive. Creating > a seperate process is much more intensive then checking for a single > registry key. > First and foremost should be good design. Good design means you don't do anything in the wine emulator startup except get the emulator running. Eventually I think Alexandre wants to remove all of the code that is run in the address space of the first loaded process somewhere more appropriate. Adding code here is probably the last thing he wants someone to do. > > Windows itself (win9x/me at least) actually has this code in > WININIT.EXE > > which is loaded early on in the boot process. It is not necessary or > even > > But this has to be loaded every time. Or at least there must be some > check done every time in order to determine wether it should be run. Do > you know how Windows handles this? > Well, WININIT does other stuff I believe like actually setup the GDI/USER structures. I may not be correct about that though. For the most part though, WININIT is something that is started when windows is booted. I think eventually we want to have a similar thing and this is where Andi's wineboot is going. I could be wrong though as I am not Andi. It would be highly appropriate to process these files in the wineboot program. I also think it would be desirable to have a way to process the files while wine is still running so a quick'n'dirty solution to that problem is something like a "--processfilesonly" switch to the wineboot program. A better solution would be to simply check if wine has already been booted and if it has then only do stuff which would make sense to do while wine is already booted up (like process the rename files list). > > desirable to have the code in the emulator itself. It is much more > > desirable to have it be a completely seperate program. Leave it to the > > distributors of Wine to implement the actual policy and only provide > the > > mechanism. This is what Alexandre has been saying, and I am saying the > > same thing. Policy decisions do not belong in Wine, even as > configuration > > options when it can be helped. If you feel you absolutely MUST have > this > > run every time a wine program is started or every time a wine program > > finishes (maybe this would be better) then write a shellscript like so: > > > > #!/bin/sh > > wine "$@" > > wine_movefiles > > > > This is so simple, why would you even waste your time trying to hack it > > into the boot code for wine? > > My prefered way of doing this, independently of having it as a seperate > program or included in wine, is to find a way to start it exactly when > it is needed. I hate to run it everytime when wine starts/ends or in a > batchscript or such. The ideal solution would be to start it when it is > really needed. > I think you are much too concerned with performance and not concerned enough with good design. Actually, my script was a little off as if no other background wine processes are running it will stop the wineserver after the first program finishes and then start it up again to run wine_movefiles. You'll notice that if you run wineserver -p and then start up some program and quit it to get the bootup code executed that every wine program you run after that will actually start pretty quickly. The important thing is to get the code implemented in something like wineboot. Leave it to the distributors/users to decide how this gets executed. On your system you may want the file processing code to run directly after you have run a program. In this case you simply use something like the shell script above or you put in a CreateProcess call somewhere in the process exit code for wine. If you feel that you must you can only run the program after checking to see if the registry keys exist. However, I think you will notice that running a small program is not going to take more than a second or two and since you'd be running that on process exit as opposed to startup you'd probably never even notice it. Anyway, on a personal note, don't get disheartened that the wine developers don't like you. Believe me, EVERYBODY who has contributed code to Wine has had some code or some ideas frowned upon. Just think about it and you'll eventually realize that most of the time Alexandre is dead-on so unless you can prove that the way he, most of the other developers, and I have been suggesting to do this is just dead-ass wrong then I would suggest not fighting it. -Dave

Feb. 26, 2002

Re: Bootprocedure again

by David Elliott

On 2002.02.23 23:49 lawson_whitney(a)juno.com wrote: > On Sat, 23 Feb 2002, David Elliott wrote: > > > application. Save yourself a lot of trouble trying to figure out where > to > > place a hook in wine and simply write it into a completely seperate > > program. You can then have wine actually run that program with a > > CreateProcess call or similar at whatever point. The code to do this > > should NOT be in the wine emulators source code itself, nor do I > believe > > it should be linked in with it. > > Well, if it is a Winelib program, it would be linked with it, sort of, > and loaded by it, but I think that is not what you mean here, is it? Err, by "the code to do this" I was still referring to the code that does the bootup procedure. And I don't believe that it should be linked to the emulator. It can and will have to be linked to winelib (thus making it a winelib program) but it should definitely not be linked in with the emulator portion of wine. The emulator may use a CreateProcess to call it during startup, but I would prefer a shell script. [SNIP] > > distributors of Wine to implement the actual policy and only provide > the > > mechanism. This is what Alexandre has been saying, and I am saying the > > same thing. Policy decisions do not belong in Wine, even as > configuration > > options when it can be helped. If you feel you absolutely MUST have > this > > run every time a wine program is started or every time a wine program > > finishes (maybe this would be better) then write a shellscript like so: > > > > #!/bin/sh > > wine "$@" > > wine_movefiles > > > > This is so simple, why would you even waste your time trying to hack it > > into the boot code for wine? > > > > -Dave > > > Right. I like that. > Yeah.. I think that this is a reasonable solution and we let the distributors figure it out from there. -Dave

Feb. 26, 2002

Re: Artilcle - loading Windows DLL's under Linux

by Jakob Eriksson

On Mon, Feb 25, 2002 at 02:25:18PM -0700, Brett Glass wrote: > At 03:41 PM 2/25/2002, Nick Temple wrote: [snip] > >The code has been "borrowed" and tweaked from the avifile distribution (which is GPL'd), originally borrowed from WINE (BSD license), and will be re-released under the GPL or LGPL once the article is published. > > It is not legal to do this. You can't change the license on existing code. > If it was originally licensed under the WINE X11 license, you cannot legally > change that. Which is a good thing. No one should be allowed to stamp a > virulent license on someone else's work without permission. You are technically right. You can't change the license notice on for instance X11 style licensed code. But you can combine X11 licensed code with other, GPL-ed code and then the program as a whole must de distributed under GPL. regards, Jakob

Feb. 26, 2002

RE: Artilcle - loading Windows DLL's under Linux

by Steven Edwards

I'm not one to feed the trolls but hey what the hell....... >It is not legal to do this. You can't change the license on existing code. >If it was originally licensed under the WINE X11 license, you cannot >legally change that. Which is a good thing. No one should be allowed to >stamp a virulent license on someone else's work without permission. You Sir are a DumbA$$ and keep showing your A$$. If you would please go to http://www.gnu.org/licenses/license-list.html "The X11 license. This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. XFree86 uses the same license." Thanks and Have a Nice day Steven _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Feb. 25, 2002