- Wine-Devel - list.winehq.org

Regression in x11drv windows handling
by Maxime Bellengé Feb. 6, 2005

Feb. 6, 2005

I have one of my applications which no longer works correctly after this patch : ChangeSet ID: 15758 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 2005/01/28 11:25:50 Modified files: include : win.h dlls/x11drv : x11drv.h winpos.c window.c event.c desktop.c Log message: Use an X context to associated the x11drv private window data to a window handle instead of accessing the WND structure directly. Patch: http://cvs.winehq.org/patch.py?id=15758 The behavior is when I try to move a window (in unmanaged mode) a little, the window moves at the bottom right corner of my screen. If I try to move it again, it moves again further on the bottom right. So I can no longer see my window. However every component in that windows works perfectly. Maxime

1 0

Re: appdb/ ./appview.php ./screenshots.php admin/a ...
by Jonathan Ernst Feb. 5, 2005

Feb. 5, 2005

Le vendredi 04 février 2005 à 08:25 -0700, tony_lambregts(a)telusplanet.net a écrit : > WineHQ wrote: > > ChangeSet ID: 15925 > > CVSROOT: /opt/cvs-commit > > Module name: appdb > > Changes by: wineowner(a)wine.codeweavers.com 2005/02/03 20:55:50 > > > > Modified files: > > . : appview.php screenshots.php > > admin : adminAppDataQueue.php editAppFamily.php > > editAppVersion.php > > include : screenshot.php user.php > > tables : appdb_tables.sql > > > > Log message: > > Jonathan Ernst <Jonathan(a)ernstfamily.ch> > > - no more appId in appData as appVersion implies an appId* > > - screenshot class has been reworked to remove need of appId > > - screenshot class has been improved to send e-mails so that email handling can be removed from other scripts > > > > Patch: http://cvs.winehq.org/patch.py?id=15925 > > > > Old revision New revision Changes Path > > 1.47 1.48 +7 -18 appdb/appview.php > > 1.25 1.26 +30 -91 appdb/screenshots.php > > 1.10 1.11 +80 -107 appdb/admin/adminAppDataQueue.php > > 1.25 1.26 +0 -131 appdb/admin/editAppFamily.php > > 1.20 1.21 +3 -10 appdb/admin/editAppVersion.php > > 1.8 1.9 +237 -46 appdb/include/screenshot.php > > 1.34 1.35 +38 -17 appdb/include/user.php > > 1.18 1.19 +0 -2 appdb/tables/appdb_tables.sql > > > > > > > Bah! How are extra links in the appfamily suposed to work? Of course you seem to > think that these are not important so you simply removed them from edit > appfamily &%@#!. This is wrong ! > > -- > > Tony Lambregts > Hi Tony, Did you read the explanation of the * near the first changelog entry ? ------------------------------------------------------------ * => application have no additional url but version have application description is now just describing an application and giving a link to the application web page. Version description can now have many urls to various interesting resources ------------------------------------------------------------ As I guess you did, here are some more explanations (you can read some in the IRC log if you have some): APPLICATIONS ------------ *ELEMENTS STILL LINKED TO APPLICATIONS AFTER THESE PATCHES* - Description: General (not wine specific) description about the application. More or less what you can find on the editor site. (You might want to put a link to alternate native applications on linux here or to codeweaver's website at the end of the description as only the first line of the description is kept on summaries like search results, top-ten applications, etc.) - Webpage: webpage for the application *ELEMENTS THAT WERE LINKED TO APPLICATIONS BEFORE THESE PATCHES* - URLs: Used to link to wine-specific material or version specific material. As it is not of general use for an application it should be deleted to avoid url duplication in APPLICATIONS and VERSIONS (we should also avoid that people put things like "I tested it with wine xyz and it worked" in the APPLICATION description as it is version specific as well.) VERSIONS -------- *ELEMENTS STILL LINKED TO VERSIONS AFTER THESE PATCHES* - Description: Describe this version of this application, don't duplicate the description that belongs to the application (it is still the case in many version entry). - Screenshots: version specific screenshot *ELEMENTS THAT WERE LINKED TO VERSIONS BEFORE THESE PATCHES* - Webpage: webpage should be removed as hardly no editor keeps a different page for each version of it's software (I'm not speaking about version-specific support, service packs, etc. which can be covered using the added URLs entries discussed below). *NEW ELEMENTS THAT ARE LINKED TO VERSIONS AFTER THESE PATCHES* - URLs: using URLs you can give version-specific or wine specific links for the given version of an application. Another reason to don't keep the link from URLs to Application is that they are stored in the same table as screenshots and screenshots are not linked to applications so that if we want to keep URLs for applications we should make two tables. Of course this is just what I _think_ (I don't *seem to think* anything and discussed everything on IRC, put it in the patch description and of course the patches I send are only proposals, etc.). Finally nothing is *supposed to work* here as I: - took a great care at cleaning up the forms to remove the thing that are not available anymore using the new table schema - took a great care at testing every single function of the appdb to find regressions - made these changes willingly and documented those as well I'm looking forward to reading your (and anybody else's) comments about these thoughts and if you found regressions that'd slip through, don't hesitate to send me a bug report, I'll fix them asap. Best regards, Jonathan

