Re: ntdll / kernel32: #58
CLSIA -- Eric Pouech Hi Eric, is there a way you could change the name for your KERNEL_USER_TIMES variable (kut). I suspect that some proxy-scannners (DansGuardian f.e.) will trip over this as this a Dutch word for some part of the female body. I don't know if there's some general 'rule' about these kind of things/wordings ? Cheers, Paul.
Re: Multi-User Software Installs
Hi, I'm looking for ways to install wine on a multi-user box so that hundreds of users can share the same base registry. Username substitution would help in the registry processing. So when a flag is set for installing a global setting, registry keys written which include the username would instead put something like $username into the key. I've found a way to do so, but I have only a small home computer and not hundrets of users. I've put the C-Drive in /opt/windows, owned by root:root and writeable only by root. system.reg, dosdevices, userdef.reg and the config file are in /etc/wine. In the home directories, there's a .wine directory with individual user.reg directories and soft links to the files in /etc/wine. This way only root can install software and the users can't modify HKEY_LOCAL_MACHINE(They can temporarily for themselves, but it won't be stored and the others are not affected. Furthermore I copy the applnk entries to a system wide directory(/usr/share/applnk/wine) and modify them manually so every user can see them in his start menu. The major problem I have are those Apps which require full access to their install directories and installers which write required application settings to HKEY_CURRENT_USER. So basically the same problems as under Windows :-( Another thing is that even new applications do not really realize that I'm using the Administrator account if I am root, so that's why they install everything to HKEY_CURRENT_USER. My hack works for a small system like mine, but I doubt it's possible for hundrets of users. Stefan Dösinger
FW: Version Info on user.exe
Uwe Bonnes wrote: The real problem however is that the final installer asked for the Country version of user.exe. The installer expects 0407 for Germany. Wine doesn't supply that information, so the installer aborts. There sure enough must be a workaround for this in the T-Online suite. Otherwise this would mean that you can't run it on a non-German Windows installation and I would certainly guess that there are several people who run for instance the US or UK English Windows version for one reason or the other. So what would they have to do? Rolf Kalbermatter
Re: Version Info on user.exe
Dmitry == Dmitry Timoshkov [EMAIL PROTECTED] writes: Dmitry Uwe Bonnes [EMAIL PROTECTED] wrote: The real problem however is that the final installer asked for the Country version of user.exe. The installer expects 0407 for Germany. Wine doesn't supply that information, so the installer aborts. Dmitry Does that mean that the app refuses to run on a not German Dmitry version of Windows? If that's the case, then the app is broken. Yes, it refuses to run on non-german versions. And Rolf == Rolf Kalbermatter [EMAIL PROTECTED] writes: Rolf There sure enough must be a workaround for this in the T-Online Rolf suite. Otherwise this would mean that you can't run it on a Rolf non-German Windows installation and I would certainly guess that Rolf there are several people who run for instance the US or UK English Rolf Windows version for one reason or the other. So what would they Rolf have to do? There is no workaround. Look at: http://www2.service.t-online.de/dyn/c/06/50/28/650286.html : - Windows 98/Me, Windows 2000 Professional oder Windows XP (jeweils : deutsche Version; unter anderssprachigen Windows-Versionen ist : keine Installation möglich) It clearly states that no installation on a non german windows version is possible... It may be broken and anyways it is strange, but it does not abuse the windows API and I think wine should support it. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: CrossOver licensing behaviour?
Andreas Mohr wrote: Hi and greetings from LinuxTag in Karlsruhe! At our booth we had a visitor who told me that the version of CrossOver Office that he had been using issued a timely warning about license expiration few months before finally actually ceasing to provide service exactly after one year. Could it have been an email sent to notify the user the the *support* is about to expire? I'm assuming it was not a demo version. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: CrossOver licensing behaviour?
Hi, On Mon, Jun 27, 2005 at 11:07:30AM +0300, Shachar Shemesh wrote: Andreas Mohr wrote: Hi and greetings from LinuxTag in Karlsruhe! At our booth we had a visitor who told me that the version of CrossOver Office that he had been using issued a timely warning about license expiration few months before finally actually ceasing to provide service exactly after one year. Could it have been an email sent to notify the user the the *support* is about to expire? It most likely was. I'd think that it simply was a random (upgrade/downgrade/killgrade/...) breakage (quote Jeremy: sometimes you've gotta love Linux) causing CXO to go down, unrelated to any notification of *support* expiration. It might be a good idea to state in support expiration notifications that this does *not* result in usage expiration of CXO at the same time, i.e. that CXO can be used in an unlimited fashion, yet without support now. But OTOH such a statement might be counter-productive for new support sales ;-) Andreas Mohr
Battlefield 1942 Regression
Hello, The patch http://cvs.winehq.org/patch.py?id=18375 from 2005/06/22 13:30:30 breaks Battlefield to a certain extend. Battlefield used to have major texture problems(Units partially not visible, wrong colors sometimes) which went away approximately 2 Weeks ago. Now they came back with this patch. It seems to me that this patch fixes some functionality which was broken 2 weeks ago and which causes the problems and the root cause is somewhere else. Can someone give me a hint/documentation links what might be wrong here? Is it worth trying Oliviers DirectX patches? It looks to me that he's just committing them to CVS. Stefan Dösinger
WileLib: Retrurning function pointers
Hi,
I'm having big troubles using function pointers.
Shortly:
I'm trying to build a Winelib compatible DLL that returns function
pointers; that pointers must be used by a WIN32 app that runs under Wine.
The problem is that the returned function pointers, when directly used
by the WIN32 code, crash the application:
wine: Unhandled exception (thread 0009), starting debugger...
In details:
For instance the DLL is a PKCS#11 library.
The PKCS#11 function C_GetFunctionList() returns a structure that
contains pointers to all PKCS#11 functions (so you need to export/use
just the C_GetFunctionList symbol)
struct CK_FUNCTION_LIST
{
CK_C_Initialize C_Initialize;
CK_C_Finalize C_Finalize;
CK_C_GetInfo C_GetInfo;
...
};
CK_RV C_GetFunctionList(CK_FUNCTION_LIST_PTR_PTR ppFunctionList);
...
All function have cdecl calling convention.
The problem is:
I need to use a linux-native BINARY PKCS#11 library under a WIN32
program should run with Wine.
As specified in the Winelib docs I've created a Winelib wrapper DLL.
Firts try:
I've wrapped just C_GetFunctionList() and I've exported it using a .spec
file.
The wrapped C_GetFunctionList() loads the native-linux lib and calls the
native C_GetFunctionList(). It just returns function pointers structure
to the calling application without doing any fix-up.
But when the WIN32 program calls any function using a function pointer
contained in CK_FUNCTION_LIST, i.e. C_GetInfo(), the function get called
but the WIN32 program crash just after the function returns:
wine: Unhandled exception (thread 0009), starting debugger...
Second try:
Looking at winebuild/winemaker/winegcc I've noticed that a PE-like
export table is automatically created using the .spec file as input. I
can't really understand all implementation details, but looks like that
there is also some code that performs calling convetion
conversion/fix-up (of course from c to stdcall, but there is also some
code for win32-cdecl to gcc-cdecl... ?).
So i've tried to use the winelib's LoadLibrary() and GetProcAddress(),
to load self and to get function pointers exactly as a Win32
application would do... hoping that this way I would get pointers to
functions fixed for externa-win32 usage...
But I noticed that fucntion pointers returned by GetProcAddress() are
exactly equal to internal fucntion pointers.
I suppose that the GetProcAddress() called from within a Winelib DLL is
smart enough to return internal pointers isntead of unusable
win32-external pointers...
Third try: not yet done
This is a very complicated way; I think that it should works, but I
wondering if ther isn't a simpler way...
Writing a pure-WIN32 library that exports just C_GetFunctionList and
does the CK_FUNCTION_LIST fix-up (lets call this DLL w32-stub)
the Winelib DLL should stub and export ALL PKCS#11 functions, and not
just C_GetFunctionList() (lets call this DLL winelib-wrapper).
So...
The WIN32 app loads the w32-stub.
The w32-stub loads winelib-wrapper (using LoadLibrary) and load all
PKCS#11 function pointers using GetProcAddress(); this should return
WIN32 usable function pointers.
The winelib-wrapper load the linux-native PKCS#11 library (using
dlopen); all exported functions just wrap native functions of the
linux-native library.
begin:vcard
fn:Giuseppe Amato
n:Amato;Giuseppe
org:ST Incard srl;Financial Identification Smartcards
adr:;;Z. I. Marcianise Sud;Marcianise;Caserta;81025;Italy
email;internet:[EMAIL PROTECTED]
title:Mr.
tel;work:+39 0823 630 404
x-mozilla-html:FALSE
url:http://www.incard.it
version:2.1
end:vcard
Re: WileLib: Retrurning function pointers
On Mon, Jun 27, 2005 at 11:53:34AM +0200, Giuseppe AMATO wrote:
Hi,
I'm having big troubles using function pointers.
Shortly:
I'm trying to build a Winelib compatible DLL that returns function
pointers; that pointers must be used by a WIN32 app that runs under Wine.
The problem is that the returned function pointers, when directly used
by the WIN32 code, crash the application:
wine: Unhandled exception (thread 0009), starting debugger...
Very likely you have a mixup between stdcall and cdecl calling
convention.
In details:
For instance the DLL is a PKCS#11 library.
The PKCS#11 function C_GetFunctionList() returns a structure that
contains pointers to all PKCS#11 functions (so you need to export/use
just the C_GetFunctionList symbol)
struct CK_FUNCTION_LIST
{
CK_C_Initialize C_Initialize;
CK_C_Finalize C_Finalize;
CK_C_GetInfo C_GetInfo;
...
};
CK_RV C_GetFunctionList(CK_FUNCTION_LIST_PTR_PTR ppFunctionList);
...
All function have cdecl calling convention.
Are you sure? Do even the win32 version have cdecl calling convention?
Ciao, Marcus
pgp2AKHaBOyRE.pgp
Description: PGP signature
Re: Battlefield 1942 Regression
--- Stefan Dösinger [EMAIL PROTECTED] wrote: Hello, The patch http://cvs.winehq.org/patch.py?id=18375 from 2005/06/22 13:30:30 breaks Battlefield to a certain extend. Battlefield used to have major texture problems(Units partially not visible, wrong colors sometimes) which went away approximately 2 Weeks ago. Now they came back with this patch. It seems to me that this patch fixes some functionality which was broken 2 weeks ago and which causes the problems and the root cause is somewhere else. That seems odd SFAIK Battlefield 1942 is a directX 8 game My notes on the demo are as follows 'seems to be ok, but there's a lot of missing text (this could just be a missing font though) graphics also seem slow, but that could be mmtimer bogging things down slowness looks like it's down to two things... drawstridedslow being one of them. Since drawStridedSlow is fixed in d3d9 the came should hopefully get a good enough performance when d3d8 is made to point to wined3d. One of the shaders doesn't work properly There's the odd missing texture or wrongly draw element, and the graphics are annoyingly slow, apart from that everything seems to work fine. Can someone give me a hint/documentation links what might be wrong here? Is it worth trying Oliviers DirectX patches? It looks to me that he's just committing them to CVS. My DirectX patches shouldn't affect anything, as they are only for DirectX 9 and shoudln't affect DirectX 8. having said that the intent is to move the DirectX 8 code over to the new code, this should fix quite a few of the problems I've noted with the game. Anyhow, I'll retest ASAP to make sure it's still working at my end. Stefan Dösinger ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: Move Notification Window (aka systray) To A Separate Process
Robert Shearman wrote: Changelog: Move notification window (aka systray) to a separate process. Sorry, this changelog should be as follows instead: Mike Hearn [EMAIL PROTECTED] Robert Shearman [EMAIL PROTECTED] Move notification window (aka systray) to a separate process. -- Rob Shearman
Re: dlls/commdlg/printdlg.c : Now works PageSetupDlgA function
Hi, you may want to recheck your patch as it contains lots of cvs update conflicts. [EMAIL PROTECTED] wrote: It's too big patch, but break it to many parts very hard. ChangeLog: Complex PageSetupDlg patch [Snip] + printdlg.c ^ cvs update conflict +/*** + * DefaultPaintHook + Default hook paint procedure that receives WM_PSD_* messages from the dialog box + whenever the sample page is redrawn. +*/ + [Snip] bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Where to map the unixfs extension
Hi,
What if we map the unixfs extension on the desktop instead of on mycomputer?
So if HKCR\Software\Microsoft\Windows\Current
Version\Explorer\Desktop\Namespace\{UnixDosFolderCLSID} is present, the
desktop folder would forward ParseDisplayName calls to UnixDosFolder instead
of MyComputer.
We could de-activate the special case of enumerating all child's of MyComputer
in the file dialogs iff unixfs is rooted at the desktop.
This way we wouldn't have to introduce a second MyUnixComputer and the user
could expand MyComputer, if he forgot where there C: drive is mapped. But he
would'nt see the drives until he does so.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Re: Battlefield 1942 Regression
Hi, That seems odd SFAIK Battlefield 1942 is a directX 8 game Yes, as far as I know it is. My notes on the demo are as follows 'seems to be ok, but there's a lot of missing text (this could just be a missing font though) The fonts work with cedega, in wine there are only blocks. I didn't look at this deeply, but a missing font sounds possible graphics also seem slow, but that could be mmtimer bogging things down Not for me. Works fine with everything set to high at 800x600. Envmap and shadows disabled. (1.6 GHZ Intel Pentium M processor, 512 MB of RAM, Radeon Mobility 9000). Seems to work better(Tested in Cedega) than on WinXP on my friends notebook, who has exactly the same hardware. Wine's performance is the same as Cedegas, but you have to redirect STDERR to /dev/null, otherwise the scrolling wine messages will eat your fps. There's the odd missing texture or wrongly draw element, and the graphics are annoyingly slow, apart from that everything seems to work fine. Yes, thats also what I noticed. With Cedega the graphics work fine, but it's hell unstable because of the crappy fglrx driver(Some maps don't start, ...) In Wine it's much more stable and I have this texture problem and problems with Direct Sound and a minor Mouse Lock problem. My DirectX patches shouldn't affect anything, as they are only for DirectX 9 and shoudln't affect DirectX 8. having said that the intent is to move the DirectX 8 code over to the new code, this should fix quite a few of the problems I've noted with the game. Anyhow, I'll retest ASAP to make sure it's still working at my end. I can send you screenshots if they are of use for you, but the most immediate thing is that you don't see the hands holding the weapon in front of you if the patch is applied. Thanks for the good Direct3D work done so far! Stefan Dösinger
Re: Move Notification Window (aka systray) To A Separate Process
From: Robert Shearman [EMAIL PROTECTED] Changelog: Move notification window (aka systray) to a separate process. --- /dev/null 2005-06-27 03:50:51.210644768 -0500 +++ programs/winesystray/Makefile.in 2005-06-26 08:34:07.0 -0500 Cool, but I wan't the plan to have only one external process (a wineexplorer or somesuch) that would handle desktop mode, systray, etc? This could be it, but then the naming (winesystray) seems a bit off... -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
AppDB
Hi, My Summer of Code proposal to work on the AppDB wasn't accepted, but I still wish to do some of the things I listed. Anyway, I was looking at the code for image handling, and I see it is written for GD 1. Thus, any image which has to be resized gets cut down to 256 colors, and is simply resized instead of being resampled, which makes the image blocky. According to the PHP manual, these better functions require PHP 4.0.6 and GD 2.0.1 or higher. Is the AppDB server really running such an old version of PHP that this is required? --Mitchell Mebane -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
Re: AppDB
Le lundi 27 juin 2005 à 11:24 -0500, Mitchell Mebane a écrit : Hi, My Summer of Code proposal to work on the AppDB wasn't accepted, but I still wish to do some of the things I listed. Anyway, I was looking at the code for image handling, and I see it is written for GD 1. Thus, any image which has to be resized gets cut down to 256 colors, and is simply resized instead of being resampled, which makes the image blocky. GD2 code is commented because we have only a very old php version on the server. According to the PHP manual, these better functions require PHP 4.0.6 and GD 2.0.1 or higher. Is the AppDB server really running such an old version of PHP that this is required? Exactly. The nice thing is that when Jeremy will decide to upgrade php we will be able to regenerate every screenshot because we keep the original image as well. -- Jonathan Ernst [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: AppDB
There are server upgrades that will hopefully come in the next few months that will upgrade a lot of the libraries and software on the appdb machine. This will let us use the latest version of GD. Afaik this is the only think holding up our use of the newer GD. Jeremy, any update on when the server is getting an upgrade? Anything we can do to speed this up? Chris On 6/27/05, Mitchell Mebane [EMAIL PROTECTED] wrote: Hi, My Summer of Code proposal to work on the AppDB wasn't accepted, but I still wish to do some of the things I listed. Anyway, I was looking at the code for image handling, and I see it is written for GD 1. Thus, any image which has to be resized gets cut down to 256 colors, and is simply resized instead of being resampled, which makes the image blocky. According to the PHP manual, these better functions require PHP 4.0.6 and GD 2.0.1 or higher. Is the AppDB server really running such an old version of PHP that this is required? --Mitchell Mebane -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-03.diff]
Gerold J. Wucherpfennig [EMAIL PROTECTED] writes:
+static cab_ULONG fci_set_little_endian_ulong( cab_ULONG i ) {
+ unsigned char v[4];
+ v[0]=i;
+ v[1]=i8;
+ v[2]=i16;
+ v[3]=i24;
+ return *((cab_ULONG*)(v));
+}
+
+static cab_ULONG fci_get_little_endian_ulong( cab_ULONG i ) {
+ unsigned char v[4];
+ cab_ULONG r=0;
+ memcpy(v,i,4);
+ r|=v[3];
+ r=8;
+ r|=v[2];
+ r=8;
+ r|=v[1];
+ r=8;
+ r|=v[0];
+ return r;
+}
You should use the Rtl*ByteSwap functions with the appropriate #ifdef
WORDS_BIGENDIAN, it would be a lot more efficient, particularly on
little endian platforms that represent 99.9% of the real world cases.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Fix libGL.a check on configure
Anderson Lizardo [EMAIL PROTECTED] writes: Hi, Changelog: Fixed the libGL.a configure check for systems where /usr/X11R6/lib/libGL.so is a symbolic link. PS.: I've not used a simple test -e because http://www.winehq.org/hypermail/wine-patches/2002/01/0206.html says this does not work on Solaris. My guess is that if test -e doesn't work, test -L won't work either... -- Alexandre Julliard [EMAIL PROTECTED]
Re: msi: prevent locking the cd
Aric Stewart [EMAIL PROTECTED] writes: Copy the msi file to a temp file to prevent locking a CD during an install. This allows multi disc installs to eject the first volume. This fails make test: fixme:msi:MSI_OpenDatabaseW open failed r = 80030050! format.c:84: Test failed: Failed to open package format.c:102: Test failed: Failed to close package fixme:msi:MSI_OpenDatabaseW open failed r = 80030050! format.c:84: Test failed: Failed to open package format.c:668: Test failed: size wrong(16) etc... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [wine] Soliciting suggestions for AppDB
David Lee Lambert wrote: On Wednesday 08 June 2005 08:32 pm, Mitchell Mebane wrote: I'm putting together a Summer of Code proposal for working on the AppDB. I've been talking with Chris Morgan, and he has a few suggestions, but I was looking for more. Does anybody have any features they'd like added to the AppDB, quirks they'd like worked out, or things of that nature? I have some ideas about the AppDB, but I've been working on some of them myself, and others really need the approval of the WinHQ webmaster more than anything. Still, I'd like to hear what other people think of them: 1. The AppDB, Bugzilla and the Wiki ought to send last-modified information for most of their pages. This would speed things up, in some cases, for dialup users, but the real advantage would be as protection against a slashdotting or onslaught of AOL users. Many of the pages also send other headers that prevent caching of positive lookups. Today I sent a patch to the AppDB maintainer to do this for images, which are probably the biggest performance hit (they cause the AppDB main page to take about 30 seconds to load over a dialup connection). However, almost any page in each of these databases could in theory be cached. Bugzilla bug display pages already display a "Last modified" datum in the text of the page, and so do Wiki pages (bug 2889 mentions this). Several of the AppDB tables already have TIMESTAMP columns, so I was planning to write some code to just gather them all together and send the latest one as the last-modified date. The only problem is that if a page contains an item which is then deleted, its timestamp will go backwards. David, I don't see this patch on wine-patches. Did you send this in? --Mitchell Mebane -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
RE: Version Info on user.exe
It clearly states that no installation on a non german windows version is possible... It may be broken and anyways it is strange, but it does not abuse the windows API and I think wine should support it. But how? The next version will check kernel32 instead to be German, and then the French will decide that their home banking software can only run on French Windows systems and will check the same DLL or another for a french language identifier, probably not even working with Swiss French ;-( This is really leading nowhere. An application checking the user32.dll language identifier does check nothing at all with this. It wouldn't even serve as a check to avoid possible problems with foreign country number format settings as you can set them to anything in Windows Control Panel on your own. So I think this app is simply broken in a very stupid way. If somebody wants to make this work for his Wine copy I think he needs to hack the resources in user32 themselves. Rolf Kalbermatter
Re: [wine] Soliciting suggestions for AppDB
The patch needed some minor changes and clarifications. I haven't received a resubmission yet. Chris On 6/27/05, Mitchell Mebane [EMAIL PROTECTED] wrote: David Lee Lambert wrote: On Wednesday 08 June 2005 08:32 pm, Mitchell Mebane wrote: I'm putting together a Summer of Code proposal for working on the AppDB. I've been talking with Chris Morgan, and he has a few suggestions, but I was looking for more. Does anybody have any features they'd like added to the AppDB, quirks they'd like worked out, or things of that nature? I have some ideas about the AppDB, but I've been working on some of them myself, and others really need the approval of the WinHQ webmaster more than anything. Still, I'd like to hear what other people think of them: 1. The AppDB, Bugzilla and the Wiki ought to send last-modified information for most of their pages. This would speed things up, in some cases, for dialup users, but the real advantage would be as protection against a slashdotting or onslaught of AOL users. Many of the pages also send other headers that prevent caching of positive lookups. Today I sent a patch to the AppDB maintainer to do this for images, which are probably the biggest performance hit (they cause the AppDB main page to take about 30 seconds to load over a dialup connection). However, almost any page in each of these databases could in theory be cached. Bugzilla bug display pages already display a Last modified datum in the text of the page, and so do Wiki pages (bug 2889 mentions this). Several of the AppDB tables already have TIMESTAMP columns, so I was planning to write some code to just gather them all together and send the latest one as the last-modified date. The only problem is that if a page contains an item which is then deleted, its timestamp will go backwards. David, I don't see this patch on wine-patches. Did you send this in? --Mitchell Mebane -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
Re: AppDB
On Mon, 2005-06-27 at 13:09 -0400, Chris Morgan wrote: Jeremy, any update on when the server is getting an upgrade? Anything we can do to speed this up? Sorry, no ETA at this time. -- Jeremy Newman [EMAIL PROTECTED] CodeWeavers, Inc.
