wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

SSTab, Tabctl32.ocx again
by Fabian Cenedese 05 Dec '03

05 Dec '03

Hi I have a VB6 program which fails on wine due to the Tab control SSTab from TabCtl32.ocx as other users have reported too. Should this already work? Is this part of the work of improving wine for VB programs? Maybe it's not the tab control itself but one of its parts. I made a trace and this is the part shortly before the error message comes: fixme:ole:SPCF_CreateInstance (0x412d2408,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40669ea4), creating stdpic with PICTYPE_NONE. trace:ole:OleCreatePictureIndirect (0x40911d28,0x212f53d8,1,0x40669ea4) trace:ole:OLEPictureImpl_Construct (0x40911d28) type = 0 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000050) ret=412941cd 0009:Ret ntdll.RtlAllocateHeap() retval=40669f00 ret=412941cd 0009:Call ntdll.RtlAllocateHeap(405e0000,00000000,00000028) ret=41281227 0009:Ret ntdll.RtlAllocateHeap() retval=40669f58 ret=41281227 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000028) ret=41281282 0009:Ret ntdll.RtlAllocateHeap() retval=40669f88 ret=41281282 trace:ole:ConnectionPointImpl_QueryInterface (0x40669f58)->({b196b286-bab4-101a-b69c-00aa00341d07}, 0x40669f3c) trace:ole:ConnectionPointImpl_AddRef (0x40669f58)->(ref=1) trace:ole:ConnectionPointImpl_Release (0x40669f58)->(ref=2) trace:ole:OLEPictureImpl_Construct returning 0x40669f00 trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({7bf80980-bf32-101a-8bbb-00aa00300cab}, 0x40669ea4) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({00000109-0000-0000-c000-000000000046}, 0x40911dd8) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Load (0x40669f00,0x4182036c) 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000000) ret=412968dc 0009:Ret ntdll.RtlAllocateHeap() retval=40669fb8 ret=412968dc 0009:Call user32.CreateIconFromResourceEx(40669fb8,00000000,00000001,00030000,00000000,00000000,00000000) ret=41295ed6 0009:Call gdi32.DIB_BitmapInfoSize(40669fb8,00000000) ret=40b0ae1b 0009:Ret gdi32.DIB_BitmapInfoSize() retval=01780108 ret=40b0ae1b 0009:Ret user32.CreateIconFromResourceEx() retval=00000000 ret=41295ed6 fixme:ole:OLEPictureImpl_Load CreateIcon failed. trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) Looks like it's something with pictures that actually fails. Does this tell anyone anything? Do I need to re-register something else? Maybe some type library? Can I get more info with other debug channels? Or am I out of luck? Thanks bye Fabi

1 0

Status of InstallShield-Setup Engine
by Andreas Rosenberg 05 Dec '03

05 Dec '03

Hi! I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from Suse 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software. I tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them. b.t.w I'm using a different eMail account with this mailing list as with the Wine Bugzilla. We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken. Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE? If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did. Regards Andy

5 5

Re: PATCH for Bugs 1844 and 1845
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andreas Rosenberg <sonix2003(a)ctf-z.de> writes: > 1844: Point Size in DLG_TEMPLATE may be negative (with DS_SETFONT) > > Within Windows the pointSize parameter (for the FONT in the DLG_TEMPLATE > struct) may be a signed 16-bit integer. With WINE this integers get's > converted to an unsigned int resulting in huge font for the dialog. The size > of the dialog is being computed based on this font and results in invalid > parameters for CreateWindow, that may cause a termination of WINE. We detected > this problem testing our software with WINE. The fix for pointSize is OK, but why did you also change the sign of the font height in the CreateFont call? This doesn't look right. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: menu: nasty bug in menu tracking
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > The problem is that MSG.lParam is NOT necessarily in screen coordinates (even > though the comment I have removed says they are). As I can't trust the MSG.pt > either, this means using GetCursorPos() to determine the mouse position in > screen coordinates. This is wrong, you have to use lParam, as the comment says. And the coordinates are always in screen coords when we are tracking the menu. Something else must be going on here. -- Alexandre Julliard julliard(a)winehq.com

2 4

RE: menu: nasty bug in menu tracking
by Mike Jackson 05 Dec '03

05 Dec '03