3 4

[d3dxof] Registering this dll
by Paul Vriens Feb. 5, 2005

Feb. 5, 2005

Hi, any particular reason why d3dxof shouldn't be able to register (itself): @ stdcall -private DllRegisterServer() D3DXOF_DllRegisterServer @ stdcall -private DllUnregisterServer() D3DXOF_DllUnregisterServer is missing from the spec file. I was just playing with dxdiag. Cheers, Paul.

2 2

Re: ntdll / kernel32: #52
by Alexandre Julliard Feb. 5, 2005

Feb. 5, 2005

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > +/****************************************************************** > + * NtAddAtom (NTDLL.@) > + */ > +NTSTATUS WINAPI NtAddAtom( const WCHAR* name, ULONG length, ATOM* atom ) > +{ > + WCHAR full_name[MAX_ATOM_LEN + 1]; > + > + if (length / sizeof(WCHAR) > MAX_ATOM_LEN) return STATUS_INVALID_PARAMETER; > + memcpy(full_name, name, length); > + full_name[length / sizeof(WCHAR)] = 0; > + return RtlAddAtomToAtomTable( get_global_table(), full_name, atom ); That will work, but it's really ugly to copy the string just so we can do a strlenW on it and convert it back to a counted string for the server call. I think you really want the Nt* functions to make direct server calls, and the Rtl* to manipulate a local table. If we don't do things the way NT does we can just as well keep the current implementation. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Wine legalities
by Ira Krakow Feb. 4, 2005

Feb. 4, 2005

Jeremy, I agree - this is an exciting development. Microsoft's ability to spread FUD and their legal budget are enormous. We need this kind of expert help. Here's an area where I'd like an expert opinion. In the Winelib part of the Wine book, I'd like to include an example of converting a Microsoft VC++ 6.0 MFC application. This is Winelib's primary target, in my opinion. My question is: how far can I go? There are proprietary Microsoft header files that need to be included - does the Microsoft EULA allow disclosure of what these header files are? Or is it only legally safe to say something generic like "....figure out for yourself which header files you need to #include..."? In general, I think Microsoft has to tread lightly on the issue of running Microsoft apps in Linux. Certainly, they're within their rights to hang up if a Linux/Winword user calls the help desk. But going after a company who legally pays for Winword licenses and runs Winword in Linux/Wine is another matter, bringing up the antitrust bogeyman again. Getting an expert legal opinion on this would be very useful. IMHO, even if Microsoft was legally on solid footing, it would be a huge PR disaster for them. Eventually, these issues will come to a head. Ira

6 6

RE: Wine legalities
by PETREOLLE Sylvain Feb. 4, 2005

Feb. 4, 2005

Hi Steven, Couldnt we put a link to it on ReactOS homepage, saying its only a draft atm ? Cordialement, Usurp(aka Sylvain PETREOLLE) -----Message d'origine----- De : Steven Edwards [mailto:steven_ed4153(a)yahoo.com] Envoyé : mercredi 2 février 2005 07:16 À : Ira Krakow; jwhite(a)codeweavers.com; ros-general(a)reactos.com Cc : wine-devel(a)winehq.org Objet : Re: Wine legalities Hi Jer, The ReactOS Project consulted a IP lawyer and came up with a draft policy statement. Maybe the two projects could work together on this. http://reactos.com:8080/archives/public/ros-general/2005-January/001402.html Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

1 0

unable to compile on x86_64 platform
by Noah Schwartz Feb. 4, 2005

Feb. 4, 2005

hey, i'm trying to compile wine on my machine (ver. 2005-01-11) but ./configure doesnt get too far... error: checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. here's the relevant info from config.log: configure:1878: checking for C compiler default output file name configure:1881: gcc -m32 conftest.c >&5 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/./libgcc.a when searching for -lgcc /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/libgcc.a when searching for -lgcc /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status configure:1884: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "20050111" | #define PACKAGE_STRING "Wine 20050111" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:1923: error: C compiler cannot create executables See `config.log' for more details. currently running gentoo. kernel version 2.6.9-gentoo-r14. glibc version 2.3.4.2004-11-02. gcc version 3.4.3-r1 compiled with multilib which works as far as i know

2 1

Theme Hospital & Dungeon Keeper Mouse
by Carlos Lozano Feb. 4, 2005

Feb. 4, 2005

Hello, I have updated the patch what does work Theme Hospital, and Dungeon Keeper games, to actual CVS. It is only for testing purposes. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

1 0

my first go at syncing opengl spec
by Tom Feb. 4, 2005

Feb. 4, 2005

This is my first attempt at syncing the opengl spec. Is this close to what needs to be done? Tom

2 1

Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem
by Ann and Jason Edmeades Feb. 4, 2005

Feb. 4, 2005

Well yes and no. The 'problem' is most of this code isn't implemented yet... Try Olivers large patch and see if things are any better, or wait a while while a whole load of code gets into cvs. Basically d3d9 shouldn't have any of the code relating to the stencil buffers - that will be in wine3d. I am pretty certain Olivers patch did that, and he is working on splitting it up to get cvs in sync with his local tree. Jason

6 13