wine-devel December 2006

wine-devel@winehq.org

112 participants
190 discussions

Re: [Wine] Cyber Cafe Pro on Linux
by Edward Savage 06 Dec '06

06 Dec '06

I'm going to get eaten alive for this though depending on your requirements it might be a better idea to stick with Windows and really lock down your installation. I've been directly involved in two Linux migrations for Internet Cafes (and advised on several others) - one successful (net cafe) and the other unsuccessful (gaming cafe) - and in both cases it was more trouble than it was worth. The problem isn't the software it is the users; When they go to use the software they notice, for example, that they aren't using IE and when they come up to some page that doesn't display perfectly problems occur. There are many more examples that just make the mind hurt. So unless this Cycber Cafe Pro provides _everything_ you really need to be asking yourself if you really want to open this can of worms. On 12/5/06, vulani mabunda <vulani(a)mac.com> wrote: > > Hi, > > I'm running an internet cafe using Cyber Cafe Pro software. This software > is design soley for Windows platforms. We're constantly experiencing > problems with Windows with regards to viruses and stability issues. > Recently, we lost all our data and had to re-install. > > May you please help us in flawlessly porting this application so that it > can run on Linux both on the server and client sides. If this happens, it > could mean an end to our nightmare with Windows! > > We have already tried Open Kiosk (which natively runs on Linux) prior to > making my request. Open Kiosk is free but is not advanced enough to meet our > requirements. For example, it can't allow us to control and charge for > excessive bandwidth. We've done extensive research on what is available and > so far Cyber Cafe Pro seems to meet all our requirements with the exception > of running only on Windows. Hodoman works on Linux but isn't as advanced as > Cyber Cafe Pro is. > > This is the reason why we are interested in trying to get Cyber Cafe Pro > to work on Linux. Cyber Cafe Pro people aren't interested in assisting us > with regards to porting their application to Windows. > > > Regards > > Vulani Mabunda > CEO > Internet CAfe Jack > South Africa > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-users >

3 3

Putting my hand up for WWN
by Edward Savage 06 Dec '06

06 Dec '06

I'm prepared to write the WWN releases in Brian Vincent seeming absence if it pleases the powers that be. If this is alright I'd like some one to give an overview of what topics should be covered and then for some one to review the first one or two created. I've read the last hundred or so WWN issues over the years so I have a good idea of whats required though clarification would be nice. I already got wine-devel/wine-users - are there any more that need to be monitored. Finally I would need to know how to submit the newsletter and the proper syntax. Edward

2 2

Re: [winetest] Make sure we can send larger files
by Dimi Paun 05 Dec '06

05 Dec '06

On Thu, November 30, 2006 1:01 pm, Paul Vriens wrote: > I'm hitting the 1MB limit already with my win98 tests. Most other tests > are about to reach that threshold as well. I'd make it 2MB, what's 1MB these days... :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 2

Putting my hand up for WWN
by Edward Savage 05 Dec '06

05 Dec '06

3 2

Re: [PATCH][DbgHelp] Recognize DT_GNU_HASH
by Thomas Fitzsimmons 05 Dec '06

05 Dec '06

Thomas Fitzsimmons wrote: > This patch fixes #6830. > > Tom > > 2006-12-05 Thomas Fitzsimmons <fitzsim(a)redhat.com> > > * dlls/dbghelp/elf_module.c (is_dt_flag_valid): Recognize > DT_GNU_HASH. > > > ------------------------------------------------------------------------ > > diff --git a/dlls/dbghelp/elf_module.c b/dlls/dbghelp/elf_module.c > index 85494ca..a7fa2f8 100644 > --- a/dlls/dbghelp/elf_module.c > +++ b/dlls/dbghelp/elf_module.c > @@ -1041,6 +1041,9 @@ #endif > #ifndef DT_EXTRANUM > #define DT_EXTRANUM 0 > #endif > +#ifndef DT_GNU_HASH > +#define DT_GNU_HASH 0x6ffffef5 > +#endif > return (d_tag >= 0 && d_tag < DT_NUM + DT_PROCNUM + DT_EXTRANUM) > #if defined(DT_LOOS) && defined(DT_HIOS) > || (d_tag >= DT_LOOS && d_tag < DT_HIOS) > @@ -1048,6 +1051,9 @@ #endif > #if defined(DT_LOPROC) && defined(DT_HIPROC) > || (d_tag >= DT_LOPROC && d_tag < DT_HIPROC) > #endif > +#if defined(DT_GNU_HASH) > + || (d_tag == DT_GNU_HASH) > +#endif > ; > } Ugh, no need for the extra "if defined" check, of course. Tom