Actually I think the code would work better like this:- if ((msg.message >= WM_MOUSEFIRST) && (msg.message <= WM_MOUSELAST)) { mt.pt.x = (short)LOWORD(msg.lParam); mt.pt.y = (short)HIWORD(msg.lParam); ClientToScreen(msg.hwnd,&mt.pt); -----Original Message----- From: wine-patches-admin(a)winehq.com [mailto:wine-patches-admin@winehq.com] On Behalf Of Andrew de Quincey Sent: Friday, 5 December 2003 8:45 AM To: wine-patches Subject: menu: nasty bug in menu tracking In IDA, the menus don't work correctly... as you move down a menu, the wrong item is highlighted if you move to a submenu.. after that, the wrong menu is opened and other bad things occur. The problem is that MSG.lParam is NOT necessarily in screen coordinates (even though the comment I have removed says they are). As I can't trust the MSG.pt either, this means using GetCursorPos() to determine the mouse position in screen coordinates. BTW: MSDN says this about the MSG.lParam value for WM_MOUSEMOVED events: lParam The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area. The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.

2 1

Re: wine/ programs/Makefile.in ./configure.ac ./co ...
by Ferenc Wagner 05 Dec '03

05 Dec '03

Alexandre Julliard <julliard(a)winehq.org> writes: > Added files: > programs/winetest: winetest.h util.c send.c maketest main.c > Makefile.in .cvsignore First of all, thank you very much for adapting and putting this into the tree! Losing some of the automation is not a problem as we seldom have new modules to test. But we've got an error in the cross-configured tree: tba:/usr/local/src/wine/pe/dlls/msvcrt/tests/ $ make i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe -L../../../dlls -lmsvcrt -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00464.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00332.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:274: first defined here make: *** [msvcrt_test.exe] Error 1 On the other hand, $ i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe works all right, and makes winetest.exe build flawlessly. Best wishes, Feri.

4 4

direct X 9 and troubles ..
by Lars Segerlund 04 Dec '03

04 Dec '03

Hi, I don't know how far along the directX9 support in wine is, and I am having trouble getting a game to run to which there is a downloadable demo (http://www.gamershell.com/news_BMotoGP2BDemo.shtml) which I thought might be usefull. The question is, should this run ? Is there something I have configured wrongly ? ( I have tried it on two different machines with different settings and hardware + soft OpenGL and hardware OpenGL ). Still it beats me .. any help appreciated if only 'no this should not work' .. / regards, Lars Segerlund.

2 1

warning fixes in comctl32.dll
by Jonathan Wilson 04 Dec '03

04 Dec '03

I just posted a patch to the reactos list that gets whatever comctl32.dll reactos has building with -Wall -Werror. But I dont have a WINE tree or any way to "port" these fixes over to WINEHQ. Can someone do it for me?

2 1

Re: sysparams: slight optimisation for IDA 3
by Dmitry Timoshkov 04 Dec '03

04 Dec '03

"Andrew de Quincey" <adq_dvb(a)lidskialf.net> wrote: > Version 3 > + spi_idx = SPI_GETICONTITLELOGFONT; > + > + if (!spi_loaded[spi_idx]) > + { > + memcpy(lpLogFont, &iconTitleLogFont, sizeof(LOGFONTA)); > + break; > + } Sorry to bother you again, but probably the comparison statement needs to be reverted... -- Dmitry.

7 10

Sound capture issues...
by Thomas Brix Larsen 04 Dec '03

04 Dec '03

Hi list, in the voice com program Skype (www.skype.org), I'm able to hear other people but I can't talk to them myself. Does anyone have a clue why? I believe this program uses DirectX to capture voice input. Not implented? Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

2 3

Font matching algorithms
by Mike Hearn 04 Dec '03

04 Dec '03

Hi, Recently Wine CVS has started always matching "System" to "Bitstream Vera Mono", and nothing I alter in the config file can seem to change it. This is kind of annoying as it's not a very good match, I'd rather it used Vera Sans, is there a way to override Wines choice? thanks -mike

1 0

Re: new old winetests
by Brian Vincent (C) 04 Dec '03

04 Dec '03

>> -- we're linking against ws2_32 >> Is this DLL available on all versions of Windows we >> want to run on? > >As far I know ><http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_st art_page_2.asp> >yes. But I am not sure whether it is installed in the base >system or only an option if you want to have networking >(like on Win3.1). Probably not too many people would run >the tests on a standalone machine anyway, but who knows... I actually just ran into this the other night. I installed TaxCut 2003 (which, by the way, mostly works with a few native DLL's) when it didn't like Wine's ws2_32. According to the references built into TaxCut this wasn't part of the original Win95 that shipped. It came out shortly after as an add-on and was likely first included in OSR2. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

