Re: Broken FC5 packages - stay clear.
On 6/14/06, Michael Stefaniuc <[EMAIL PROTECTED]> wrote: Dream on! As long as all those subpackages are generated from the same SRPM you will save nothing and get all of them if the SRPM changes. I suppose you are right, at least at the moment. Hopefully one day if the build system detects that a subpackage hasn't changed then it would not update that particular rpm. Where subpackes help is to limit the amount of requirements the program has. That's highly used on heavy customized servers and less so on the desktop. I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it. Sounds like a good idea. n0dalus.
Re: One more shot at ntoskrl implementation
Tuesday, June 13, 2006, 4:27:07 PM, Detlef Riekenberg wrote:
> Vitaliy Margolen wrote:
>> Here is last instalment of safedisc support in Wine.
> Great Stuff, but heavy.
Thank you. I appreciate all the comments.
Well it's not that easy to run kernel drivers...
> +lpservicestatus->dwCurrentState = SERVICE_STOPPED;
> +else
> +{
> +Sleep(1000);
> +lpservicestatus->dwCurrentState = SERVICE_RUNNING;
> Waiting for something, reason unknown without a comment.
> It seems to be related to:
> + * Note: NtQuerySystemInformation needs to be fixed to handle this
> +++ b/dlls/ntdll/misc.c
> in NTSTATUS NTOSKRNL_connect(HANDLE *device_handle)
> +ntoskrnl_started = TRUE;
> +sleep(3);
> +continue;
> Waiting for something, reason unknown without a comment.
> Is it here to force a shedule / taskswitch?
Those are the two places that do need extra work. I'm not sure what would be a
clean way to check if a driver is running (1st wait) and synch with child
process
startup - ntoskrnl (2nd wait).
> +++ b/programs/ntoskrnl/ntoskrnl_api.c
> +LPCSTR wine_dbgstr_us( const UNICODE_STRING *us )
> This is also in "dlls/ntdll/misc.c"
> Is it useful to add "debugstr_us" to "include/wine/debug.h"?
Yes that's where it came from. I'm not sure if it would be beneficial to move it
or not.
Vitaliy.
Re: [Setuapi] implement SetupDiCreateDeviceInfoListExW - try 3
Hi Christian Gmeiner:
> Sorry for the new version, but i got rid of the whitspace stuff and also
> added a check if Reserved != NULL.
>
> I hope that this patch is ready to commit now.
+if (MachineName != NULL)
+{
+FIXME("remote support is not implemented");
+goto cleanup;
+}
A failure should always set an error.
You should add a test for this in the testsuite.
(winspool as example uses an empty servername the same way as NULL).
For external Servers, ERROR_ACCESS_DENIED is a very common Result.
+if (Reserved != NULL)
+{
+SetLastError(ERROR_INVALID_PARAMETER);
+goto cleanup;
+}
Same here. This is simple to test in the testsuite.
-SerialPortList *list = (SerialPortList *)devinfo;
+struct DeviceInfoSet *list = (struct DeviceInfoSet *)devinfo;
-if (list->magic == SETUP_SERIAL_PORT_MAGIC)
+if (list->magic == SETUP_DEVICE_INFO_SET_MAGIC)
{
This is wrong.
Read: static HDEVINFO SETUP_CreateSerialDeviceList(void) (line 904)
---
In your test:
+// create empty DeviceInfoList
C++ comments are not allow (not supported by some compiler)
+devlist = SetupDiCreateDeviceInfoListExW(NULL, NULL, NULL, NULL);
+
+ok(devlist && devlist != INVALID_HANDLE_VALUE,
"SetupDiCreateDeviceInfoListExW failed : %p %ld\n", devlist,
GetLastError());
- You missed the "SetLastError(0xdeadbeef);" before the tested function.
- The first Part of your "ok()" - message
("SetupDiCreateDeviceInfoListExW failed :") has no additional infos.
When a test fails, you will already get:
"__FILE__:__LINE__: Test failed:"
You know the dll, file and line of the failing "ok()" - statement.
Example:
info.c:932: Test failed: returned 0 with 1801 (expected '!=0' or '0'
with ERROR_INVALID_PARAMETER)
You may want to look at my recent Tests / Implementations for
GetPrintProcessorDirectory or AddMonitor/DeleteMonitor (winspool.drv),
but do not use the macro "MAGIC_DEAD" in the tests
(it works, but 0xdeadbeef has more advantages).
As an Example, that we really need tests for every API-Function:
The second Parameter of "DeleteMonitor" is ignored in all tested
Windows-Versions.
--
By By ...
... Detlef
Re: msi: Add tests for MsiInstallProduct
On 6/12/06, James Hawkins <[EMAIL PROTECTED]> wrote: Hi, Changelog: * Add tests for MsiInstallProduct. Ignore this patch for now. Eclipse changed necessary tabs to spaces, and I forgot to include module imports for Makefile.in. I'll resend it tonight. -- James Hawkins
Re: One more shot at ntoskrl implementation
Vitaliy Margolen wrote:
> Here is last instalment of safedisc support in Wine.
Great Stuff, but heavy.
Need to check with http://www.gameburnworld.com/PCprotectedgames.htm
which CD I can use for testing.
> Need to run tools/make_reqwests.
Big fingers at the Keyboard :-)
Just some things, that I want to mention without deep knowledge, what
the code does:
+++ b/dlls/advapi32/service.c
@@ -1569,6 +1625,40 @@ BOOL WINAPI QueryServiceStatus(SC_HANDLE
+static int i;
+
+lpservicestatus->dwServiceType = SERVICE_KERNEL_DRIVER;
+if (i == 0)
i was not initialized. You initialized static variables in other
locations (static BOOL * = FALSE)
+lpservicestatus->dwCurrentState = SERVICE_STOPPED;
+else
+{
+Sleep(1000);
+lpservicestatus->dwCurrentState = SERVICE_RUNNING;
Waiting for something, reason unknown without a comment.
It seems to be related to:
+ * Note: NtQuerySystemInformation needs to be fixed to handle this
+++ b/dlls/ntdll/misc.c
in NTSTATUS NTOSKRNL_connect(HANDLE *device_handle)
+ntoskrnl_started = TRUE;
+sleep(3);
+continue;
Waiting for something, reason unknown without a comment.
Is it here to force a shedule / taskswitch?
+++ b/programs/ntoskrnl/ntoskrnl.c
in static NTSTATUS driver_control(void)
+/* Call DispatchDeviceContorl and return */
Typo: DispatchDeviceControl
+++ b/programs/ntoskrnl/ntoskrnl_api.c
+ *ExLocalTimeToSystemTime [EMAIL PROTECTED]
Copy & Paste - Typo: [EMAIL PROTECTED]
+++ b/programs/ntoskrnl/ntoskrnl_api.c
+LPCSTR wine_dbgstr_us( const UNICODE_STRING *us )
This is also in "dlls/ntdll/misc.c"
Is it useful to add "debugstr_us" to "include/wine/debug.h"?
+++ b/server/device.c
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
This old Address slipped through
+++ b/server/object.h
@@ -45,6 +45,7 @@ struct async;
+struct semaphor;
Did you mean "struct semaphore;" here?
--
By By ...
... Detlef
Re: [Wine] Re: wine-0.9.15 & winetools problems.
Rick Romero wrote: 12. wine ie6setup.exe 13. Error. "The download location information is damaged" WTF? This error message happens on Windows 98 too. I suggest that you complain to Microsoft. -- Rob Shearman
Re: wined3d: GLSL Patch feedback requested
On Tuesday 13 June 2006 18:39, Jason Green wrote: > On 6/13/06, H. Verbeet <[EMAIL PROTECTED]> wrote: > > On 13/06/06, Raphael <[EMAIL PROTECTED]> wrote: > > > I only have one question: > > > i see you have a cache to reuse prgid in set_glsl_shader_program but > > > what happens if user/app change the shaders content (for example using > > > SetFunction) ? your pre-compiled program will be correct ? > > > (because i don't see any list cleanup in shaders function reset) > > > > Good point :-) > > I wonder if respecifying the source and recompiling the program is > > worth it, or if we should just create a new shader object. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c >/IDirect3DPixelShader9.asp > > >From what I can tell (for DX9 at least), the app shouldn't be able to > > use SetFunction(). I thought it was an internal wined3d function. > Unless it's a DX8 call that I'm unaware of. I haven't seen any apps > try to do that yet, but maybe I'm just not looking closely enough. > > :-) The apps tend to CreatePixelShader(), then later [often during > > the render loop], they SetPixelShader(). I haven't seen any that > modify an existing shader yet. No seems correct to me (from DX8-9 APIs) but never say never :) Anyway cleaning glprograms on Delete can be a good idea :) And we must think, for futur, about the ressources manager (was last oliver works). As in some cases the CG will not be able to contains all precompiled shaders couples, and we must swap them on need ;) Best Regards and thx to you two, Raphael pgprt8voNzH1B.pgp Description: PGP signature
Re: WINED3D: Bug 5418
On Tuesday 13 June 2006 09:21, H. Verbeet wrote: > http://bugs.winehq.org/show_bug.cgi?id=5418 > > The code in question does look a bit dodgy. Bad merge perhaps? Yes Seems bad merge Raphael pgp6DPsEEn5U5.pgp Description: PGP signature
Re: [Wine] Re: wine-0.9.15 & winetools problems.
On Tue, 2006-06-13 at 21:47 +0200, Peter Åstrand wrote: > On Tue, 13 Jun 2006, Jonathan Ernst wrote: > > > BTW, as I used to maintain this entry, > > If you consider yourself an inactive maintainer, perhaps you should let > someone else takeover? > > > > I updated it with current > > informations. I don't have time to test the runtime settings so I'd be > > glad if you could fill the missing part and send me the details so I'll > > update the entry http://appdb.winehq.org/appview.php?versionId=469 > > Thanks for the update. A few comments: > > * I think the reference to WineTools and Sidenet should be removed. Wine > version 20050725 is quite old. I think we should focus on having the > latest AppDb pages document the latest Wine, rather than old stuff. > > * The manual installation still doesn't work for me (see bug 5409 etc), > but let's get back to that. > > * I think it would be nice if you could include my command lines for > fetching & extracting inseng.dll, for those users without a Windows > installation nearby: > > $ wget > http://download.microsoft.com/download/ie6sp1/finrel/6_sp1/W98NT42KMeXP/EN-US/IE_S5.CAB > $ cabextract -L IE_S5.CAB > $ cabextract -L -F inseng.dll ie_5.cab > $ rm -rf ~/.wine ie_5.cab IE_S5.CAB > $ wineprefixcreate > $ cp inseng.dll ~/.wine/drive_c/windows/system32/ > $ wget > http://download.microsoft.com/download/ie6sp1/finrel/6_sp1/W98NT42KMeXP/EN-US/ie6setup.exe > $ wine ie6setup.exe > Interestingly I _JUST_ decided to go through this myself on a raw wine install of .9.15 So I did the following (Some relate this Subject, some just FYI): 1. Ok, RPM installed. Now what? I need IE. 2. run winecfg, create new Wine install. (Icon says 'Add Application', thought it was for installing applications :/ ) Exit. 2. Read Install/Config HowTo http://www.winehq.org/site/howto 3. Follow link to appdb 4. type 'Internet Explorer' in search 5. Click Internet Explorer link 6. Click 6.0 7. Look confused for a moment, then scroll down far enough to see there's a HOWTO with a dark green background that's hard to see in Opera. 8. 'Install dll?' Screw that, follow link to IE6 at MS. 9. Download IE6SP1 ie6setup.exe 500k. 10. wine ie6setup.exe 11. Error. Go back to Appdb, get dll from link at dlldump.com 12. wine ie6setup.exe 13. Error. "The download location information is damaged" WTF? 14. Ok, maybe I should choose custom install.. Did I get the option? wine ie6setup.exe No options, installs complete. 15. wine IEXPLORE.EXE White Page. Not good. 16. Search for 'Could not load Mozilla' 17. Install ActiveX Control and learn it's re-written and not done yet. So I did all this to test some 'web' VoiceChat, http://www.univoice.us/demo/ that installs from a cab file through IE. Is this functionality lost with this migration from IE to internal rendering? Rick > Regards, > ___ > wine-users mailing list > [EMAIL PROTECTED] > http://www.winehq.org/mailman/listinfo/wine-users
Re: [Bug 5409] ie6setup fails with "The download location information is damaged"
On Tue, 13 Jun 2006, Wine Bugs wrote: http://bugs.winehq.org/show_bug.cgi?id=5409 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Since you obviously doesn't believe this is a bug, let's take this discussion on the devel list, instead of ping-ponging between RESOLVED/REOPENED. --- Additional Comments From [EMAIL PROTECTED] 2006-13-06 03:21 --- Either way, the bug is: wine does not provide inseng.dll, which ie6setup.exe requires. You don't need to tell me that over and over; I did understand the first time. But again, I *have* installed inseng.dll. I've tried the same version that comes with the IE download package. I've tried the version from Windows XP. I've tried the version from Windows 2000. I've also registered the DLL with: $ wine regsvr32 inseng.dll which gave me: "Successfully registered DLL inseng.dll" So I have a hard time believing that inseng.dll is the cause of my problems. If you're having problems with native dlls, that's not wine's bug. Strange comment. Marking as a duplicate, but it really should be invalid, worksforme, etc. If you don't think this is a duplicate, why mark it as that? *** This bug has been marked as a duplicate of 1293 *** I don't believe this is a duplicate of 1293. A comment on that bug says, which you have written yourself, says: "ie6setup.exe claims that it can't download the setup files because inseng.dll is not registered." Again, it doesn't look like this is my problem. Also, the error message is different. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Re: Broken FC5 packages - stay clear.
n0dalus wrote: > I think that person should really be you :). Your preconceptions about > how things should be packaged is a bit outdated. > > A few years ago there used to be monolithic packages well over 100MB > that every time something small was changed the whole lot needed to be > updated. Splitting up packages is a good thing. It means less install > size, less bandwidth used and easier updates. The packages should have Dream on! As long as all those subpackages are generated from the same SRPM you will save nothing and get all of them if the SRPM changes. Could be seen very nicely with X where a stoneage small program had a security bug and the _whole_ X was upgraded including the font files. And yes, X was already split in subpackages. Now that's fixed with the modular xorg but that's *not* an achievement of the packagers but of the upstream project. Where subpackes help is to limit the amount of requirements the program has. That's highly used on heavy customized servers and less so on the desktop. I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it. > meaningful descriptions, and should depend on each other in a way that > means you just choose what you want and the package manager will get > what you need. Some time in the future (or already) the package > manager may make the distinction between required packages, suggested > packages and enhancement packages, making it easier for users like > yourself to work out what they want. I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it. 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
Re: Broken FC5 packages - stay clear.
On Tuesday 13 June 2006 16:19, Brian Vincent wrote: > "This package contains special color management for use with Wine by > integrating with LittleCMS. Most users will never need to even think > of downloading this package. If you're doing high-end graphics work > using a commercial Windows package, you might want to consider using > it." That was true a couple of years ago maybe, we now live in the age of digital cameras. I've seen it being used by a simple photoalbum app. Secondly, this dll is shipped since Window 98, so many apps that use it don't check for it's presence, which results in, well, needless pain. Lastly, this dll is just over 100k stripped, wldap32 is 280k. Given the risks mentioned above, is it really worth it to save such amounts of disk space? -Hans
Re: Broken FC5 packages - stay clear.
On 6/14/06, Brian Vincent <[EMAIL PROTECTED]> wrote: Just a quick example. Let's say I want to install Samba. I've used Samba a lot, it's saved my butt more times than I can count. However, the packaging is a complete disaster and even as a knowledgable user I have no clue what's going on. Looking at rpmfind.net I see Samba has the following packages available: I am guessing that the list you got were rpms from various different distros, each with their own naming conventions. So there's going to be a lot of overlap. samba (Um, I guess I'd need that.) samba-client (Well, that can be useful..) samba-server (Uh.. wait.. why isn't that part of Samba. That's what I need.) samba-common (Whoa.. if it's so important, why isn't it part of samba?) samba-winbind (Well, I may or may not need that, but it's small so I better download it.) samba-vfs (Um.. I know what Samba is, I know what vfs is. Do I need it? No clue. Better download it.) samba-pdb (No clue what this is. Maybe I won't download it. But what does it do? Anything important?) samba-python (Gee.. I like python. Maybe I should download it.) And that's just the tip of the iceberg (samba-console? samba-vscan? samba-vfs-fake_perms?) Taking a _single_ distro, like Fedora Core 5, this is what we see: samba (just the server) samba-client (just the client, for people who don't need the server) samba-common (files shared by both, -common packages shouldn't concern anyone since they get pulled in by whatever packages are chosen) It's simple; it allows people to save space by not having everything and it allows updates to individual parts so you don't need to download the whole lot when something changes. Anyway, it's such a god awful mess that someone deserves to be taken into a backroom and have all knowledge of building RPM's erased from their head. I think that person should really be you :). Your preconceptions about how things should be packaged is a bit outdated. A few years ago there used to be monolithic packages well over 100MB that every time something small was changed the whole lot needed to be updated. Splitting up packages is a good thing. It means less install size, less bandwidth used and easier updates. The packages should have meaningful descriptions, and should depend on each other in a way that means you just choose what you want and the package manager will get what you need. Some time in the future (or already) the package manager may make the distinction between required packages, suggested packages and enhancement packages, making it easier for users like yourself to work out what they want. n0dalus.
Re: wined3d: GLSL Patch feedback requested
On 13/06/06, Jason Green <[EMAIL PROTECTED]> wrote: From what I can tell (for DX9 at least), the app shouldn't be able to use SetFunction(). You're right.
Re: Broken FC5 packages - stay clear.
On 6/13/06, n0dalus <[EMAIL PROTECTED]> wrote: I think that most users would just install 'wine' and use it. I don't think it's common for people to get confused over which of all the packages they should install. Yeah, it is confusing. Just a quick example. Let's say I want to install Samba. I've used Samba a lot, it's saved my butt more times than I can count. However, the packaging is a complete disaster and even as a knowledgable user I have no clue what's going on. Looking at rpmfind.net I see Samba has the following packages available: samba (Um, I guess I'd need that.) samba-client (Well, that can be useful..) samba-server (Uh.. wait.. why isn't that part of Samba. That's what I need.) samba-common (Whoa.. if it's so important, why isn't it part of samba?) samba-winbind (Well, I may or may not need that, but it's small so I better download it.) samba-vfs (Um.. I know what Samba is, I know what vfs is. Do I need it? No clue. Better download it.) samba-pdb (No clue what this is. Maybe I won't download it. But what does it do? Anything important?) samba-python (Gee.. I like python. Maybe I should download it.) And that's just the tip of the iceberg (samba-console? samba-vscan? samba-vfs-fake_perms?) Anyway, it's such a god awful mess that someone deserves to be taken into a backroom and have all knowledge of building RPM's erased from their head. That's exactly what Wine shouldn't become. But who knows, maybe that's good for sys admins who keep up to date with the latest minor versions of every piece of software out there. Wine is an end-user utility who's installation and usage instructions should be: Install Wine package -> Run program with Wine -> Magic happens -> Use program. -Brian
Re: riched20 patch
On 6/12/06, Clinton Stimpson <[EMAIL PROTECTED]> wrote: Second attempt (seems my last one email with this patch dropped through the cracks ??): Attached is a patch to fix a crash when EM_SETTEXTEX is called with a NULL lParam. Return values and behavior has been verified and found equivalent to an app on Windows. This will have a much better chance getting accepted if you provide a test case for this behavior. -- James Hawkins
Re: wined3d: GLSL Patch feedback requested
On 6/13/06, H. Verbeet <[EMAIL PROTECTED]> wrote: On 13/06/06, Raphael <[EMAIL PROTECTED]> wrote: > I only have one question: > i see you have a cache to reuse prgid in set_glsl_shader_program but what > happens if user/app change the shaders content (for example using > SetFunction) ? your pre-compiled program will be correct ? > (because i don't see any list cleanup in shaders function reset) Good point :-) I wonder if respecifying the source and recompiling the program is worth it, or if we should just create a new shader object. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/IDirect3DPixelShader9.asp From what I can tell (for DX9 at least), the app shouldn't be able to use SetFunction(). I thought it was an internal wined3d function. Unless it's a DX8 call that I'm unaware of. I haven't seen any apps try to do that yet, but maybe I'm just not looking closely enough. :-) The apps tend to CreatePixelShader(), then later [often during the render loop], they SetPixelShader(). I haven't seen any that modify an existing shader yet.
Re: wine XShm problem on remote display
Am Dienstag, den 13.06.2006, 16:22 +0200 schrieb Alexandre Julliard: > Benjamin Fabricius <[EMAIL PROTECTED]> writes: > > > vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll > > yo... lets see... > > The program 'fst.exe.so' received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadAccess (attempt to access private resource denied)'. > > (Details: serial 114 error_code 10 request_code 144 minor_code 1) > > (Note to programmers: normally, X errors are reported asynchronously; > >that is, you will receive the error a while after causing it. > >To debug your program, run it with the --sync command line > >option to change this behavior. You can then get a meaningful > >backtrace from your debugger if you break on the gdk_x_error() > > function.) > > Wine will handle that error properly, but here it sounds like fst (or > more likely Gtk) has replaced the Wine error handler with its own, so > Wine doesn't get a chance to handle it. > thanks for the hint, isn't there a possibility in wine to turn of the use of the xshm extension globally? i read that there used to be wine.conf with [x11drv] .. ; Use XFree86 DGA extension if present UseDGA = Y ; Use XShm extension if present UseXShm = Y .. is there a mechanism to do this in my wine version (20050725) or current builds? or do you see a way different way to workaround this, i. e. to write an own error handler. i'm not to deep into the x matter though... thanks again bf -- --- Benjamin Fabricius German Student Lawo AG
Re: [Setuapi] implement SetupDiCreateDeviceInfoListExW
Hi Christian, thanks for working on setupapi, it could use some help. Huw
already commnented on your patch, I have a couple more:
+if (!list) {
+goto cleanup;
+}
The style in this file has opening braces on lines of their own, e.g.:
if (hInf == INVALID_HANDLE_VALUE)
{
return FALSE;
}
Please stick with that.
+if (MachineName != NULL) {
You should probably just fail if the machine name isn't NULL, since you
don't use it and you don't connect to a remote machine anyway.
--Juan
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Wine's Mozilla Control - Very old
For any it might concern! The Mozilla ActiveX Control recommended for download by Wine is based on a pre FireFox 1.0 gecko engine and is missing support for many web standards! I was doing development in Windows and needed an Embedded browser. I wanted to also support Mozilla engine and was Quickly downloading the ActiveX from wine download page. (My installed FireFox does not supply one). My work involved embedding the FCKEditor (http://FCKEditor.sourceforge.net). So I installed and change the source code to use the Mozilla GUID and oops FCKEditor does not work. After some investigation I found that even though the Control's package is from Q4/2005 the engine included is much older and belongs to Mozilla 1.6 or something. Since then the Mozilla package did not include a new Control and Has eventually stopped been released. (Do to FireFox replacing it). The New (Mozilla 1.8) Control can only be found in the new SeaMonkey 1.0.x package, which is what I got. And with this control every thing works grate. (Even better than IE). Now SeaMonkey (http://www.mozilla.org/projects/seamonkey) is a very large package and is not something a user would be Happy to be forced with. I did Package a one time Installation of the new Control, stripping down from SeaMonkey anything I could guess does not belong. But this is a one time Job and I'm not sure is the right solution. Maybe we should contact the Sea-Monkey maintainers and ask them to Also produce an "on the side" extra package for our sake. I have not done that yet ... Any body in contact with Mozilla.org? Free Life Boaz
Martin Fuchs : shell32: SHELL32_GetItemAttributes()
hi, Like many wine users, I'm having trouble with programs calling the GetFolderAttributes... I've seen your patches and was wondering if it would be possible to download the pre-patched DLLs from somewhere. I'm running wine 0.9.15 and am surprised that the problem continues since the patch is so old... Thanks for your help, Rick Opper
Re: Broken FC5 packages - stay clear.
Andreas Bierfert wrote: On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn <[EMAIL PROTECTED]> wrote: On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or It does know about this (don't quite remember the version it was introduced with but it allows for that now). simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras. missing the features will be disabled at runtime usually with a message on stderr. Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly... The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) Looking over to debian and thinking about the stuff that is installed by 'make install' got me to the layout I have now... I don't say its perfect... it never was and it probably never will be... that is why I like input from upstream... I am the packager not the guy who did all the work on wine but I am the packager and I know what is needed/wanted/regulated on the fedora side of the story. Together with your input I am more than happy to change things around, just need people upstream who are willing to listen and talk to packagers and I hope in this case it will work. On thing I could offer which probably makes sense anyway is to mention sub packages in the description or in a README-Fedora. wine-tools and does not install it? They will be missing: * winecmd * notepad * winedbg * winepath * winhelp * _EXPLORER_ These may appear to to be optional but they are not. Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure. Ok, will move explorer to the main wine package. Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously. hm then maybe stuff should be merged to the main wine package for the stuff mentioned above... will look into it and if you have further input and suggestions rest assured that they are always welcome. Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it? Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have no problem with that and I stand for what I do. Maybe just maybe try to see the packager/distro side of things and you will see that what Vincent did was great work and is for certain things but for what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community... if you don't like it fine... ignore it, ignore me... but I'd rather work together with you and the wine team on improving the wine experience for users and not fighting here wasting time that could be better spent improving the user situation. - Andreas Well I found it frustrating the way it is packaged. I just deleted all the FC5 wine stuff and downloaded it from winehq. It is a shame you don't get the all the things you need without having to install 10 packages. My $.02, Steve Clark -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Re: Broken FC5 packages - stay clear.
On 6/13/06, Brian Vincent <[EMAIL PROTECTED]> wrote: 1. Put wine and wine-tools together. Call it 'wine' Or make wine require wine-tools. There's nothing wrong with splitting up packages, but any recommended combinations should be linked by requires until rpm/yum starts supporting tags like 'Enhances' and 'Suggests'. 3. Combine wine-debuginfo with wine-devel and call it wine-devel. They're both necessary for development, right? Debuginfo is built automatically by rpmbuild and can't joined to the devel package. The debuginfo package is only needed for debugging, whereas (I think) the -devel package is used for things like making winelib apps. All packages in Fedora are like that, and developers are used to that now. I think that most users would just install 'wine' and use it. I don't think it's common for people to get confused over which of all the packages they should install. Unless they know already that they need something non-standard, anything not required by the base package is probably something they won't need. n0dalus.
Re: Crash in XOpenIM in wine 0.9.15
On Tue, Jun 13, 2006 at 03:32:03PM +0200, Daniel Skorka wrote: > Any time a process in wine tries to execute another process, wine will > crash following a call to XOpenIM. For details please look here [1]. > [1] http://www.winehq.org/pipermail/wine-users/2006-June/021973.html Check if any X input server is installed (like what is used to input Japanese with e.g. a US keyboard). In the past I experienced crashes with various X apps (thu not with Wine) because of SCIM. (No idea if the XIM-server or Wine is at fault in this case.) Jan
One more shot at ntoskrl implementation
Here is last instalment of safedisc support in Wine. The major change from last version is the way user space talks to ntoskrnl. Now I'm passing the information through wineserver with a help of 4 server calls. There are still some areas that require work. I will appreciate any input that you guys might have about any part of this code. It's been on my lap for way too long. It would be really cool to finally get it in. PS: Diffed against 1d40bf0141b7f67b1188555962698f5dab631bc3. Need to run tools/make_reqwests. -- Best regards, Vitaliy origin_sd1.diff.bz2 Description: Binary data
Re: wine XShm problem on remote display
Benjamin Fabricius <[EMAIL PROTECTED]> writes: > vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll > yo... lets see... > The program 'fst.exe.so' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadAccess (attempt to access private resource denied)'. > (Details: serial 114 error_code 10 request_code 144 minor_code 1) > (Note to programmers: normally, X errors are reported asynchronously; >that is, you will receive the error a while after causing it. >To debug your program, run it with the --sync command line >option to change this behavior. You can then get a meaningful >backtrace from your debugger if you break on the gdk_x_error() > function.) Wine will handle that error properly, but here it sounds like fst (or more likely Gtk) has replaced the Wine error handler with its own, so Wine doesn't get a chance to handle it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Broken FC5 packages - stay clear.
On 6/13/06, Andreas Bierfert <[EMAIL PROTECTED]> wrote: Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) First off, thank you very much for building the FC packages. It was something we were sorely lacking for months and it's a thankless job. So, thanks. I'd disagree about the 'splitting stuff makes users happy'. As a long time RH user and former sys admin, I hate it. It's one of the reasons I used to dislike Debian, although apt is very good at hiding dependencies. The last thing I want to do when I go to download a piece of software is to figure out which of the 50 million packages I need. In the end I usually download them all and try to install them. It's frustrating. As others mentioned, the tools package really needs to be included. I understand why you split the other stuff out, so maybe we need to do something like this: 1. Put wine and wine-tools together. Call it 'wine' 2. Not include wine-nas or wine-jack. Aren't they both currently broken? For that matter, I think I heard wine-arts is as well. 3. Combine wine-debuginfo with wine-devel and call it wine-devel. They're both necessary for development, right? The rest of the packages won't be necessary for 99% of users. Can we just tell them that in the description of the RPM? For example, for wine-cms: "This package contains special color management for use with Wine by integrating with LittleCMS. Most users will never need to even think of downloading this package. If you're doing high-end graphics work using a commercial Windows package, you might want to consider using it." Maybe you already do, I didn't download them and look. So, perhaps the package names should even reflect that. Instead of "wine-ldap", call it "wine-extras-ldap". That'd probably be enough for me to figure out what I needed. By the way, the whole Gecko integration Jacek is doing seems like something packagers should tackle with Wine. It'd be nice if someone could come up with a contained Windows Gecko package that could be included with the basic Wine package. -Brian
Re: wine XShm problem on remote display
"Benjamin Fabricius" <[EMAIL PROTECTED]> wrote: I am working on a vst (audio-plugin-)server with embedded linux. Everything is up and running in a testing phase. Unfortunately i am experiencing difficulties, that i think could derive from wine. First of all my setup vst:/opt/fst # uname -a; wine --version Linux vst 2.6.15 #21 PREEMPT Thu Mar 30 22:11:02 CEST 2006 i686 unknown Wine 20050725 [skipped] so attaching a shared memory pixmap appears to be causing the trouble. Now I`m not sure yet if a wine or fst function is causing the trouble. It could derive from some Gtk call... Isn't it problematic to use the shared memory extension when working on a remote display? Please try more current Wine version, very likely the problem was already fixed. -- Dmitry.
Re: [Setuapi] implement SetupDiCreateDeviceInfoListExW
On Tue, Jun 13, 2006 at 03:42:22PM +0200, Christian Gmeiner wrote:
> diff --git a/dlls/setupapi/devinst.c b/dlls/setupapi/devinst.c
> index f402f00..c24ae1e 100644
> --- a/dlls/setupapi/devinst.c
> +++ b/dlls/setupapi/devinst.c
> HDEVINFO WINAPI
> -SetupDiCreateDeviceInfoListExW(const GUID *ClassGuid,
> -HWND hwndParent,
> -PCWSTR MachineName,
> -PVOID Reserved)
> +SetupDiCreateDeviceInfoListExW(
> +const GUID *ClassGuid,
> +HWND hwndParent,
> +PCWSTR MachineName,
> +PVOID Reserved)
Please avoid these unnecessary whitespace changes, they just make the
patch bigger.
> diff --git a/dlls/setupapi/setupapi_private.h
> b/dlls/setupapi/setupapi_private.h
> index bce05cb..77e4fb0 100644
> --- a/dlls/setupapi/setupapi_private.h
> +++ b/dlls/setupapi/setupapi_private.h
> +struct DeviceInfoSet
> +{
> +DWORD magic;/* if is equal to SETUP_DEVICE_INFO_SET_MAGIC struct
> is okay */
> +GUID ClassGuid;
> +PWSTR MachineName;
> +HWND hwndParent;
> +};
> +
Is this struct going to be used by functions outside devinst.c? If
not then this should be moved into that file.
Also please include a test with your patch and, in this case, I think
it makes sense to include the appropiate Destroy function too, that
way it's easy to check that you haven't introduced a memory leak.
Thanks,
Huw.
--
Huw Davies
[EMAIL PROTECTED]
wine XShm problem on remote display
Hello all, I am working on a vst (audio-plugin-)server with embedded linux. Everything is up and running in a testing phase. Unfortunately i am experiencing difficulties, that i think could derive from wine. First of all my setup vst:/opt/fst # uname -a; wine --version Linux vst 2.6.15 #21 PREEMPT Thu Mar 30 22:11:02 CEST 2006 i686 unknown Wine 20050725 Also i am using FreeST which is a binary in order to mount and maintain the vst plugins. The server runs as a x client and my development laptop as x server. This setup works satisfactory i can display any graphical windows on my laptop including wine loaded windows executables. now though, when loading certain plugins on the server (x client) (these all work fine on my local development host) i get a weird x server fault 8<8<8<8<8<8<8< vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll yo... lets see... The program 'fst.exe.so' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAccess (attempt to access private resource denied)'. (Details: serial 114 error_code 10 request_code 144 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) 8<8<8<8<8<8<8< An xdpyinfo on my xserver gives me [EMAIL PROTECTED]:~> xdpyinfo -queryExt | grep 144 MIT-SHM (opcode: 144, base event: 94, base error: 166) So the MIT-SHM extension seems to be the source of the trouble. looking into the MIT-SHM extension headers gives me the minor opcode: [EMAIL PROTECTED]:/usr/include/X11/extensions> less XShm.h ... #define X_ShmQueryVersion 0 #define X_ShmAttach 1 #define X_ShmDetach 2 #define X_ShmPutImage 3 #define X_ShmGetImage 4 #define X_ShmCreatePixmap 5 ... so attaching a shared memory pixmap appears to be causing the trouble. Now I`m not sure yet if a wine or fst function is causing the trouble. It could derive from some Gtk call... Isn't it problematic to use the shared memory extension when working on a remote display? Now some google entries tell me one must have been able to disable wine using xshm in /etc/wine.conf for example. Is this still so because i can not find any config file allowing this in my distro. And using winecfg didn't really deliver results either. My handicap is my lack of profound knowledge in wine and x matters. Maybe you guys now some work around or can imagine what could be causing all the havoc here... Any help would be great... thank for your time, Cheers, bf -- --- Benjamin Fabricius German Student Lawo AG
Crash in XOpenIM in wine 0.9.15
Hello, I want to bring an issue that has appeared on wine-users to your attention. The issue is basically this: Any time a process in wine tries to execute another process, wine will crash following a call to XOpenIM. For details please look here [1]. I'm sure Leigh is willing to provide any additional info required. regards, Daniel [1] http://www.winehq.org/pipermail/wine-users/2006-June/021973.html
Re: What is needed to get more sites with a winetest executable
On Tue, 2006-06-13 at 06:57 -0600, Andrew Ziem wrote: > Paul Vriens wrote: > >> Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: > >>> Hi, > >>> > >>> in the last months we've experienced several times that there was no > > winetest.exe available at the usual location > >>> (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several > > days/weeks. The reasons are sometimes known but in any case it's a > > Single Point Of Failure. > >>> What will it take to have multiple sites generating and hosting the > > winetest executable? Or do we already have this? > >>> Cheers, > >>> > >>> Paul. > >> Hi, > >> > >> not the answer to your question, but some thoughts about the topic. > >> > >> As long as the automatic build of Paul Millar works, there is not reason to > >> have a second winetest binary for nearly the same git/cvs source of the > > tests. One binary a day is enough. If you check > >> http://test.winehq.org/data/ > >> you will see that we miss often tests results for some windows platforms. > >> > >> If building the winetest binary fails. Someone needs to look into the > > reason > >> anyway. In almost all cases its a missing import in a library the test > > ist linked against. So first "our mingw environment" needs to be fixed. > > Just running another automatic build will fail with the same error as > > the build of > >> Paul. > >> > >> Its not hard for me to do the manual build. I just need some webspace to > > put > >> the stuff on. And i need to know what needs to be modified in the source > > before the build (somehow the build date need to be patched into the > > source). > >> Also the question is how the new build is announce to the public (hope that > >> it si not the case that it appears on astro.gla.ac.uk). > >> > > > > exactly my point. I know Paul Millar fixes stuff all the time by patches > > of you I think and Hans Leidekker (and others). But he is only one person, > > with of course a limited amount of time. > > > > Maybe we should have a few sites generating the winebuild and using a > > different path to publish stuff at test.winehq.org/data/[site]. We don't > > want to mix the output of different executables in one view (apples and > > pears). > > There are a limited number of winetest reports, but it's nice to be able > to see how a single test operates on a variety of systems. However, > having separate sites would fragment the reports. > > How about integrating all of winetest into winehq.org where there is a > primary maintainer and one or more backup maintainers? > > > Andrew > I wasn't talking about splitting the output. It was more like having a separate branch for every winetest-origin. Paul
Re: msvcrt[1/2]: add initial tests for dlls/msvcrt/data.c
Alexandre Julliard wrote: Andrew Ziem <[EMAIL PROTECTED]> writes: +typedef void (*_INITTERMFUN)(void); +unsigned int (WINAPI *p_initterm)(_INITTERMFUN *,_INITTERMFUN *); Msvcrt functions are not WINAPI. And why don't you simply call the function directly instead of loading it dynamically? I found the second problem. To avoid warning implicit declaration of function ‘_initterm’ when compiling the test data.c, where should _initterm be declared? In a new dlls/msvcrt/data.h? Andrew
Re: What is needed to get more sites with a winetest executable
Paul Vriens wrote: Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: Hi, in the last months we've experienced several times that there was no winetest.exe available at the usual location (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several days/weeks. The reasons are sometimes known but in any case it's a Single Point Of Failure. What will it take to have multiple sites generating and hosting the winetest executable? Or do we already have this? Cheers, Paul. Hi, not the answer to your question, but some thoughts about the topic. As long as the automatic build of Paul Millar works, there is not reason to have a second winetest binary for nearly the same git/cvs source of the tests. One binary a day is enough. If you check http://test.winehq.org/data/ you will see that we miss often tests results for some windows platforms. If building the winetest binary fails. Someone needs to look into the reason anyway. In almost all cases its a missing import in a library the test ist linked against. So first "our mingw environment" needs to be fixed. Just running another automatic build will fail with the same error as the build of Paul. Its not hard for me to do the manual build. I just need some webspace to put the stuff on. And i need to know what needs to be modified in the source before the build (somehow the build date need to be patched into the source). Also the question is how the new build is announce to the public (hope that it si not the case that it appears on astro.gla.ac.uk). exactly my point. I know Paul Millar fixes stuff all the time by patches of you I think and Hans Leidekker (and others). But he is only one person, with of course a limited amount of time. Maybe we should have a few sites generating the winebuild and using a different path to publish stuff at test.winehq.org/data/[site]. We don't want to mix the output of different executables in one view (apples and pears). There are a limited number of winetest reports, but it's nice to be able to see how a single test operates on a variety of systems. However, having separate sites would fragment the reports. How about integrating all of winetest into winehq.org where there is a primary maintainer and one or more backup maintainers? Andrew
Re: Broken FC5 packages - stay clear.
Tuesday, June 13, 2006, 1:14:00 AM, Andreas Bierfert wrote: > On Mon, 12 Jun 2006 15:31:12 +0100 > Mike Hearn <[EMAIL PROTECTED]> wrote: >> On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: >> > Well from a wine perspective I see that this makes sense, but if you take a >> > look at all the dependencies it is another story... >> >> simply to not mark them as dependencies at all yet still build the >> package with those features enabled. If the supporting libraries are > This is just wrong packaging. Sorry if this sounds harsh but that cannot be > the > solution and it never will be in Fedora Extras. And why isn't that a solution? That's what Wine already _does_. So what is the problem on your end? Just a principle? >> missing the features will be disabled at runtime usually with a message on >> stderr. > Don't get me wrong... I am really happy that in the near future (1-2 years) > rpm and yum support for optional dependencies will be spread enough so it > solves a lot of issues like this one and I am really happy to make use > of it... but for now this is not an option, sadly... Obviously you have never monitored this mailing list, looked at the source, bothered reading documentation. But that has nothing to do with rpm/deb/etc. That the the way Wine is made. It is built with few hard requirements. Most are soft requirements. >> wine-tools and does not install it? They will be missing: >> >> * winecmd >> * notepad >> * winedbg >> * winepath >> * winhelp >> * _EXPLORER_ >> >> These may appear to to be optional but they are not. >> >> Explorer is needed for shell integration, HAL support and system tray >> support. It is not an end user tool, it's a part of the Wine >> infrastructure. > Ok, will move explorer to the main wine package. You totally missed the point. You have to include _all_. Otherwise one part of Wine or another will brake. That's the main reason why I said that these packages are broken and that anyone reading this list should stay away from them. The only parts that you can possibly split are sound drivers, headers and debug package. Vitaliy
Re: What is needed to get more sites with a winetest executable
> Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: >> Hi, >> >> in the last months we've experienced several times that there was no winetest.exe available at the usual location >> (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several days/weeks. The reasons are sometimes known but in any case it's a Single Point Of Failure. >> >> What will it take to have multiple sites generating and hosting the winetest executable? Or do we already have this? >> >> Cheers, >> >> Paul. > Hi, > > not the answer to your question, but some thoughts about the topic. > > As long as the automatic build of Paul Millar works, there is not reason to > have a second winetest binary for nearly the same git/cvs source of the tests. One binary a day is enough. If you check > http://test.winehq.org/data/ > you will see that we miss often tests results for some windows platforms. > > If building the winetest binary fails. Someone needs to look into the reason > anyway. In almost all cases its a missing import in a library the test ist linked against. So first "our mingw environment" needs to be fixed. Just running another automatic build will fail with the same error as the build of > Paul. > > Its not hard for me to do the manual build. I just need some webspace to put > the stuff on. And i need to know what needs to be modified in the source before the build (somehow the build date need to be patched into the source). > Also the question is how the new build is announce to the public (hope that > it si not the case that it appears on astro.gla.ac.uk). > > Bye Stefan > Hi, exactly my point. I know Paul Millar fixes stuff all the time by patches of you I think and Hans Leidekker (and others). But he is only one person, with of course a limited amount of time. Maybe we should have a few sites generating the winebuild and using a different path to publish stuff at test.winehq.org/data/[site]. We don't want to mix the output of different executables in one view (apples and pears). Another thing what we could is just use a well-known-url for the winetest.exe like we did with the Mozilla ActiveX component. This url should of course point to the latest available on all site (don't know if that's feasible). Cheers, Paul.
Re: Vertex Buffer Objects for WineD3D
> It will be better to move VBO creation and binding on vertexbuffer.c. (its > why GetMemory didn't provide VBO id before, no need for that) > Have you planned to use ti for index buffers too ? That was my first idea(just bind the vertex buffer in GetMemory and return the offset), but the problem is that dx apps may split vertices on multiple buffers. They may store the position in buffer 1 and the colors of vertices in buffer 2. GetMemory is called when the FVF or declaration is converted into strided data. The strided data contains pointers to the vertex data which may come from many different VBs. I have to bind the VBO the data is stored in when I pass the data pointer to gl in LoadVertexArrays. This is perfectly ok for GL(and not a performance issue), but I need the VBO number in the strided data to know where each data comes from. > > The vertex conversion is slow, and it turned out that if the app Locks > > the Buffer every frame then drawStridedSlow is faster Converting + > > drawStridedSlow. Because of that VBOs and the conversion aren't used for > > vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not > > loaded into a vbo. > > For that problem i had a prototype who remembered too many lock (in small > times) and active the no-VBO flag :) I considered the same thing, considering that the app may be bad-behaved and set bad flags. Remembering the application's behavior seemed to be better. However, I noticed that even well behaved apps(e.g. battlefield 1942) don't keep all the geometry they use in a map in vertex buffers at all time. Instead they load the area around the player, and load new stuff and throw away the old while the player moves through the map. As a result wined3d gets a bunch of IWineD3DVertexBuffer::Lock calls sporadically. Depending on the behavior of the player that is different. E.g. if a sniper stays at one place all the time there isn't much reload, but if he's flying a plane there is constantly new data. I couldn't think of any good heurisitics which could detect all that stuff, so I decided to rely on the flags set by the app. After all, the application developers know best what happens, and D3D8 and D3D9 apps are quite well-behaved compared to DDraw / D3D7 apps. (Even if we can find a good way to handle the bf1942 and hl2 cases perfectly, who can say if we won't find a game which does something perfectly valid and fools our algorithms) The same problem applies to textures and render targets, btw. For textures it can be solved quite well, render targes are more tricky. Stefan pgpMu3pkhcpgk.pgp Description: PGP signature
Re: What is needed to get more sites with a winetest executable
Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: > Hi, > > in the last months we've experienced several times that there was no > winetest.exe available at the usual location > (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several > days/weeks. The reasons are sometimes known but in any case it's a > Single Point Of Failure. > > What will it take to have multiple sites generating and hosting the > winetest executable? Or do we already have this? > > Cheers, > > Paul. Hi, not the answer to your question, but some thoughts about the topic. As long as the automatic build of Paul Millar works, there is not reason to have a second winetest binary for nearly the same git/cvs source of the tests. One binary a day is enough. If you check http://test.winehq.org/data/ you will see that we miss often tests results for some windows platforms. If building the winetest binary fails. Someone needs to look into the reason anyway. In almost all cases its a missing import in a library the test ist linked against. So first "our mingw environment" needs to be fixed. Just running another automatic build will fail with the same error as the build of Paul. Its not hard for me to do the manual build. I just need some webspace to put the stuff on. And i need to know what needs to be modified in the source before the build (somehow the build date need to be patched into the source). Also the question is how the new build is announce to the public (hope that it si not the case that it appears on astro.gla.ac.uk). Bye Stefan
WINED3D: Bug 5418
http://bugs.winehq.org/show_bug.cgi?id=5418 The code in question does look a bit dodgy. Bad merge perhaps?
Re: wined3d: Another GLSL shader status update
On 13/06/06, Raphael <[EMAIL PROTECTED]> wrote: Well it will not be suficient to begin hacking on wined3d (as only wined3d shaders architecture is explained) The rest is easy ;-)
Re: Broken FC5 packages - stay clear.
On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn <[EMAIL PROTECTED]> wrote: > On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: > > Well from a wine perspective I see that this makes sense, but if you take a > > look at all the dependencies it is another story... > > This is a problem with RPM and not with Wine. If RPM/yum had the concept > of optional dependencies like some other systems do then this would really > not be an issue. A better way to handle this would be to fix RPM, or It does know about this (don't quite remember the version it was introduced with but it allows for that now). > simply to not mark them as dependencies at all yet still build the > package with those features enabled. If the supporting libraries are This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras. > missing the features will be disabled at runtime usually with a message on > stderr. Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly... > The problem here is exactly the same as with Debian. This approach is > just broken and should not be used. What if the user does not know about Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) Looking over to debian and thinking about the stuff that is installed by 'make install' got me to the layout I have now... I don't say its perfect... it never was and it probably never will be... that is why I like input from upstream... I am the packager not the guy who did all the work on wine but I am the packager and I know what is needed/wanted/regulated on the fedora side of the story. Together with your input I am more than happy to change things around, just need people upstream who are willing to listen and talk to packagers and I hope in this case it will work. On thing I could offer which probably makes sense anyway is to mention sub packages in the description or in a README-Fedora. > wine-tools and does not install it? They will be missing: > > * winecmd > * notepad > * winedbg > * winepath > * winhelp > * _EXPLORER_ > > These may appear to to be optional but they are not. > > Explorer is needed for shell integration, HAL support and system tray > support. It is not an end user tool, it's a part of the Wine > infrastructure. Ok, will move explorer to the main wine package. > Winedbg is needed to produce useful crash data for developers. Notepad and > winecmd are sometimes used by installers which will *fail silently* if > they are missing. Winepath is used by various third party scripts. Winhelp > is used by apps for online help, obviously. hm then maybe stuff should be merged to the main wine package for the stuff mentioned above... will look into it and if you have further input and suggestions rest assured that they are always welcome. > Gah. This is just frustrating. The same mistakes are made over and over > and over again. And we are the ones who get to pick up the bugs. What was > wrong with the way Vincent did it? Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have no problem with that and I stand for what I do. Maybe just maybe try to see the packager/distro side of things and you will see that what Vincent did was great work and is for certain things but for what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community... if you don't like it fine... ignore it, ignore me... but I'd rather work together with you and the wine team on improving the wine experience for users and not fighting here wasting time that could be better spent improving the user situation. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB [EMAIL PROTECTED] | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043| mail preferred signature.asc Description: PGP signature
Re: wined3d: GLSL Patch feedback requested
On 13/06/06, Raphael <[EMAIL PROTECTED]> wrote: I only have one question: i see you have a cache to reuse prgid in set_glsl_shader_program but what happens if user/app change the shaders content (for example using SetFunction) ? your pre-compiled program will be correct ? (because i don't see any list cleanup in shaders function reset) Good point :-) I wonder if respecifying the source and recompiling the program is worth it, or if we should just create a new shader object. - It is correct to have GLSL binding code out of "if (useVertexShaderFunction)" block ? It is, actually. If there's no shader in use, we need to tell GL to use fixed function again. The glUseProgramObjectARB call takes care of that. (programId is zero when no shaders are in use).
