Re: Deadline for Summer of Code is March 26th!
On Thursday 22 March 2007 06:49, Dan Kegel wrote: > On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote: > > Watch out, those deadlines can creep up on you! > > If you're a student interested in working on Wine > > as part of Google's Summer of Code, you have > > only five or so more days to apply. See > > > > http://code.google.com/soc > > We still only have a couple applications. Now's your chance > for programming glory - come up with a good idea and apply today! Read that as: Uncle Dan wants YOU for working on Wine! -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpq0YZJLoomU.pgp Description: PGP signature
Re: x11drv: XDND: Fix file drop to properly support file:/// URIs(debugging problem)
Dmitry Timoshkov wrote: -strcpy(((char*)lpDrop)+lpDrop->pFiles, path); +memcpy(((char*)lpDrop)+lpDrop->pFiles, (char*)wpath, fullpathlen * sizeof(WCHAR)); Use lstrcpyW here instead of memcpy. Why? Maciej has already got the length, so why not do the appropriate calculation on fullpathlen and use memcpy? -- Rob Shearman
SoC idea: pressure sensitive tablet support
While looking around for a project idea, I noticed that people are starting to ask for pressure sensitive tablet support in Photoshop on Wine. Seems like it could be a fun project for some Summer of Code student. - Dan
Re: Deadline for Summer of Code is March 26th!
On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote: Watch out, those deadlines can creep up on you! If you're a student interested in working on Wine as part of Google's Summer of Code, you have only five or so more days to apply. See http://code.google.com/soc We still only have a couple applications. Now's your chance for programming glory - come up with a good idea and apply today! - Dan
Re: x11drv: XDND: Fix file drop to properly support file:/// URIs(debugging problem)
Maciej Katafiasz <[EMAIL PROTECTED]> wrote:
+ if(!strncasecmp(p, "://localhost/", 13))
+ {
+ i = 12;
+ } else if (!strncasecmp(p, ":///", 4))
+ {
+ i = 3;
+ } else
+ {
+ TRACE("Not a valid file: URI: %s\n", (char*)data);
+ return count;
+ }
Please use the same indentation style as the existing does, i.e. 4 spaces,
not 2.
+pathlen = MultiByteToWideChar(CP_UNIXCP, 0, filename, len, NULL, 0);
+
+wfn = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, pathlen);
You allocate not enough space for a wide char string.
+TRACE("Convert to WCHAR: filename: %s, len: %d\n", debugstr_a(filename),
pathlen);
+pathlen = MultiByteToWideChar(CP_UNIXCP, 0, filename, len, wfn, pathlen);
+if(GetLastError())
+{
+ TRACE("Can't convert to WCHAR: %d\n", GetLastError());
+ goto clean_wfn;
+}
This is not an appropriate way of testing for an API failure.
+TRACE("WCHAR filename: %s\n", debugstr_w(wfn));
+wpath = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, pathlen *
sizeof(WCHAR));
Memory space calculations and allocations don't look right all over the place.
-strcpy(((char*)lpDrop)+lpDrop->pFiles, path);
+memcpy(((char*)lpDrop)+lpDrop->pFiles, (char*)wpath, fullpathlen *
sizeof(WCHAR));
Use lstrcpyW here instead of memcpy.
--
Dmitry.
Re: automatically running wineprefixcreate
On Wed, Mar 21, 2007 at 12:24:23PM -0500, Tom Spear wrote: > Well, Im just wanting to have winecfg run wineprefixcreate after the > ok and apply buttons are pressed, so that the files and folders > created by wineprefixcreate are created in the location of the fake c > drive (in the event a user moved it from the default).. But then the old location is left behind and the new used instead, what happens when the user already has something installed there? How about a big warning that the user needs to move the content of the directories he changed himself and a pop-up warning on OK if e.g. the windows directory is not found on C: ? Jan
x11drv: XDND: Fix file drop to properly support file:/// URIs (debugging problem)
Hi, (please ignore the other copy I sent from the wrong address by accident) I'm working on a bug in winex11drv/xdnd.c, where file:/// URIs are not correctly interpreted, resulting in DnD broken most of the time. There are two parts of that bug: 1) X11DRV_XDND_BuildDropFiles() fails to properly handle absolute unix paths, which is exactly what you get from file:///, so it won't find the file unless $PWD and the constructed Windows drive-absolute path happen to have the same root. For example, file:///home/mathrick/foo.txt will yield "\\home\\mathrick\\foo.txt" and work only if the current directory is on a drive letter on which that path is valid. 2) X11DRV_XDND_DeconstructTextPlain() fails to accommodate for the fact file:/// URIs are, in fact, URIs and not paths, and doesn't check for validity nor does it unescape % sequences. The result is that paths with spaces, etc. in them won't work. The attached patch is my first take at 1), it works, but there is a problem. My test application is μTorrent, and it'll randomly lock up with the following errors printed: err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001f, blocked by 0019, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001e, blocked by 0019, retrying (60 sec) I can reproduce them by attempting to drop a file on µT's window right after startup. If I wait a while, it works. It also happens if I switch to another virtual desktop, then back to the one µT is on and then try to drop. I tried to check the code as well as I could (win32 API is not exactly my everyday environment), and I believe it's correct. At least all the allocations appear to be correct, nothing is overwritten. I've tried debugging in several ways using winedbg, but it fails pretty hard with various exceptions that aren't there when running outside the debugger, or fails to attach to the process, etc. From the circumstances, I believe there's some kind of race condition in allocation from process heap. However, I'm unable to find it as I have no idea about wine internals and how exactly DnD happens, and what threads do what and when. I'd be therefore very grateful if someone knowledgeable would take a look at it and see what's wrong, or at least help me with debugging the issue, as my ideas how to attack it have run out. Cheers, -- Being really good at C++ is like being really good at using rocks to sharpen sticks. (Thant Tessman) Maciej Katafiasz <[EMAIL PROTECTED]> http://mathrick.org binEvpgzIwfLK.bin Description: application/mbox
Re: Regedit output to STDOUT / force registry files sync
On Di, 2007-03-20 at 21:12 +0100, Vit Hrachovy wrote: > Hi Bill, > that's not the case I'm searching for. I'm aware that regedit can export > into files. I simply want registry export to STDOUT nothing else. Did you test reg.exe / regini.exe ? > I'm going to submit a patch with some sort of new application Please try the above first. Both are from Microsoft. Example: $ wine reg.exe query "HKCU\Software\wine\MSHTML" ! REG.EXE VERSION 3.0 HKEY_CURRENT_USER\Software\wine\MSHTML GeckoUrlREG_SZ http://source.winehq.org/winegecko.php -- By by ... Detlef
Re: Improving DirectDraw OpenGL renderer for SoC?
On Wed, 2007-03-21 at 20:32 +0100, Stefan Dösinger wrote: > The other issue is render target locking. This is essentially something that > is not well supported by OpenGL. There are 2 extensions which can help to > improve that, one is the pixel buffer objects extension, the other one is a > nvidia only extension which does exactly the same as > IDirectDrawSurface7::Lock. If neither of those extensions is available, or if > pbos turn out to be slow too, we can only play tricks like watching the > application's behavior and predict the area it will modify. I have started > toying with that, the most important fragment is this: > http://stud4.tuwien.ac.at/~e0526822/optimizer.junk If it's the most efficient way to make it work, I see nothing wrong with using an nvidia-only extension and then letting it be known we'd like that extension as part of the OpenGL specification. We'd likely want to catalog the various vendor-specific extensions we use somewhere, though. Thanks, Scott Ritchie
Re: [3/4] WineD3D: Store the pixel format in the texture
Am Mittwoch 21 März 2007 17:53 schrieb H. Verbeet: > Shouldn't this be done for volume textures as well? It is done, unless I missed something: @@ -896,6 +898,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateVolumeTexture(IWineD3DDevice *ifa object->width = Width; object->height = Height; object->depth = Depth; +object->baseTexture.format = Format; pgpi2Ng96IsE8.pgp Description: PGP signature
Re: Improving DirectDraw OpenGL renderer for SoC?
Am Mittwoch 21 März 2007 20:01 schrieb Alexander Nicolaysen Sørnes: > Greetings, > > i am thinking about participating in the Summer of Code, and thought it > would be interesting to improve DirectDraw such that Command & Conquer > Tiberian Sun & Red Alert 2 run faster. Currently, they crash once the > mouse is moved in-game when OpenGL rendering is enabled. Thus the project > would involve fixing that bug, and then other performance issues/crashes > that occur. However, I don't really have much experience with C and Wine. > The closest I have gotten is some patches for Wine's WordPad > implementation. Would it be feasible to acquire the necessary knowledge and > fix the bugs before the end of summer? I think learning those things over the summer is feasable. There is not much OpenGL knowledge required, it is mostly about drawing textured quads. Unfortunately other issues are major: The crash when moving the mouse is because those games draw the mouse from a different thread. My multithreaded opengl patches may fix that. But for real thread safety we have to implement locking of private data. For one part this needs a lot of patience because those patches are tricky to review for Alexandre, and it needs knowledge about thread synchronisation. Overall it is a very tricky task. The other issue is render target locking. This is essentially something that is not well supported by OpenGL. There are 2 extensions which can help to improve that, one is the pixel buffer objects extension, the other one is a nvidia only extension which does exactly the same as IDirectDrawSurface7::Lock. If neither of those extensions is available, or if pbos turn out to be slow too, we can only play tricks like watching the application's behavior and predict the area it will modify. I have started toying with that, the most important fragment is this: http://stud4.tuwien.ac.at/~e0526822/optimizer.junk pgpiaMl7oLVQy.pgp Description: PGP signature
Improving DirectDraw OpenGL renderer for SoC?
Greetings, i am thinking about participating in the Summer of Code, and thought it would be interesting to improve DirectDraw such that Command & Conquer Tiberian Sun & Red Alert 2 run faster. Currently, they crash once the mouse is moved in-game when OpenGL rendering is enabled. Thus the project would involve fixing that bug, and then other performance issues/crashes that occur. However, I don't really have much experience with C and Wine. The closest I have gotten is some patches for Wine's WordPad implementation. Would it be feasible to acquire the necessary knowledge and fix the bugs before the end of summer? Regards, Alexander N. Sørnes
Review of wine/crossover
Another "jouralist tries linux" article. This one's pretty good. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9013280 Her first complaint is that NoteTab Pro doesn't start when installed with Crossover. The app is $30 at http://www.notetab.com/ and sadly the free demo doesn't show the problem. The exact page where she complains about NoteTab Pro is page 3, http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9013280&pageNumber=3 - Dan
Re: automatically running wineprefixcreate
On 3/21/07, Marcus Meissner <[EMAIL PROTECTED]> wrote: On Wed, Mar 21, 2007 at 09:31:23AM -0500, Tom Spear wrote: > I was looking into my issues with menubuilder and trying to figure out > ways to make the setup automatic so that everything would go where it > should (since I know how to manually make wine put things in the > proper place), and I noticed that no matter how wine is invoked (wine, > winecfg, wineboot, winemine, notepad etc), if there is no ~/.wine it > runs wineprefixcreate _first_ in order to create it. > > Currently in order to fix my issues, I have to re-run wineprefixcreate > after running winecfg to make sure the directories and files are put > in the place I have my fake c located. > > Would it be possible to make winecfg run wineprefixcreate one more > time after the ok and apply buttons are pressed so that users dont > have to manually run it when they use winecfg? What do you really want to do? Well, Im just wanting to have winecfg run wineprefixcreate after the ok and apply buttons are pressed, so that the files and folders created by wineprefixcreate are created in the location of the fake c drive (in the event a user moved it from the default).. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
Re: [3/4] WineD3D: Store the pixel format in the texture
Shouldn't this be done for volume textures as well?
Re: automatically running wineprefixcreate
On Wed, Mar 21, 2007 at 09:31:23AM -0500, Tom Spear wrote: > I was looking into my issues with menubuilder and trying to figure out > ways to make the setup automatic so that everything would go where it > should (since I know how to manually make wine put things in the > proper place), and I noticed that no matter how wine is invoked (wine, > winecfg, wineboot, winemine, notepad etc), if there is no ~/.wine it > runs wineprefixcreate _first_ in order to create it. > > Currently in order to fix my issues, I have to re-run wineprefixcreate > after running winecfg to make sure the directories and files are put > in the place I have my fake c located. > > Would it be possible to make winecfg run wineprefixcreate one more > time after the ok and apply buttons are pressed so that users dont > have to manually run it when they use winecfg? What do you really want to do? Ciao, Marcus
Re: Supreme Commander Up and running!
Am Mittwoch 21 März 2007 14:31 schrieb H. Verbeet: > On 21/03/07, Mirek <[EMAIL PROTECTED]> wrote: > > fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 > > That'll do it. Looks like it's not so much the GLSL implementation as > the different caps we return when GLSL is used. Ah yes, Instancing makes sense for a real time strategy game. pgpPOJjp2hBob.pgp Description: PGP signature
automatically running wineprefixcreate
I was looking into my issues with menubuilder and trying to figure out ways to make the setup automatic so that everything would go where it should (since I know how to manually make wine put things in the proper place), and I noticed that no matter how wine is invoked (wine, winecfg, wineboot, winemine, notepad etc), if there is no ~/.wine it runs wineprefixcreate _first_ in order to create it. Currently in order to fix my issues, I have to re-run wineprefixcreate after running winecfg to make sure the directories and files are put in the place I have my fake c located. Would it be possible to make winecfg run wineprefixcreate one more time after the ok and apply buttons are pressed so that users dont have to manually run it when they use winecfg? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
Re: Accessing File > 4gb problem (was: Debugging Supreme Commander)
On 20.03.2007 15:08, Stephan Rose wrote: > So apparently the issue comes down the lseek failing with > 4 gig files only > on cd-rom drives and ends up not being a wine bug after all as far as I can > tell. I will try to install it from the hard drive in a little bit and see > if it succeeds then. I didn't have enough time during lunch to actually let > the install run from the HD. AFAIK Linux didn't support files with multiple extents on ISO9660 filesystems in the past, at least when Joliet is used. I'm not sure about the current status. http://en.wikipedia.org/wiki/ISO_9660#The_4_GB_file_size_limit Regards, Carl-Daniel -- http://www.hailfinger.org/
Accessing File > 4gb problem (was: Debugging Supreme Commander)
Allright, I've got the bug nailed to the wall with all of its 6 legs.
What I don't know though is what to do about it. Still trying to find
the right sledgehammer to squash it with
Problem boils down to this:
Supreme Commander has a .cab file that is just under 6 gigs in size.
0x178d42fce bytes to be exact
Now here are the last 5 file seek positions in order from first to last:
0x0ff697fb4
0x0ff69800b
0x0ffebc19a
0x0ffebc1f0
All those succeed fine. But #5 ...
0x1007bc160 results in NTSTATUS c00d, Invalid Parameter.
That address is well within the range of the file though.
The status occurs when lseek is called in this part of NtSetInformation,
don't mind my added debug fixme's =)
case FilePositionInformation:
if (len >= sizeof(FILE_POSITION_INFORMATION))
{
const FILE_POSITION_INFORMATION *info = ptr;
unsigned int* iptr = (unsigned
int*)&info->CurrentByteOffset.QuadPart;
FIXME( "%i, 0x%08x%08x\n", fd, *(iptr+1), *iptr);
if (lseek( fd, info->CurrentByteOffset.QuadPart, SEEK_SET ) ==
(off_t)-1)
{
FIXME("Bad result from lseek");
// Above fixme triggered past 4gb
io->u.Status = FILE_GetNtStatus();
}
}
else io->u.Status = STATUS_INVALID_PARAMETER_3;
break;
I checked sizeof(off_t) and it correctly reports as 8-bytes, so I am not
sure what the problem is and why this is happening.
Any ideas?
On a bright note...I almost have my Supreme Commander CD Key memorized
now...how many people can say that!!! ;)
Thanks,
Stephan
Re: Debugging Supreme Commander Installer
On 3/19/07, Stephan Rose <[EMAIL PROTECTED]> wrote: On Mon, 2007-03-19 at 09:40 +0100, Stefan Dösinger wrote: > Am Montag 19 März 2007 01:49 schrieb Stephan Rose: > > I've been playing around with the supreme commander install most of > > today trying to figure out why it does not want to install. Running with > > +file,+msgbox and noticed the following error for virtually all files: > > > So it seems that it freaks out because somehow the file appears in the > > directory tree late. > Sounds like a race :-) . I don't know anything about wine's msi and dcom > implementation(which installshield uses heavilly). DCOM is about the most > complex thing in Windows :-/ > > One think you can try if that game works with windows 98 too is to use native > msi 2.0 and / or native dcom98 . If that fails in the same way it is a bug > somewhere else(ntdll / kernel), otherwise most likely msi or dcom. Dan's > Winetricks may help with installing that. You need winver = win98 for native > msi and dcom. > No luck there...but I am one step closer to tracking down the source of the problem. I found that kernel32 is calling RaiseException when the file that is failing comes up. So I went to check it out with +seh, this is the exception that comes up: trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7ee4ca80 trace:seh:raise_exception info[0]=19930520 trace:seh:raise_exception info[1]=00334aec trace:seh:raise_exception info[2]=100f7058 trace:seh:raise_exception eax=7ee37d89 ebx=7eeb8880 ecx= edx=100f18d8 esi=100f18d8 edi=00334ad0 trace:seh:raise_exception ebp=00334a90 esp=00334a2c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00200216 Anyone have any idea on what the exception is? I've come as far so far as that it seems to be some MS Specific C++ exception. I've still got to find out what function this exception is originating in. Going to try and figure that one out next. I could be way off the mark on this one but I think I remember hearing somewhere that ebx=7eeb8880 was copy protection (SD2?). Like I said maybe way off the mark, but we will see. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman <[EMAIL PROTECTED]> writes: > Alexandre Julliard wrote: >> The MAKEFLAGS hack is certainly non portable, and won't behave right >> on other makes. Using a shell script will also cause trouble on >> Windows. The extra shell evaluation will also require some extra >> quoting, that may be tricky to get right. It's really a lot of >> trouble... > > I'm guessing you still believe this is the case, even with my latest patch. Well, the quoting is fixed, but the rest isn't... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Link creation not working _properly_ under 2.6 kernel?
On 3/20/07, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: Tom Spear wrote: >> > 2) Is the menu location (~/.local/share/applications) pretty much >> > universal? In other words IF a patch were submitted to add Start Menu >> See: http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#paths >> >> > creation under windows\profiles, would it require detection of the >> > menu location, or (in the case that it is nearly universal) could it >> > just be statically coded? >> You talking about two totally separate things: >> 1. Windows' "Start Menu" location >> 2. XOrg's location for the menu entries. >> >> Vitaliy. >> > No I'm not. Apparently wine is broken in the way that it handles > making links anyways, because if you look in winecfg with a clean > ~/.wine you see Desktop points to ~/Desktop which is not good. The > reason this is not good is because when a user installs a program they > get 2 icons, one is the lnk file that is used in windows (useless in > wine/linux for launching programs), and the other is the .desktop > file. You missed that discussion. It was decided some time ago that for compatibility reasons with 1000 different distros Wine will be using symlinks. And it works properly. But the biggest reasoning behind it is integration. Wine should use ~/Desktop as desktop (if it's present). So we want users to have both a .lnk file (which doesnt work) and a .desktop file (which does) on their desktop? Ill file bugs if that is not correct, but afaics everything in the menubuilder code looks fine. Like I said if I disable the Desktop/My docs linking in the desktop integration tab of winecfg, then wine acts properly and puts lnk files where they should be (under the fake c drive's start menu/desktop) and puts desktop files where they should be (under the real xorg desktop and menu), which is what I meant when I had said "central location", I just hadnt thought to disable the link to boxes until after I said that. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
Re: Link creation not working _properly_ under 2.6 kernel?
On 3/19/07, Tom Spear <[EMAIL PROTECTED]> wrote: On 3/19/07, Tom Spear <[EMAIL PROTECTED]> wrote: > > On 3/16/07, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > > > Tom Spear wrote: > > > > I did some more checking into this just now. I'm not sure why or how, > > > > but when I installed Worms 2, it installed the menu entries properly. > > > > So I uninstalled WinRAR and reinstalled it. This time it created a > > > > menu entry for WinRAR under the wine folder in the menu, but it isnt a > > > > subfolder, like it should be and the other icons that should be in the > > > > menu aren't there. It appears that the winrar installer may be doing > > > > something that other installers dont do > > > After install is finished you did run 'wineboot' right? As most > > > installers create icons _first_ before anything else is installed. > > > > > > > > > > > Anyone know of any debug messages I should run to try to narrow down > > > > the problem? > > > menubuilder would be helpfull. With the bug # where you should send all > > > this information of course. > > > > > > Vitaliy > > > > I just uninstalled 0.9.32 (using the make directory for 0.9.32) and > pulled and installed 0.9.33, removed ~/.wine, and drive_c as well as > my desktop icons, and menu icons. > > On an unrelated note, oddly enough wine prompted me to install gecko, > but when I said yes it did not install it and instead tried to > initialize the one from my 0.9.32 install, which wasnt there... > > So anyways I get it all installed, run wineprefixcreate and winecfg, > switch to my home directory, run wine with WINEDEBUG=+menubuilder > ./wrar362.exe and install it. > > The Desktop icon appears like usual, but still no menu icons. So I > run WINEDEBUG=+menubuilder wineboot and still get no menu icons. So, > thinking that maybe the K Menu just needed to refresh, I rebooted the > machine, and STILL get no icons.. So I looked into the > drive_c/Program\ Files/WinRAR directory, and again there is the folder > WinRAR (/mnt/d/Program\ Files/WinRAR/WinRAR) with all of the icons in > it.. So I am still having my icons created in the Program files > directory.. > > Im taking a look into menubuilder now to see if I can find anything > and will post back once the site is back up (which will be about the > time you read this). By that time I will also have a bug # (since I > cant very well create a bug with bugzilla down too).. The full > +menubuilder trace is attached with comments inside the file, and the > trace will also be attached to the bug for future reference.. > > -- > Thanks > > Tom > > Check out this new 3D Instant Messenger called IMVU. It's the best I > have seen yet! > > > > http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email > > To add a bit more info, I just retried, again cleaning everything out and rebuilding the environment with wineprefixcreate and winecfg. This time however I created a symlink from /mnt/d/windows/profiles/speeddy/Start\ Menu to ~/.local/share/applications One of the .lnk files was put in the right place this time, and then when I ran wineboot, it created the wine folder and the main shortcut based off of that. It seems (looking at my trace) that it's failing around line 917 (in InvokeShellLinker), which basically checks the location of the lnk file and if it isnt in a known location, such as Desktop, Start Menu, Startup or the common version of such, then it fails and spits a warn. The odd thing is that that function should return a relative path Assuming that my hunch is correct, if I comment out that part of the call, then it should create the shortcuts in the proper location. Of course this would only work because I manually created the symlink for Start Menu earlier, due to the next part which checks to see if the links are under the start menu or desktop The reason I see this failing is not due to a bug in the menubuilder but due to a bug somewhere else in wine that causes the folder that should go into the Start Menu to be put into Program Files\WinRAR.. So IMHO this bug is somewhere else. I'll try running with +file and see what I can come up with. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email OK finally found the culprit! Looks like the WinRAR installer is looking for the Start Menu and Start Menu\Programs.. Found it with the +file trace. If those don't exist then it defaults to installing into Program Files\WinRAR. So I now have two questions: 1) Why was the Start Menu left out of wine's first boot/wineprefixcreate and left out of the winecfg dialogs? I mean was it just an oversight or was there a specific reason, because I honestly dont know or understand. 2) Is the menu location (~/.local/share/applications) pretty much universal? In other words IF a patch were submitted to add Start Menu creation under windows\profiles, would it
Re: Regedit output to STDOUT / force registry files sync
Lei Zhang wrote: Believe it or not, there are UNIXes without /dev/stderr and /dev/stdout. Having regedit option to flush its output to STDOUT (and to get its input from STDIN) would be very helpful - and in case of STDOUT output very easy to implement. Regards Vit Hrachovy Sure, but Unices that run Wine have /dev/stderr. A better reason for not modifying regedit is that is breaks compatibility with Windows' regedit. Yes, it can is helpful to have a tool that can retrieve registry keys from the command line, but we should not overload that functionality into regedit. Hi, thanks for recommendation, I'll send a patch with the new tool for review soon. Regards Vit
RE: Enlarge max. length of PATH variable in programs/cmd/wcmdmain.c
Hello Jason, >>PS: I think char string[1024]; in the main() should be extended >>to char string[2048]; as well! (please see the MS note above) >Yes, I'd agree (to MAXSTRING, but change the 1024 in at least one of the calls appropriately as well) yes, there are several places in wcmdmain.c besides main() where 1024 is wrongly used. But that would be another patch - related to the max. length of commands. I hope my original patch will be applied (with 2048 or with MAXSTRING as you suggest) http://www.winehq.org/pipermail/wine-patches/2007-March/037313.html - it is about the max. length of a PATH variable. Regards Alex
Re: Supreme Commander Up and running!
On 21/03/07, Mirek <[EMAIL PROTECTED]> wrote: fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 That'll do it. Looks like it's not so much the GLSL implementation as the different caps we return when GLSL is used.
Re: wined3d: Check for float texture formats correctly.
On 21/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Mittwoch 21 März 2007 08:34 schrieb H. Verbeet: > On 21/03/07, Vitaly Budovski <[EMAIL PROTECTED]> wrote: > > Move the checks for float texture formats into the correct location. > > This allows some Direct3D sample applications to start up which check > > for any of the float formats together with D3DUSAGE_RENDERTARGET. > > --- > > That's better, but now those formats can only be used with render > targets. I don't think that's correct, since they were probably added > in the other place to make some application work. Especially since its pointless to render to a texture if you can't use it otherwise :-) Although I guess that apps assume that if its ok as a rt you can use it as a texture too Seems to have been comitted :-/
Re: Supreme Commander Up and running!
On Wednesday 21 March 2007 13:26, Wojciech 'arab' Arabczyk wrote: > > http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and > > this is part of messages when playing demo game: > > > > fixme:d3d_draw:drawStridedInstanced > 0x502 from > > glDrawElements @ drawprim.c / 991 > > fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 > > fixme:d3d_draw:drawStridedInstanced > 0x502 from > > glDrawElements @ drawprim.c / 991 > > I've encountered this when running some windows demoscene prod, with GLSL > FBO's enabled. Try switching to pbuffer as it helped here. Setting either pbuffer, fbo or no OffscreenRenderingMode key at all did not have any effect. -- Markus
Re: Supreme Commander Up and running!
Hello > http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and > this is part of messages when playing demo game: > > fixme:d3d_draw:drawStridedInstanced > 0x502 from > glDrawElements @ drawprim.c / 991 > fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 > fixme:d3d_draw:drawStridedInstanced > 0x502 from > glDrawElements @ drawprim.c / 991 I've encountered this when running some windows demoscene prod, with GLSL FBO's enabled. Try switching to pbuffer as it helped here. -- Best regards Wojciech Arabczyk :: http://www.arabek.net :: jid:[EMAIL PROTECTED]
Re: Supreme Commander Up and running!
Stefan Dösinger napsal(a): Which font patch? http://bugs.winehq.org/show_bug.cgi?id=7507 Oh, not d3d related. According to the system requirements the highest it uses is 2.0. I am also wondering if some of the other bugs, such as geometry being in the wrong place may be resulting from the d3dx9_31.dll not being our own. Maybe seeing some interoperability issues there between the native version of that and our own version of the remaining d3d dlls? No, this is not the case. d3dx9_31 is supposed to work with wine and works nice so far. Can you attach a screenshot showing the rendering issues and / or open a bug for them? Hi, here is screenshot: http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and this is part of messages when playing demo game: fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced > 0x502 from glDrawElements @ drawprim.c / 991 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4 fixme:d3d_dra
Re: Sugestion: A few changes to the
Giles Cameron wrote: After learning about the wine debuging output's level system, and seeing it be used for a while, I think its time we make a couple of new channels. They would be like the 'trace' channel, only for more spefic purposes, these could by default be compiled out, but when needed put in. Trace isn't a channel. It's a level of debug output for the channel. Their primary purpos would be for tracking down bugs in the API, ones that may not be as easy to find in a test case. You need to be more specific about what you propose to add. -- Rob Shearman
Re: Road to 1.0
On 3/20/07, Kai Blin <[EMAIL PROTECTED]> wrote: http://code.google.com/soc/wine/about.html Like that? Yeah. That was me attempting something resembling humor. GSoC is exactly what I meant. --tim
Re: Test framework for authentication testing
On So, 2007-03-18 at 18:18 +0100, Kai Blin wrote: > > > What I'd want to do would be the following: > > > * add a user > > > > You must handle the case, that the user has no rights > > to do that (User is not an Administrator). > > Sure. In that case, we just skip the tests like we do now. Nothing lost. When you are not an Admnistrator and run the tests for msi (install) or advpack (install), you see why I just want to point to this situation. (both tests pop up a Dialog on w2k and stop the testsuite) I will create bug-reports, when bugzilla is online again. -- By by ... Detlef
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Alexandre Julliard wrote: Robert Shearman <[EMAIL PROTECTED]> writes: I don't see how. It doesn't change the portability with other versions of make, and although I'm not an expert on shell programmings, I don't think I used an non-portable constructs there. The MAKEFLAGS hack is certainly non portable, and won't behave right on other makes. Using a shell script will also cause trouble on Windows. The extra shell evaluation will also require some extra quoting, that may be tricky to get right. It's really a lot of trouble... I'm guessing you still believe this is the case, even with my latest patch. -- Rob Shearman
Re: wine opinion of a user
Dan Kegel wrote: On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote: >> Sage Line 50 already has a bug filed: >> http://bugs.winehq.org/show_bug.cgi?id=2956 >> but we're hampered because there's no free demo for us to test. >> >You could register for a free trial cd? >http://www.sage.co.uk/considering/TryNow.aspx?tid=213114 D'oh. Missed that. Yeah, I'll register for one, thanks. Sadly, only UK residents can get the free trial. Can someone in the UK get a copy and send it to me (and/or test themselves)? I've ordered a trial CD of everything they're offering. -- Rob Shearman
Re: wined3d: Check for float texture formats correctly.
Am Mittwoch 21 März 2007 08:34 schrieb H. Verbeet: > On 21/03/07, Vitaly Budovski <[EMAIL PROTECTED]> wrote: > > Move the checks for float texture formats into the correct location. > > This allows some Direct3D sample applications to start up which check > > for any of the float formats together with D3DUSAGE_RENDERTARGET. > > --- > > That's better, but now those formats can only be used with render > targets. I don't think that's correct, since they were probably added > in the other place to make some application work. Especially since its pointless to render to a texture if you can't use it otherwise :-) Although I guess that apps assume that if its ok as a rt you can use it as a texture too pgpDEFOS5w6vr.pgp Description: PGP signature
