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

winevdm changes break non-Linux platforms

by Gerald Pfeifer

I'm sorry to bother you, but the following change Moved the functionality of starting Win16 and DOS programs from the common process startup into a separate winevdm application. breaks non-Linux (actually "non-MZ" platforms as far as I can tell): /sw/test/wine/dlls/winedos% make /sw/gcc-3.2.2/bin/gcc -shared -Wl,-Bsymbolic,-z,defs winedos.spec.o devices.o dma.o dosaspi.o dosconf.o dosvm.o fpu.o himem.o int09.o int10.o int11.o int12.o int13.o int15.o int16.o int17.o int19.o int1a.o int20.o int21.o int25.o int26.o int29.o int2a.o int2f.o int31.o int33.o int41.o int4b.o int5c.o int67.o interrupts.o ioports.o module.o relay.o soundblaster.o vga.o xms.o winedos.dll.dbg.o -o winedos.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lm -lc winedos.spec.o: In function `__wine_spec_exports_funcs': winedos.spec.o(.data+0x40): undefined reference to `wine_load_dos_exe' winedos.spec.o: In function `__wine_spec_exp_ordinals': winedos.spec.o(.data+0xd8): undefined reference to `wine_load_dos_exe' winedos.spec.o(.data+0xd1): undefined reference to `wine_load_dos_exe' collect2: ld returned 1 exit status *** Error code 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 27, 2003 12:47 am, Francois Gouget wrote: > Only as far as commercial companies are concerned. Under the GPL > license, anyone can fork QT. And you think this is any way acceptable? I am sorry, but an OS that puts commercial development at such a tremendous disadvantage (that is, subject to the monopolistic whims of one company) is not a platform. So all the portability issues you listed don't even start to apply. > So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT > and instead develop using Win32+OLE+COM? No! Unfortunately, KDE/QT is in a difficult situation due to the licensing problem. It is the desktop of choice for most people, I use it, but I can't see what we can do about it. > I'm not criticizing, I'm trying > to clarify because in one of your previous email I had the impression > that you advocated development against a Win32-based Gtk API. Gtk is already ported to Win32. App wouldn't even know what Gdk backend is used, they would be just the same. > What about graphical applications? In the Windows world most > applications don't use Win32 directly for the GUI. Should we provide an > LGPL implementation of MFC? Implement a replacement for Visual Basic? A > binary compatible one? I am mainly referring to graphical apps. And no, commercial apps provide their own framework just like they do now. It'd be nice to have efforts toward a free MFC implementation, but it's besides the point. It's an orthogonal issue. > What API would open-source developpers use for WIDE applications? They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of free apps (see the top SF downloads for examples) that use the Win32 API, so it's not something new I'm suggesting? Do you think it's more moral/ethical to treat these apps as second class citizens in Linux? > Yes it would be very cool. I am far from being an expert on OLE/DCOM but > I have been told that it may be feasible. Probably a heck of a lot of > work though. I'm not saying it would be easy. But given that Bonobo was so deeply inspired by OLE, I'm hoping it can map easily onto an OLE backend, and maybe that leads to an easier path to integration. > But AFAICS what's needed is much smaller in scope from what you propose > with WIDE. Hm, it seems I have problems communicating. In fact, it seems to me we have most of the pieces for Wide already. > Other questions so I better understand: > * are you proposing source-level compatibility or binary level > compatibility? Both. We get both with Wine, we should be able to keep that. > * if it is source level, does it mean modifying gcc to support the > Visual C++ COM extensions? It would be nice to have gcc support for those, but this is independent of the Wide effort. Just like we have support for other stuff that was added through the MinGW project. > * how do you propose to handle the issue of drive letters? What we do in Wine is just fine. I'm only concerned with GUI apps, and there I see drive letters as just shorthands to a bunch of dirs. If you like that, go nuts. I see it as mainly a UI thing, other than that we'd try to pass Unix paths around as much as possible. -- Dimi.

April 27, 2003

Re: commctrl: fix indentation

by Dimitrie O. Paun

On April 27, 2003 12:50 am, Francois Gouget wrote: > I noticed the resulting file still uses a mixture of spaces and tabs for > alignment. Maybe some tabs escaped? Tabs really shouldn't be used unless > they are at the beginning of a line. I don't care about tabs vs. spaces. For me a tab is 8 spaces, and that's good enough. This patch is meant to align things so they look nice. If people feel spaces should be used instead of tabs, that's the subject of another patch. :) -- Dimi.

April 27, 2003

X11DRV_DIB_CreateDIBSection

by Robert Lunnon

Under Solaris I have a problem with this function.which appears to protect a section of the DIB giving a portion of it no access at all and when the application tries to blit from it later, a segfault results. Anyone had any similar experiences/know of this problem ? The offending application was little fighter II ntdll.dll.so`VIRTUAL_SetProt() ntdll.dll.so`VirtualProtectEx+0x27() ntdll.dll.so`VirtualProtect+0x23() x11drv.dll.so`X11DRV_DIB_DoProtectDIBSection+0x43() x11drv.dll.so`X11DRV_DIB_CreateDIBSection+0x32d() gdi32.dll.so`DIB_CreateDIBSection+0x4b() ddraw.dll.so`create_dib+0x14e() ddraw.dll.so`DIB_DirectDrawSurface_Construct+0xe3(dd5c2da0, dd5c16c8, dd532648) ddraw.dll.so`DIB_DirectDrawSurface_Create+0x6c() ddraw.dll.so`Main_create_offscreen+0x42() ddraw.dll.so`create_offscreen+0x105() ddraw.dll.so`Main_DirectDraw_CreateSurface+0xed() ddraw.dll.so`IDirectDrawImpl_CreateSurface+0x2f() 0x439a00()