6 8

Re: Missing msvcmaker .cvsignores 1
by Jakob Eriksson 04 Dec '03

04 Dec '03

:-D Shachar Shemesh wrote: > Ferenc Wagner wrote: > >> There will be no further parts, sorry. >> >> Feri. >> >> >> > Nobody expects the Spanish Inquisition! Our chief weapon is suprise. > Suprise and fear. Fear and suprise. Are TWO weapons are fear, suprise, > and ruthless eficiency. >

1 0

JournalPlayBack hook
by Juan Antonio Boscá Lloret 03 Dec '03

03 Dec '03

Hello, I'm trying to use the JournalPlayBack hook in a Win32 application and it doesn't work. However it looks to work in 16 bits. Any idea? Thank you --------------------------------------------------------------- Juan Antonio Boscá Lloret Departamento Programación CAE, S.A. jabosca(a)edicurs.com ---------------------------------------------------------------

3 2

Question about simple profiling implementation
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, the last thing I have to do with the profiling stuff is the trickiest: To decide what is the best way to determine the times. To get times that are useful, I'm using the RDTSC opcode (which returns the number of CPU clock cycles since the machine was powered on).. basically I've added a couple of defines to wine/debug.h: #define GET_COUNTER(__COUNTER) __asm__ __volatile__ ( "rdtsc" : "=a" (__COUNTER.LowPart), "=d" (__COUNTER.HighPart) ) and theres another, GET_ELAPSED which takes a start time, and calculates the difference. (BTW: I don't think these names are very good; I'm going to change them) The elapsed value is output when the relay trace for the function return is printed. I've also created a new script to analyse these to give you the average times, total times etc, and I've fixed tools/examine-relay to cope with the addition to the trace output. The problem is.. not all i386-derived CPUs support this feature. As far as I can see there are three ways of determining this. Which would people prefer? 1) Check in /proc/cpuinfo for the "tsc" flag. 2) I could write a short amount of assembly to interrogate the chip itself for this feature (a couple of instructions) 3) Use the existing QueryPerformanceCounter(). Personally, I'm favouring (2)... but what do other people think?

6 12

Re: debugger problems
by Chris Morgan 03 Dec '03

03 Dec '03

Nope, still doesn't appear to work. Rein, you see the same? Chris On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > Chris Morgan wrote: > > Still isn't working with build from todays cvs. Is this patch in there? > > it seems that AJ applied it after your mail had been sent > A+

5 10

Re: bc21en209 at Odin
by Dietrich Teickner 03 Dec '03

03 Dec '03