1 0

Re: James Hawkins : msi: Add tests for installing from continuouscabinets.
by Dmitry Timoshkov 05 Dec '06

05 Dec '06

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > the test should be either disabled completely, or made it run only > if cabinet.dll is detected. Last line should read as: if good/not broken cabinet.dll is detected. -- Dmitry.

1 0

Re: James Hawkins : msi: Add tests for installing from continuouscabinets.
by Dmitry Timoshkov 05 Dec '06

05 Dec '06

"Alexandre Julliard" <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: 1f3f88bf67d32983ff00d96bf58bf91c6e72ae02 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=1f3f88bf67d32983ff00d96bf… > > Author: James Hawkins <truiken(a)gmail.com> > Date: Mon Oct 23 18:15:28 2006 -0700 > > msi: Add tests for installing from continuous cabinets. According to http://test.winehq.org/data/200612021000/ this test fails under all NT based platforms. I've ran it under XP SP2 and got the following error messages: install.c:864: Test failed: Expected ERROR_SUCCESS, got 1603 install.c:869: Test failed: File not installed install.c:870: Test failed: File not installed install.c:871: Test failed: File not installed install.c:873: Test failed: File not installed install: 1147 tests executed, 0 marked as todo, 5 failures. and a bunch of .log files in the TEMP directory with the following contents: Error 1334. The file 'maximus' cannot be installed because the file cannot be found in cabinet file 'test1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package. Error 1334. The file 'augustus' cannot be installed because the file cannot be found in cabinet file 'test1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package. So, either the test is not entirely correct, or just the .cab files it creates are corrupted. -- Dmitry.

2 2

Re: make check_no_exec() work reliable
by Peter Beutner 04 Dec '06

04 Dec '06

Peter Beutner wrote: > Before starting to make this whole noexecute override behaviour configurable, > it first must work reliable. In its current form there is no guarantee that > the check_no_exec() function is actually called, because any other installed > exception handler might decide to handle the exception itself. > And as seen by the number of failing applications, this seems to happen > quite a lot. > This patch therefore makes check_no_exec() to be called before any other > exception handler. > > --- Any comments what is wrong with this one?

2 7

Re: [5/6] wined3d: Make CreateFakeGLContext thread safe.
by Alexandre Julliard 04 Dec '06

04 Dec '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > This adds thread safety to CreateFakeGLContext and it's > corresponding Release function only. This addresses no thread > safety in the rest of wined3d, which AFAIk as a whole is still > not thread safe. When addressing thread safety in wined3d it must > also be taken care that a GL context is not deleted away by a > different thread when execution is between these two functions. You are calling ENTER_GL while holding your crit section, this will deadlock. -- Alexandre Julliard julliard(a)winehq.org

1 0

Help needed on an SHGetFileInfoW() crash
by Francois Gouget 04 Dec '06

04 Dec '06

A friend pointed me to a railway signalling simulation game: http://www.simsig.co.uk/html/downloads.html However, the installer crashes in SHGetFileInfoW(): 000d:Call shell32.SHGetFileInfoA(0045eae8,00000010,0034fcec,00000160,00001010) ret=0045e9f6 000d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e8871b2 000d:trace:seh:raise_exception info[0]=00000000 000d:trace:seh:raise_exception info[1]=00000000 More precisely the crash happens on this line: hr = IShellFolder_GetUIObjectOf(psfParent, 0, 1, (LPCITEMIDLIST*)&pidlLast, &IID_IExtractIconW, &uDummy, (LPVOID*)&pei); And the reason is that psfParent is NULL. psfParent is initialized a bit above, but only if SHGetFileInfoW() was given a PIDL and SHGFI_USEFILEATTRIBUTES was not used. This means that whenever a 'real path' or SHGFI_USEFILEATTRIBUTES is used in combination with SHGFI_DISPLAYNAME, SHGFI_ICONLOCATION, SHGFI_ICON or SHGFI_SYSICONINDEX, then SHGetFileInfoW() will crash. However we cannot just create a pidl since the 'real path' will usually refer to a nonexistent file or directory (in our case it is 'c:\directory' so it's clear the installer just wants to know what's the icon for a standard directory). Any idea? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 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 December 2006