April 27, 2003

Re: commctrl: fix indentation

by Francois Gouget

On Sat, 26 Apr 2003, Dimitrie O. Paun wrote: > > ChangeLog > Indentation fixes. I noticed the resulting file still uses a mixture of spaces and tabs for alignment. Maybe some tabs escaped? Tabs really shouldn't be used unless they are at the beginning of a line. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Francois Gouget

April 27, 2003

Re: wine/ scheduler/process.c programs/Makefile.in ...

by Dimitrie O. Paun

On April 26, 2003 08:47 pm, Alexandre Julliard wrote: > Moved the functionality of starting Win16 and DOS programs from the > common process startup into a separate winevdm application. Wow -- very nice! It almost makes miscemu/main.c wanna move to something like programs/wine ;) This is very cool, the source starts to look better and better every day. Thanks! -- Dimi.

April 27, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > At some point we will have no choice but to add support in Wine to this. > I am not a major hurt party, as my layout is going to be us,il even > without the Wine problem, but this is causing people grief. This gets > worse through the fact that the new X behaviour is actually a better > one. We are now officially holding people back from moving a behaviour > that is better for them. I don't see why explicitly adding a "us" keyboard layout would hurt people, since before 4.3.0 release en_US was a mandatory layout existing whether the user wanted it or not. > I would volunteer to do it, except I'm unusually busy of late. I know > that you have messed around with the keyboard code at some time. If you > have time, I recommend you look at it. Actually I have a plan to implement support for keyboard layout Win32 APIs and that anyway requires rewrite of big chunks of the existing keyboard code in x11drv, and as a part of that rewrite I'm going to decouple all existing keyboard layout tables with a US English one and build new tables with LCID and a layout id, but so far I don't know how to support several layouts for single locale but with different code pages (for instance for Russian locale we need to support 20866 (KOI8-R) and 1251 code pages). -- Dmitry.

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 25, 2003 04:53 pm, Francois Gouget wrote: > > So, can someone please tell me a *single* advantage of having KDE & QT > > as the GUI platform for Linux vs. having WIDE? > > I mentioned many but you seem to be conveniently ignoring them. No, I'm not ignoring anything. You referred to KDE/QT/GNOME/GTK, I argued precisely against KDE/QT. Once again, I think it is unacceptable to have our _platform_ (not apps) covered by the GPL. It sets an uneven playing field. I'll ask again: is this the kind of free OS we want to build? Yes, QT is licensed under QPL as well -- go rea

April 27, 2003

Re: Mac OS X and Wine troubles

by Steven Edwards

Pierre d'Herbemont wrote: > First of all I have a good news :) : Wine is able to build on Mac OS X. > > We decided not to follow WineHQ cvs version for early build, in order > not to be so much disturbed by others wine development and not to > produce bad patches, but don't worry ;) we are (of course!) planing to > send patches, I hope they would be integrated... > > If you have any idea of what could be wrong, or just a thought drop me > a line, it could be very useful :) > Without seeing your changes it is going to be almost impossible for the people here to help you.

April 26, 2003