Hi Craig, The best way is for the future the first, removing '\\?\' in Odin and Wine. This way will need some times in odin, we are not prepaired for this, And I have no update access for wine. I will try to inform wine about the problem. I thing You have implemented this methods and You modify this without full forthing w98-api. This can us help for this build. We can test BC2.1 and can work with them as w2k(without , and we can also test the new api modifications. The switch should only force the w98 behavior in the path handling. For 'all', Odin and Wine can set the configuration-file. And Wine and Odin should work in the next time at the \\?\ problem. Please save also the last BC2.0 Build. Dietrich Scooter Support wrote: > Hi Dietrich, > > That would definitely cause problems in BC. We detect the Windows > version on startup and when running under WinNT4/2K/XP we use the \\?\ > notation for all file access, including sessions and rules. Under > Win9x we use the standard ANSI functions. > > In our current usage it wouldn't be a problem if ODIN simply removed > the \\?\ prefix and converted the paths back to ANSI. If it would be > easier I can add a command line switch to force BC to use the Win9x > behavior. > > Best Regards, > Craig > > > >>Hi Craig, > > >>I know where the problenm is in the comunication between BC21 and Odin. >>BC21 used only the long path notation for the filenames if the version >>set in Odin (Wine ?) as w2k or xp. If I set Win98 (nt4.0?), I have no >>problems with accessing folders. >>Currently is the \\?\h:\... notation only partialy supported in >>Odin (for eCS or OS/2) and in >>wine (for Linux). > > >>Start in native w98 ok, >>also in my xp >>Also in w98 in virtual PC. > > >>Can it be that many problems comes from the \\?\ prefix ? >>Also no access to the session database ? > > >>Best regards, >>Dietrich > > >>Log as w2k > > >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win2000' >>t01 ( 0): (FS=150B) version 5.0 >>t01 ( 0): (FS=150B) build nr 893 >>t01 ( 0): (FS=150B) Platform Id 2 >>t01 ( 0): (FS=150B) szCSDVersion Service Pack 2 >>... >>t02 ( 0): attachThread to dll NTDLL.DLL >>t02 ( 0): attachThread to dll NTDLL.DLL DONE >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003f1b8 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesW 3016994 >>t02 ( 1): KERNEL32: SetLastError to 123 >>t02 ( 1): KERNEL32: GetFileAttributes of \\?\h:\ returned -1 >>t02 ( 0): KERNEL32: GetFileAttributesW returned ffffffff >>t02 ( 0): KERNEL32: GetLastError returned 123 >>t02 ( 0): KERNEL32: SetLastError to 123 >>t02 ( 0): KERNEL32: RaiseException eedfade 1 7 327fd80 >>t02 ( 1): KERNEL32: RaiseException(0eedfadeh) >>t02 ( 1): KERNEL32: RtlDispatchException entered >>t02 ( 1): Win32 exception chain: > > >>Log as w98 > > >>t01 ( 0): (FS=150B) KERNEL32: SetEnvironmentVariable HOMEPATH to \ >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win98' >>t01 ( 0): (FS=150B) version 4.a >>t01 ( 0): (FS=150B) build nr 40a07ce >>t01 ( 0): (FS=150B) Platform Id 1 >>t01 ( 0): (FS=150B) szCSDVersion Win98 > > >>.. > > >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003ea14 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesA 2003e9f4 >>t02 ( 1): KERNEL32: GetFileAttributes of h:\ returned 16 >>t02 ( 0): KERNEL32: GetFileAttributesA returned 10 >>t02 ( 0): KERNEL32: SetErrorMode 1 >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) >>t02 ( 0): KERNEL32: SetErrorMode returned 0 >>t02 ( 0): KERNEL32: GetVolumeInformationA 2003ea24 329fc8b 104 2003ea3c >>2003ea40 2003ea44 329fb86 104 >>t02 ( 1): GetVolumeInformationA h:\ >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) > > >

1 0

I found what I believe is a bug in include/wine/prsht.h in ReactOS
by Jonathan Wilson 03 Dec '03

03 Dec '03

cc-ing WINE list in case its also present in the WINEHQ CVS this line: typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW; If this is a bug, can someone fix it? If its not, can someone explain why this construct is present (it looks very wierd to mix an A structure and a W structure in this typedef)

4 5

Re: winetest: the Wine test shell
by Ferenc Wagner 03 Dec '03

03 Dec '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- removed the CROSS compilation support. It should work > with a different build tree, but I haven't tested that Works just fine, thanks! Interestingly, yesterday evening I got all kinds of problems, like the build process trying to run WINDRES=false in the elf tree and other silly things. :) > -- removed striping the tests from the build. This wasn't > right for multiple reasons: > * it was using a hardcoded 'strip' command instead > of the configure one What about the following in maketest(s? cf. 8.3) STRIP="$3" DLLEXT="$4" [...] filename="$BINDIR/${test}_test.exe$DLLEXT" [...] $STRIP -s $filename and in Makefile.in (cf. tests.list vs 8.3 again): winetest.rc: maketest tests.list $(SRCDIR)/maketest -r $(SRCDIR)/tests.list "$(STRIP)" "$(DLLEXT)" > $@ || ( $(RM) $@ && exit 1 ) > * it seems strange that building winetest should > magically affect all the tests Maybe. But nothing depends on those, so I can't see it cause problems. And stripping reduces the final size of the program by an order of magnitude! It counts on a not-so-wide download link. > * why should we strip every time Stripping stripped programs doesn't take much time or effort. > Maybe we should replace this with an explicit > make strip-tests > or some such. Suggestins are welcome. Another possibility is to $STRIP -s -o ${testname}_test.exe$DLLEXT $filename It's sterile, but I'm not sure if it's better. > But I think it looks decent enough that it can go in, so we > can start sending small incremental patches to it. Shall not we put copyright notices into the files? > + if (remove (logname)) > + fatal (strmake (NULL, "Can't remove logfile: %d.", errno)); Maybe a warning would be enough here, too... :) Not that it makes any difference, of course. Best wishes, Feri.

1 0

Re: [clock04] Tidy up resources
by Alexandre Julliard 03 Dec '03

03 Dec '03

Richard Cohen <richard(a)daijobu.co.uk> writes: > Alexandre Julliard wrote: > > Your mailer has corrupted the 8-bit chars, could you please resend >> differently? > > Hmm, .. mozilla sent it as text/plain,8-bit,inline > Looks fine to me, and I can save and apply the patch OK. You are right, the problem was on my side; looks like a recent update had broken my sendmail config. My apologies to your mailer <g> -- Alexandre Julliard julliard(a)winehq.com

1 0

IDA speed problem analysis
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, I've been doing some more work on this, and I think I've found the culprit (my apologies to everyone for the crap I've been talking recently). Whenever IDA opens the Save box.. and in fact when it does a lot of operations, it seems to completely regenerate its menus. It uses an MDI interface, and so uses the WM_MDISETMENU message to set menus. The problem function is controls/menu.c/SetMenu(). Specifically, the call to SetWindowPos() passing the SWP_FRAMECHANGED flag. If I comment this call out, IDA becomes very fast... as fast as is it in windows. If I add in Y copies of that call, IDA becomes about Y times slower. Looking at the docs on MSDN for WM_MDISETMENU, it says "After sending this message, an application must call the DrawMenuBar function to update the menu bar". Which implies that the application is in charge of telling the menu bar to redraw, meaning the call to SetWindowPos() is superfluous. However, SetMenu() is used non by MDI menus as well, which DO expect the menu to be updated automatically (MSDN: "The window is redrawn to reflect the menu change"), which means it can't just be removed. Does anyone have any suggestions for the cleanest way to resolve this? Perhaps MDI should have an internal copy of SetMenu() tailored to its needs? BTW, under windows, the MDI code does not call the USER32.SetMenu() function.

1 0

Re: WineX 3.2
by Ivan Leo Murray-Smith 03 Dec '03

03 Dec '03

My free RPMs can't hurt Transgaming. For a start, on my winex page, I have a complete list of the features that only the commercial version has, and an invitation to subscribe to Transgaming if you want those extra features. As the freeware version doesn't include installshield, lots of games won't even install with the freeware version, for a start max payne. Also, even if a game does work, it won't run full screen, so if a users has lots of games that work with the free version, but wants them to run full screen, he'll probably go to the transgaming store. For all these reasons, I don't think my free RPMs are a financial threat to Transgaming in any way. Transgaming has taken a lot from Wine (Well it wouldn't have much to sell without wine), and I don't think there is anything wrong if someone takes something back. I think Transgaming should worry about those web sites that distribute the full commercial version of WineX, you just have to look for winex 3.2 download free on google , I reported this to Transgaming many months ago, and they still haven't taken any action. Ivan.

2 1

64bit Wine?
by J. Grant 02 Dec '03

02 Dec '03

Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. Kind regards JG p.s. I'm not subscribed to this list from this email address, so please include my email address in any replies.

4 4

wine in the press
by Tom 02 Dec '03

02 Dec '03

http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom

2 1

Wineinstall, Regedit seg faults
by Fabian Cenedese 02 Dec '03

02 Dec '03

Hi I just tried to install wine (from cvs 2003-12-02) on a fresh install of Knoppix (Debian). Configure/Compile went fine but I got an error with regedit as already reported here: http://bugs.winehq.org/show_bug.cgi?id=1664 In my case: Compiling regedit... make: nothing to do for "all" Preparing to install default wine registry entries... Installing default wine registry entries... tools/wineinstall: line 648: 10747 memory access error $REGEDIT $DEFREG >/dev/null Registry install failed. Is there something we can do to help? Anybody working on this? Thanks bye Fabi

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel