Re: extern char **environ and msvc
On 25.05.2011 22:52, Stefan Dösinger wrote: I'm sorry for the German, I don't know how to change this. Google finds only other clueless people. Either way it says something like Inconsistent DLL binding I believe the English translation is “inconsistent DLL linkage”. The line in stdlib.h declares _environ as _CRTIMP extern char ** _environ;/* pointer to environment table */ The compiler just writes a warning, but afterwards linking fails: 1loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol __environ. The linker complains about an unresolved external symbol __environ. Removing our declaration of environ fixes the warning, link error and libwine seems to work OK. I don't know what the proper fix is, please advise. Maybe this code shouldn't be compiled at all? I don't think I need the loader code on Windows. The underlying issue is probably the _CRTIMP - that's most likely _declspec(dllimport) in MSVC. This matters, as DLL-imported and “plain” extern variables are handled differently on Windows. IIRC DLL export/import of variables is indirect - when DLL-importing a variable you really import a _pointer_ to the variable. So accessing the variable dereferences some pointer. “extern” variables, otoh, are accessed directly (resolving the actual variable location is handled at link-time). -f.r. signature.asc Description: OpenPGP digital signature
Re: correct comctl32 implementation
On 11.03.2011 10:28, Nikolay Sivov wrote: In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless. Buttons: technically, I don't think you need SxS class redirection for that. The issue with the current “subclassing” is that, well, the button can't really be subclassed for theming - IIRC some state changes don't trigger a “paint” message but only cause internal painting - this can't be caught lass function and breaks theming. What MS supposedly did was to simply copy'n'paste the controls code into comctl32 and add theming. That would certainly allow properly themed buttons. And SxS class redirection... Scroll bars, are, IIRC, a different beast - window scroll bars are not controls but handled/drawn by DefWndProc. No idea how native themes these. Maybe some mojo to override/hook into DefWndProc? -f.r. signature.asc Description: OpenPGP digital signature
Re: shell32/tests: Test that a folder can be named when clicking Make New Folder
On 10.08.2010 20:22, Michael Mc Donnell wrote: When a user clicks the Make New Folder button a new folder is created. The name of the folder is selected, and the dialog box waits for the user to either accept the name or type in a new one. The test types in a new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.
Re: [2/4] tools: enable .lnk thumbnailing in Gnome
On 28.07.2010 09:36, Damjan Jovanovic wrote: thumbnails that are missing on every startup. But even if this is acceptable solution, it's still hard to implement, because the thumbnail cache spec requires specific thumbnail sizes (128x128 or 256x256) and a special pixel format (256 colour indexed-mode PNG IIRC) Differing sizes are no problems. Prominent example: if you have picture with an aspect ratio other than 1, the thumbnail won't be square. The file managers usually handle that quite fine ... The spec actually says that thumbnails for small images don't have to be saved; though in practice I'd expect that a 32x32 sized thumbnail shows up as 32x32 (and not scaled up or so). Colors: spec says “it must be a 8bit, non-interlaced PNG image with full alpha transparency”. It's somewhat ambiguous, but indexed colors seem unlikely - 32bit RGBA images (ie 8 bit per channel) is what every thumbnailer practically creates. Link for above info: http://jens.triq.net/thumbnail-spec/creation.html -f.r.
Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
On 19.06.2010 06:30, Vincent Povirk wrote: I guess it's not a problem. It's just that up until now, I've been trying to keep them interchangeable. Isn't windowscodecs supposed to be extensible with 3rd party plugins?... So you could provide the additional formats D3DX would use as plugins instead of built-in; that should make these available with both wine's as well as native windowscodecs. -f.r.
Re: The WineHQ About page needs a picture
On 19.05.2010 17:03, Scott Ritchie wrote: I was doing some housecleaning work looking at the WineHQ website, and I realized we still have an awful lot of flat, wide text on the About page. This is the perfect place to collapse it into a column and fill the right side of the screen with an image. But...what image? wxwidgets.org shows a small, random screenshot on its front page... could do the same for the about page? Perhaps select some AppDB screenshots of ”interesting” apps (eg Office, popular games) and rotate through them. -f.r.
Re: GdiplusAbort type needs to be translated from C++ to C
On 19.11.2009 17:23, Vincent Povirk wrote:
The Windows SDK defines the following type:
struct __declspec(novtable) GdiplusAbort
{
virtual HRESULT __stdcall Abort(void) = 0;
};
I don't think I can provide a proper C++ definition because the abi
depends on the compiler.
Depends; with limitations this is possible. For cases like above - ie
interface kind of structs with no members, only virtual methods and
explicit calling convention specified - the resulting struct layout is
the same between MSVC and g++ (at least on MinGW) and can be passed from
binary code of one to another. If Linux g++ produces the same struct
layout as it does on mingw it would be viable to keep the C++ version
for, well, client sources written in C++.
Does this look correct?
You forgot __stdcall on 'Abort' member of gpabort_vtable.
-f.r.
Re: Image List tests for comctl32 v6
On 02.10.2009 00:27, Joel Holdsworth wrote: Does anyone have any thoughts about what might be going on here, and what I should do with my tests? If the manifest is set up dynamically I would expect that all symbols imported from comctl32.dll are done so _before_ the manifest takes effect, ie any comctl32 functions would be from the pre-v6 one chosen at the program load time. (Apparently, for window classes, there is some extra mechanism in Windows that makes the v6 classes used.) If that is the case the solution would probably be to load v6 comctl32.dll dynamically and obtain the symbols you want to use at runtime as well. -f.r.
Re: Finding IDB_VIEW_SMALL_COLOR
On 06.09.2009 22:29, Joel Holdsworth wrote: Does anyone know where the 32-bit one is? comctl32.dll version 6, it seems. -f.r.
Re: comctl32: stop flicker when drawing themed
On 26.07.2009 15:57, André Hentschel wrote: ...and draw the correct image smothly. the code shouldnt have been copied and paste from the unthemed code. This changes the appearance of progress bars: now they look always smooth when themed. But on Windows they look always chunky when themed. -f.r.
Re: comctl32: Fix dialog ('Next' button was hidden)
On 09.07.2009 07:42, Aurimas Fišeras wrote: On 07/08/2009 10:31 PM, Frédéric Delanoy wrote: I think it should be under the button Finish, so that the Finish button can be shown in the same place instead of Next on the last wizard page. I recall some Wizards have Next and Finish visible enabled at the same time ... so I don't think putting Next and Finish in the same place is a good idea. -f.r.
Re: d3d9: Add DF16 support
On 07.06.2009 19:35, Henri Verbeet wrote: 2009/6/7 Frank Richter frank.rich...@gmail.com: As far as I could gather DF16 is the ATI way of getting a renderable 16 bit depth texture. Without knowing much about the actual format, DF16 implies this should be a floating point format, similar to the ones provided by ARB_depth_buffer_float. Maybe... but it seems that format is solely intended for use on render target textures, not any download or upload... so not sure if the data type would matter in practice. Also, I didn't find a 16-bit float depth texture format for OpenGL so far. Also, could you please add this at the same location as the other depth formats? Well I added it to the vendor-specific formats because it _is_ ATI-specific... -f.r.
Re: d3d9: Add DF16 support
On 07.06.2009 22:22, Henri Verbeet wrote: Even if the format isn't lockable, you can still use the data with a shader. If it's a typical depth format the shader will see normalized values. Information on DF16 seems to be sparse, one thing I found was: http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0611AL=DIRECTXDEVP=R2492I=-3d=No+Match%3BMatch%3BMatches It says that DF16 returns real depth values - which would indeed be normalized. Typically float formats aren't normalized, so you can have values outside the traditional [0.0,1.0] range. If there's no specific extension for this format you could use GL_DEPTH_COMPONENT32F as internal format and GL_HALF_FLOAT_ARB as type, although that would waste some memory, of course. On what graphics cards is that extension supported? DF16 is supported since the R300. It appears that float depth formats are much younger, so it seems unlikely DF16 is actually a float format internally. Does D3D(9) allow a depth range outside [0.0,1.0] anyway? Is there any specific application that needs this format? Some ATI graphics demos (e.g. Toy Shop). Probably at least some games that use shadow mapping. -f.r. signature.asc Description: OpenPGP digital signature
Re: New icons for 1.1.21
On 09.05.2009 04:41, Scott Ritchie wrote: Anyway, please feel free to give way too much feedback :) The outline of the upper glass part seems to be a shade of gray, but the outline of the shaft at the bottom is black, looking kind of unbalanced. Changing the black to #919191ff looks IMO better. -f.r.
Re: Wine menu creation questions
On 27.01.2009 05:00, Scott Ritchie wrote: One open question: what to do with Windows apps that don't put themselves in Program Files, but rather put themselves at the top of the start menu? Desktop menu building could put both 'Program Files' and 'real top-level' entries under the same Wine Programs menu. -f.r.
Re: Wine menu creation questions
On 25.01.2009 22:58, Owen Rudge wrote: Windows software may be a better term than Wine. Program Files wouldn't really make sense, since all the items in the Applications menu are meant to be program files. On the issue of whether we should keep the Programs subfolder, I guess you could transparently redirect things that try to create items there, and it would probably not cause too many problems. The current system though doesn't seem too bad. Also, Windows and Linux desktops have a bit of different views on what the desktop menu should contain: most of the time, the Windows start menu contains one folder per application, with that folder containing not only the application but also a link to the README or web page, uninstaller etc. In contrast, Linux desktop first sort the items per category (eg Education, Development) and there is one icon per application (no READMEs etc). Now, if the Windows start menu would simply be merged with the desktop menu at the top level, you'd suddenly throw (potentially a lot) application/vendor categories into it - arguably with a messy result. Ideally, Windows applications would just show up in the according desktop menu categories - but of course, since this information isn't provided by Windows in any way* you would have to have a database of application-to-category mappings**. So realistically, while not the nicest solution, there probably has to be some Wine applications or Windows applications (or, if you want to do without Win* entirely, Other applications or so). * - Vista added the Game Explorer, so games could be identified and added to the Games category. ** - This actually sounds like something the 3rd party Wine users (eg Crossover, Bordeaux, Wine Doors) could implement. -f.r.
Re: [2/3]: winemenubuilder: generate fd.o MIME and file type associations
On 24.01.2009 12:03, Damjan Jovanovic wrote:
+static char* wchars_to_unix_chars(LPCWSTR string)
+{
+char *ret;
+INT size = WideCharToMultiByte(CP_UNIXCP, 0, string, -1, NULL, 0, NULL,
NULL);
Since that is used to write fd.o desktop and mime files: double-check
the respective specs, I believe they mandate UTF-8 as the character
encoding. UNIXCP isn't necessarily UTF-8.
-f.r.
signature.asc
Description: OpenPGP digital signature
Re: RFC: fd.o file type association integration
On 15.01.2009 21:31, Damjan Jovanovic wrote: Also what is a good way to invent a MIME type for an extension? Currently for a .ext extension I'm just using application/x-wine-ext. For some extensions the system's fd.o mime database might already record a mime type. Perhaps you can somehow reverse lookup a mime type for an extension if none is specified in the registry. -f.r. signature.asc Description: OpenPGP digital signature
Re: wow, there are more win64 apps than I thought...
On 20.12.2008 13:42, Dan Kegel wrote: I updated http://wiki.winehq.org/Wine64 with a list of some win64 apps. There are lots more than I expected. I also recall that Far Cry (1) is available as 64-bit version, tho someone who actually possesses that game should check back. So it could also serve as a test case for DirectX in 64 bit ;) -f.r.
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On 02.11.2008 23:28, Steven Edwards wrote: I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard. I've just seen this: http://www.andreasn.se/blog/?p=91 In short, there is work being done on a GTK+ theming engine that uses CSS(!) for describing themes. If that pans out ... arguably you could cover quite a good part of a hypothetical 'formal standard' by just reusing CSS. -f.r. signature.asc Description: OpenPGP digital signature
Re: ComputeSphereVisibility: a patch
On 14.11.2008 20:27, paulo lesgaz wrote: Hi, here is a patch for a first try to implement ComputeSphereVisibility. Any feedback is welcome. I think you can simplify the sphere-plane intersection. Just compute the signed distance D of the sphere center from the plane. If D r, the sphere is visible. If -r = D = r, the sphere is partially visible. if D -r, it's invisible. Also, wine people like tests. You should probably add some. -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On 01.11.2008 21:21, Reece Dunn wrote: In order to do that properly, you will need major buy-in from the Gtk, Qt and other widget toolkit developers, FWIW, I recall having read some Planet GNOME blog posts where people expressed, well, a bit of unhappiness with GTK's current theming system. (Apparently a lot of hacks are needed, some even for specific applications.) So a buy-in might be possible from them, if you promise something better than you have now ;) -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On 01.11.2008 14:04, Reece Dunn wrote: Note that as Vista has a different msstyles theming engine (it is a DLL), It's also a DLL on XP. Note that in both cases no code is exported, the DLLs serve only as a container for the theme data, stored as resources. we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles That sounds like misappropriating the msstyles 'format'. The idea of theming engine plugins is a good one, but then some other mechanism than abusing the msstyles extension should be used to detect these plugins. Some ideas: an extension (but a different, unique one), putting them into a special directory, listing engines in the registry. Anyhow, this is somewhat bikeshedding ;P First step would probably be to define a theming plugin API - you say that the theming plugins would just export the whole uxtheme API. However, it could be possible that the theming plugin interface can be simplified compared to that, with uxtheme.dll filling the gaps. (After all, a simpler interface can mean a simpler plugin implementation...) -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On 01.11.2008 16:06, Reece Dunn wrote: It would also be a good idea to look at the capabilities of the major theming engines (Gtk, Qt, Cocoa) and possibly some others like the one used by Enlightemnent and try to abstract an API that can accommodate them all in a straightforward way. Definitely. Note also that there is the added complication that the interface wine uses will need to be a native one, so it can interact with the native cocoa, qt or gtk libraries. This is already done in Wine, e.g. look at some of the TWAIN plugins Wine ships - they're DLLs but access native APIs like gphoto, iirc. -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On 01.11.2008 16:49, Roderick Colenbrander wrote: The winetheme app would have plugins So winetheme would have plugins - that seems to make the whole thing an additional complication over straight uxtheme plugins, since you have the application as an extra layer in the middle. And as already said, an application may complicate things such as reacting to theme changes on the fly. -f.r. signature.asc Description: OpenPGP digital signature
xrandr unsupported video modes [was: Re: winecfg - great job!]
On 28.10.2008 22:33, Eric Anopolsky wrote: Thanks, but it's not a wine bug. The problem is that xrandr doesn't think 640x480 and 800x600 are valid modes on my laptop so when I launch Diablo II I get a dialog box that says: I guess technically it would be possible to emulate the modes. I recall that DirectDraw/Wine actually uses OpenGL as a backend, so just stretching up to a higher resolution would be trivial (though not it may not necessarily look good to everyone). Anyhow, all that should probably go into a bug report if it's perceived as an issue Wine should deal with ... -f.r. signature.asc Description: OpenPGP digital signature
Re: [1/3] [try 3] appwiz.cpl: Add GUI for Add/Remove Programs controlpanel
On 17.07.2008 17:22, Owen Rudge wrote: Well, I'm not sure how much smaller I can realistically split them, at least, if the individual parts are to be functional, although I guess the first and second ones (which are the largest) could be split up a little more if that is the reason they weren't accepted. The larger a chunk is the harder a review is. I think a patch doesn't necessarily have to have a sensibly functional result. E.g. you could start off with a very skeleton control panel, maybe icons which don't do anything. Sure, it's not very functional, but it is very easy to review. Likewise, the next step could add a do-nothing dialog ... and so on. -f.r.
Re: Alex Villacís Lasso : uxtheme: Speed up UXTHEME_SizedBlt in the ST_T ILE by building an appropriately-sized me mory bitmap out of the tile instead of iterating with UXTHEME_Blt () directly
On 23.04.2008 01:00, Alex Villacís Lasso wrote: Have you seen a theme that uses alpha and breaks with my patch? It's more of a dim recollection from the time I worked on the theming stuff. Mind you, it's a while back now, so assuming I remember right the underlying issue might have been fixed already. -f.r.
Re: Alex Villacís Lasso : uxtheme: Speed up UXTHEME_SizedBlt in the ST_TILE by building an appropriately-sized memory bitmap out of the tile instead of iterating with UXTHEME_Bl t () directly
On 22.04.2008 13:47, Alexandre Julliard wrote: uxtheme: Speed up UXTHEME_SizedBlt in the ST_TILE by building an appropriately-sized memory bitmap out of the tile instead of iterating with UXTHEME_Blt() directly. But does that keep the alpha channel intact? -f.r.
Re: [PATCH] winecfg = control panel applets patch
On 10.04.2008 09:47, [EMAIL PROTECTED] wrote: However, since control panel does not utilize Unicode yet, the additionalb Bulgarian translation matches the English one. So what's the point of that translation then? Right now it doesn't add anything worthwhile but increases the patch size - not good. You probably increase the chance of your patch being accepted by leaving out that not-really-a-translation. I'd recommend you submit that as a patch at a later point of time. It probably also makes sense to properly unicodify the control panel before supplying a language that needs it. -f.r.
Re: [RFC] winecfg enhancements
On 13.02.2008 10:15, Reece Dunn wrote: * Pre-populate the Theme list with themes in WINDOWS/Resources/Themes and with other *.theme files added by the user. I dimly recall this is already the case. winecfg lets uxtheme enum installed themes, which in turn should look into said directory. * Rename Install theme... to Add The rationale is that we are not installing a theme, but setting it as the theme being used. Having the theme appear in the Themes list in the future further supports this name change and workflow. Well but it really installs. It copies the selected file to Themes dir. See on_theme_install() in winecfg. -f.r.
Re: [msiexec] A nicer icon
On 19.12.2007 13:04, Alexandre Julliard wrote: Having icons in .svg format is a nice improvement, but we'll need a tool to build the .ico from the .svg. We also need to include multiple sizes in the .ico, most places want a 32x32 icon, and scaling down the 48x48 looks bad. Of course we should also look into taking advantage of the larger size where that's possible without breaking compatibility. I've created a system to produce Win32 .icos from SVGs for another project[1]. I used rsvg to convert svg-png, imagemagick's convert to reduce color depths and finally icotool[2] to assemble the Win32 icon. -f.r. [1] http://trac.crystalspace3d.org/trac/CS/browser/CS/trunk/mk/jam/icons.jam - it's for the Jam build system, but at least you can see the commands used (the stuff in 'actions'). [2] Part of icoutils: http://www.nongnu.org/icoutils/
Re: xdg_user_dirs patches
On 01.12.2007 22:05, Steven Edwards wrote: I think teaching them about .lnk files is a better solution. It should not be to hard to have a mime type of *.lnk that invokes Wine and passes the shortcut to the link processor. Really all GNOME KDE need to do with *.lnk files is have the ability to follow a small part of them to the binary in question and load the Icon data from the resource section. The rest can be off loaded to Wine when a user actually clicks one. One idea I had earlier is to actually store .desktop file data in files ending in .lnk. At least gnome didn't care about the extension (didn't try with KDE due not having it installed). So the shell links would show up as proper icons on the desktop. Also, applications would see files with a suffix of '.lnk' so e.g. uninstallers would work correctly when directly deleting link files. Of course it's a bit of a hack. A technical issue is that the original .lnk would have to be preserved somewhere to make sure all attributes can be restored without loss. When the shell is used to access the links, this hiding is not a problem. However, when an application would access the .lnk directly, it'd see a .desktop file. (Don't know how common that is.) Also, since applications could copy/delete a link file directly, some process would have to monitor the Desktop dir and ensure that .lnks are turned to .desktops and that any possibly necessary cleanup of the shadowed original data is done when the .lnk is removed. -f.r.
Re: programs/explorer/desktop.c: Add error checking
On 01.12.2007 16:20, Vitaly Lipatov wrote: UuidToStringW from legacy (DCOM95) rpcrt4.dll returns RPC_S_CANNOT_SUPPORT, works only ANSI version. Changelog: Add return codes checking for UuidCreate and UuidToStringW Do users still commonly install that legacy DCOM? If so, it may be better to replace UuidToStringW with UuidToStringA so the initialize_display_settings() function continues working (it looks somewhat important, but not sure if it really is). -f.r.
Re: xdg_user_dirs patches
On 30.11.2007 18:50, Dimi Paun wrote: I guess the preferred solution would be to teach GNOME KDE about .lnk files. Or write .desktop files to the Desktop dir. -f.r.
Re: d3dx8: Implementation of WINAPI D3DXAssembleShaderFromFileA
On 27.11.2007 09:28, Michael Stefaniuc wrote: Just go for if ( !pSrcFile ) return D3DXERR_INVALIDDATA; LPWSTR pSrcFileW = NULL; DWORD len; HRESULT ret; ... That's C++, not C, isn't it? -f.r.
Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW
On 01.11.2007 14:26, Robert Shearman wrote: There's no need to move the entry for SetupInstallServicesFromInfSectionW. The list was sorted alphabetically, but now it isn't. Unless you ignore the A/W suffix. One could argue that this is more intuitive as you could locate an entry in the list by searching for the undecorated name and then look for the one with the appropriate suffix, which is at most one line away. If you sort strictly alphabetically, A/W variants may be a couple of lines away (e.g. FooA/FooExA/FooExW/FooW) which could make finding the right variant slightly counterintuitive. -f.r.
Re: Misplaced Property Sheet buttons
On 26.10.2007 16:52, Peter Åstrand wrote: This solves the position problem, but instead the Help button disappears. See screenshot http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas? Hint: check again what WM_WINDOWPOSCHANGED's 'lParam' contains ... -f.r.
Re: [PATCH] wininet: Substitute strchrW with memchrW in InternetCrackUrlW.txt
On 17.10.2007 06:49, Nigel Liang wrote: Hi, strchrW assumes a NULL-terminated string. May crash if terminating character is not found. memchrW is better because you can specify the maximum number of bytes to search. On the flipside, memchrW() doesn't stop at a NUL... -f.r.
Re: comctl32: fixed drawing the trackbar background when themes are installed
On 07.10.2007 17:41, Reece Dunn wrote: The DPI trackbar has a black background that does not match the property sheet background. This patch fixes this so that the trackbar is drawn correctly. Wouldn't, or so says my intuition, the parent background usually be drawn before the control background? -f.r.
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
On 31.07.2007 05:37, Dmitry Timoshkov wrote: rc doesn't support embedded or escaped quotes at all. So statements like LTEXT String with quotes,-1,7,7,120,8 or LTEXT String with \quotes\,-1,7,7,120,8 don't work. The strings I'm using and that work for me look like: LTEXT String with quotes,-1,7,7,120,8 That would create an additional problem for translators IMO. Why? -f.r. signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable byaWindows resource compiler
On 31.07.2007 17:44, Dmitry Timoshkov wrote: Alexandre Julliard [EMAIL PROTECTED] wrote: Like it or not different languages use different styles of quoting, and you can't force everybody to use single quotes just because a couple of places are escaping incorrectly. Not a couple of places! It got spreaded by copy/pasting over almost all of .rc files. For what gain? Just because somebody likes fancy things? FWIW, use of fancy quotes is sometimes featured in official rules for languages. In German, for example, but likely others, too. Also, while and ' have obviously a special meaning for the resource compiler and need to be escaped, I doubt ‘’‚‛“”„「」『』 have, so using them in strings - as far as the codepage allows - shouldn't cause any problems. -f.r. signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
On 30.07.2007 16:37, Dmitry Timoshkov wrote: Steven Edwards [EMAIL PROTECTED] wrote: In this case do you mean windres or rc? I ask because if its rc then shouldn't we fix wrc to not accept these sources also? If its windres thats broken I think there is a workaround for the problem. This patch is aimed to make winecfg resources compileable by microsoft's rc. I don't think that fixing wrc is worth the trouble. I just played with winecfg under Windows to see how well it behaves there :-) What's the actual problem? Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? -f.r.
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
On 30.07.2007 18:54, Dmitry Timoshkov wrote: Frank Richter [EMAIL PROTECTED] wrote: What's the actual problem? rc simply doesn't handle \ or constructs. Hm, I have some .rc files here with that work just fine with MS' rc. (Tho maybe it's braindead enough to have it supportted in one place but not some other.) And what about other substitutes, like \x22 or \042? Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? The problem is that those characters don't exist in some locales. But when they exists in the codepage commonly used for a locale, I don't think there is a reason not to employ them? -f.r. signature.asc Description: OpenPGP digital signature
Re: wine's argv[0] and current directory
On 21.07.2007 18:05, Vitaliy Margolen wrote: First of all there are extensive tests for this in kernel32 process test. Which shows exactly opposite from what you stated here - windows does support use of unix path. Unix paths or unix-style paths? If a program is started as /home/user/myapp and would see the directory /home/user in argv[0] I'd guess it would interpret that as C:\home\user, while seeing something like Z:\home\user or Z:/home/user would perhaps me more correct. That said, perhaps an absolute unix path in argv[0] should be converted to a Windows path. -f.r.
Make winecfg a control panel applet? [was: programs/winefontcfg: Add winefontcfg]
On 12.07.2007 18:29, Stefan Dösinger wrote: I am not sure if it is a good idea to wrap the winecfg functionality into something complex like a control panel applet(which is tied to shell folders in some way). A user can easilly break core parts of wine with winecfg. The more complex the requirements for winecfg are the more likely it is that a user can't get back into winecfg to undo a bad option. Control Panel applets are just DLLs... You could provide an alternative way to launch the wine configuration in case something is too borked, like an entry point for RunDll32, or turn winecfg into a simple launcher for the configuration applet. -f.r.
Re: [3/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
On 25.06.2007 16:03, H. Verbeet wrote: On 25/06/07, Stefan Dösinger [EMAIL PROTECTED] wrote: +0x0009fffe, 0x58443344, 0x68532038, /* No idea about that stuff, */ +0x72656461, 0x73734120, 0x6c626d65, /* vsa.exe generated it */ +0x56207265, 0x69737265, 0x30206e6f, /* And without it windows complains*/ +0x0031392e, That looks pretty bad, imo. FWIW, that comment reads D3DX8 Shader Assembler Version 0.91. -f.r.
Re: wine menus
On 22.06.2007 08:21, Damjan Jovanovic wrote: Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay? Another idea: let wine's explorer monitor the start menu directory and let it update the fd.o menu as soon as it detects a change. This way changes to the start menu folder are instant, at least while explorer runs. -f.r.
Re: Start of an opengl-based gdi driver
On 28.05.2007 22:23, Stefan Dösinger wrote: loads it into an opengl texture(GL_ALPHA) and records 256 display lists to draw textured quads. So far no unicode support, no custom pens, but custom fonts work. One trick I've seen (in CEGUI) is to use one font texture per Unicode plane. So the page you attached would be the texture for plane 0 (ie ISO-8859-1). Also, why display lists? Each character is a quad. You could draw the text from simple quads, with some buffering to reduce overhead. -f.r.
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
I would make the combobox editable (plain CBS_DROPDOWN), just add all preset memory sizes, and WM_SETTEXT the value read from the registry. -f.r.
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
On 16.05.2007 18:18, Frank Richter wrote: I would make the combobox editable (plain CBS_DROPDOWN), Er, you do that already. Pays off to read... just add all preset memory sizes, and WM_SETTEXT the value read from the registry. Might be code-wise a bit simpler than your GETCURSEL approach, but otherswise not much different I think. -f.r.
Re: Unsecured API functions
On 03.05.2007 22:00, Tom Spear wrote: Do we implement secured versions of other functions, and if not, how come? The *_s functions are provided by the C runtime library (ie msvcr80.dll). So Wine probably doesn't need to implement them (at least not until they pop up in, say, msvcrt.dll). -f.r.
Re: dbghelp: Directly use Heap functions.
On 30.04.2007 08:56, Eric Pouech wrote: Markus Amsler a écrit : This reduces WoW debug symbol load time from about 100s to 18! this also removes two key design features: - memory is free:d (as Dimitry already pointed out) - a memory pool is associated to every module, so that all allocations for a specific module are free:d when the module is unloaded If using the Heap* functions gives such a significant speed boost it may make sense to create a heap with HeapCreate() per module and use that. When a module is unloaded you can just call HeapDestroy() to get rid of the memory allocated for that module. -f.r.
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
On 27.04.2007 09:23, Vit Hrachovy wrote: Hi, the attached patch adds new textbox input 'Video Memory size' for Graphics/Direct3D tab of winecfg. Updated every live locale resource to include this. Some thoughts on the UI: - Maybe make it an editable combobox with common sizes in the dropdown (64, 128, 256 ...) for convenience. - It looks like the field is left empty when no video memory setting is found in the registry. Maybe it's better to show the default value from wined3d then? -f.r.
Re: Uninstaller: 2 questions
On 25.04.2007 19:58, Steven Edwards wrote: Why do we show a dialog if there are no uninstall entries found in the registry? Windows does not do that, and I think we shouldn't either. I agree. So a user starts the uninstall app but doesn't see a dialog... and probably thinks it's a bug. On the other hand, just showing a dialog with an empty list makes it clear that there's nothing to uninstall and will probably not produce false bug reports. I just worry we will get in to a situation where the uninstall partly worked and uninstall.exe goes ahead, removes the entry and then the user is left with old files floating around. Better to leave the entry and then the next time they try to run it, prompt them to just remove the offending entry. Or perhaps don't ask but just remove the entry? -f.r.
Re: Add Windows Vista option to winecfg
On 12.04.2007 15:25, Felix Nawothnig wrote: Kovács András wrote: This patch is needed, because DirectX 10 is Vindows Vista only feature. Nothing wrong with adding Vista to the list but how is this needed? You don't want to disallow usage of dx10 unless Vista is selected, do you? Apps might do something like if (WindowsVersion = WindowsVista) UseDX10(); else UseDX9(); So a Vista version would make those apps take the DX10 path. -f.r.
Re: Wine Benchmarks and CAPS
On 29.03.2007 09:41, Tom Wickline wrote: CAPS results: http://wiki.winehq.org/DirectX-Caps Some note on the coloring: presumably, a green coloring in the Wine row means better, red means worse. For true/false caps those that Wine has but native doesn't are green, while those that Wine does not have but native not are red. However, presence of a cap is not always better: for example D3DPTEXTURECAPS_CUBEMAP_POW2 - MSDN says that this means Device requires that cube texture maps have dimensions specified as powers of two. So it's actually better if the flag is absent (as that means cubemaps can be non-POW2). It would be nice if the visual hint could reflect that - this way a red background would be a clear signal that this needs work. -f.r. signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] wined3d: Add ARB_texture_rectangle extension
On 29.03.2007 16:02, Stefan Dösinger wrote: Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: Add support for ARB_texture_rectangle extension. --- dlls/wined3d/directx.c|3 +++ include/wine/wined3d_gl.h |9 + 2 files changed, 12 insertions(+), 0 deletions(-) There is also GL_NV_texture_rectangle. Is that one related? I think they're the same. -f.r.
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
On 10.03.2007 15:02, Fabian Bieler wrote:
+static const PixelFormatDesc NV_texture_shader_formats[] = {
+{WINED3DFMT_V8U8,0x0,0x0,0x0,0x0
,2 ,FALSE ,GL_SIGNED_HILO8_NV ,GL_HILO_NV ,GL_BYTE
},
Are you sure this is right? From the NV_texture_shader spec it looks to
me like HILO is for high-precision data, and that DSDT (described as
offset data) would be more appropriate for V8U8.
-f.r.
Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
On 03.03.2007 13:56, Joris Huizer wrote: if( i == 0 ) - memcpy( lpSpData-dwReserved1, returnBuffer, sizeof(lpSpData-dwReserved1) ); + sscanf(returnBuffer, %x, lpSpData-dwReserved1); Couldnt you use: strcpy(lpSpData-dwReserved1,returnBuffer); Reading a string and interpreting it as a hex value, this value then being stored in a DWORD, is not quite the same as copying the string into the memory occupied by the DWORD. -f.r.
Re: Using ex-user32 controls from native comctl32 6
On 28.02.2007 18:26, Felix Nawothnig wrote: So, any idea how Windows makes comctl32 register the user classes? I think it just re-registered the classes, but I'm not sure. A trace with class registrations (ie +class) might give some hint at what native does. -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine and XP Themes
On 26.02.2007 00:33, Vitaliy Margolen wrote: Oh and yeah the only workaround is not using themes at all. They are buggy and never worked right anyway. They are an extra hackish layer on top of some controls. The comctl32 controls all do theming natively. The subclassing is done only for control residing in user32 (the motivation was to avoid copying and pasting all the control implementations from user32 to comctl32, as Microsoft supposedly did). WRT speed: themes usually use alpha-blending extensively; however, the speed of Wine's AlphaBlend() can almost be measured in geological terms; so at least part of the performance problem can be found there. -f.r.
Re: [Bug 7503] Eve Online pasword box on login screen doesn't work
On 21.02.2007 03:31, Dmitry Timoshkov wrote: Lei Zhang [EMAIL PROTECTED] wrote: Can we change wineprefixcreate to copy the truetype fonts (if any) from /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert distro specific X11/fonts/TTF directory] to $WINEPREFIX/drive_c/windows/fonts/ ? No. It's the distribution's duty to put ttf fonts in the path available through the fontconfig APIs. Unless the game tries to read the .TTF file directly from the Windows\Fonts directory. (For e.g. custom rendering without GDI. I don't know if that's the case, but it's a possibility.) -f.r.
Re: [2/2] shell32: Add proper support for SHGetFileInfo(SHGFI_ICONLOCATION | SHGFI_USEFILEATTRIBUTES).
On 18.01.2007 16:23, Francois Gouget wrote:
+if (dwFileAttributes FILE_ATTRIBUTE_DIRECTORY)
+{
+lstrcpyW(psfi-szDisplayName, swShell32Name);
+psfi-iIcon = -IDI_SHELL_FOLDER;
+}
At least on Windows, folders have a file type, too - see HKCR\Folder. So
maybe use 'HCR_GetDefaultIconW(LFolder, ...)' when the directory
attribute is set, and 'HCR_GetDefaultIconW(sTemp, ...)' otherwise?
-f.r.
Re: OpenGL in child windows
On 10.01.2007 07:27, Chris Robinson wrote: Beyond that, the only problem I can recall off-hand is that the OpenGL window will draw overtop of all Win32 windows that are sharing the same X11 parent window. Hmm, if OGL is displayed in its own child window, maybe it's possible to shape it so that overlapping Win32 child windows are excluded... -f.r.
Re: uninstaller: Add a Portuguese translation (contributed by Americo Jose Melo).
On 08.01.2007 11:49, Francois Gouget wrote: +CAPTION Desinstalador de Aplicações Wine That's UTF-8... Is that correct? I though Portugese resources should be in cp1252. -f.r.
Re: appdb rating inflation
On 03.01.2007 04:00, Dan Kegel wrote: No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Platinum rating. Giving a set of points may lead to some people think hey to run MyApplication I just have to some obscure workaround. It's not in the list, so lets rate it platinum!. So maybe put some generalized criterium in front of that list: The application should install and run on a fresh, unmodified Wine, from original installation media. That means, among other things, no manual editing of files, ... OTOH, there are not much obscure workarounds not covered by that list. Manually editing the registry might be one that should be be disallowed. Also, you mentioned apps that only run as root; this might be worthwhile to disallow, too. -f.r.
Re: wine-patch OleIconToCursor function
On 30.12.2006 18:54, Marcus Meissner wrote:
+/***
+ * OleIconToCursor (OLEAUT32.415)
+ */
+HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon)
+{
+FIXME((%p,%p), (olepro32.dll), partially
implemented.\n,hinstExe,hIcon);
+if (hIcon)
+ return CopyCursor(hIcon);
+else
+ return NULL;
+
+ /* FIXME
+ make a extended conversation from HICON to HCURSOR
+ */
+}
According to http://msdn2.microsoft.com/en-us/library/ms694362.aspx,
this function just does a simple CopyCursor() on Win32. And since there
doesn't seem to be a need for further changes to that function, the
FIXME trace as well as comment could both be removed.
-f.r.
Re: kernel32 console bug?
On 21.12.2006 21:28, Eric Pouech wrote: perhaps ShellExecute is supposed to create a console when calling CreateProcess for CUI subprocesses (this should be tested) Or CreateProcess() itself creates the console window. -f.r.
Re: winemenubuilder: Write truecolor icons as PNGs
On 06.12.2006 20:01, Francois Gouget wrote: The thing that blocked this patch from being applied last time is that, if I remember correctly, Alexandre would like the PNG functionality to be added to the IPicture implementation in dlls/oleaut32/olepicture.c. Then winemenubuilder would use this interface to save the icon into the proper format. It's easy to see where the code should go to extend this interface to support loading PNG files as it already supports loading Gif and Jpeg files. However I'm fuzzy on how one would use this interface to specify the format to use for saving. Maybe by defining Wine-specific PICTYPE_XXX values? But that would not work on Windows... Looking at IPicture, it just doesn't seem to be made for conversions. You can save an image in the original format, but that's about it for image format support. Using IPicture to write a PNG seems like trying to fit a square peg into a round hole. Ideas like abusing PICTTYPE don't help to relieve that feeling. -f.r.
Re: Running winetest on Vista
On 18.12.2006 16:50, Dmitry Timoshkov wrote:
Well, a manifest is just an text (.xml) file with the resource type set
to RT_MANIFEST. Adding it into the resources is easy, the problem is that
wrc doesn't support that kind of a resource, so that support should be
added to wrc first.
RT_MANIFEST is 24. Adding a resource of type 24, ID 1, should suffice;
no special handling in wrc should be needed.
E.g.:
1 24 myapplication.manifest
or:
1 24
{
assembly ...
/assembly
}
f-r-
Re: WineD3D: paletted texture emulation using fragment shaders
On 16.12.2006 22:24, Roderick Colenbrander wrote: +MUL index.x, index.x, constants.x;\n /* Scale the index by 255/256 */ +ADD index.x, index.x, constants.y;\n /* Add a bias of '0.5' in order to sample in the middle */ FWIW, this can be conflated to MAD index.x, index.x, constants.x, constants.y;. -f.r.
Re: mshtml #5: Set default print template in exec_print.
On 14.12.2006 09:10, Jacek Caban wrote: Could it be you forgot to submit the .rc file changes for these new strings? .rc changes are in an other patch: http://www.winehq.org/pipermail/wine-patches/2006-December/033782.html Ah sorry, didn't notice. -f.r. signature.asc Description: OpenPGP digital signature
Re: mshtml #5: Set default print template in exec_print.
On 14.12.2006 00:21, Jacek Caban wrote: --- a/dlls/mshtml/resource.h +++ b/dlls/mshtml/resource.h @@ -28,6 +28,9 @@ #define IDS_MESSAGE_BOX_TITLE 2213 +#define IDS_PRINT_HEADER_TEMPLATE 8403 +#define IDS_PRINT_FOOTER_TEMPLATE 8404 + Could it be you forgot to submit the .rc file changes for these new strings? -f.r.
Re: winemenubuilder: Write truecolor icons as PNGs
On 06.12.2006 20:01, Francois Gouget wrote: I'm pretty sure my memory mangled some of this. Hopefully Alexandre will clarify things. Yeah, I'm also wondering how an acceptable PNG icon support would look like. -f.r.
Re: Help needed on an SHGetFileInfoW() crash
On 04.12.2006 19:20, Francois Gouget wrote: Any idea? FWIW, maybe you need an IExtractIcon that does not work on a pidl but only on a filename and file attributes. So if the attribute is a folder, return the folder icon. Else get the default icon for that particular file type. Maybe the existing IExtractIcon could even be extended for that. -f.r.
Re: winemenubuilder: Look for supported color depths icons only. [resend]
On 30.11.2006 01:54, Vitaliy Margolen wrote: Remove all the code simplification. This patch fixes icon extraction for most steam games. All HL2 based games have .ico file with 32-bit colors. Since we don't support those, Or write the icons as PNGs. -f.r.
Re: winemenubuilder: Look for supported color depths icons only. [resend]
On 30.11.2006 02:46, Frank Richter wrote: On 30.11.2006 01:54, Vitaliy Margolen wrote: Remove all the code simplification. This patch fixes icon extraction for most steam games. All HL2 based games have .ico file with 32-bit colors. Since we don't support those, Or write the icons as PNGs. The portland utils come with an utility to install icon resources: http://portland.freedesktop.org/xdg-utils-1.0/xdg-icon-resource.html That tool would also allow to take advantage of the fact that Windows icons usually have multiple resolutions (ie extract more than one size). The current XPM icon writer could still be used when backwards compatibility is needed. -f.r.
Re: winemenubuilder: Look for supported color depths icons only. [resend]
On 30.11.2006 03:29, Vitaliy Margolen wrote: Frank Richter wrote: On 30.11.2006 01:54, Vitaliy Margolen wrote: Remove all the code simplification. This patch fixes icon extraction for most steam games. All HL2 based games have .ico file with 32-bit colors. Since we don't support those, Or write the icons as PNGs. Right, tried that before. Those patch(es) were not applied. Any idea why? I tried to search gmane but did only find the original patches but no replies. -f.r.
Re: [2/8] wined3d: Select the right shader backend when creating the device
On 28.11.2006 09:48, H. Verbeet wrote: Another issue that comes up when trying to mix eg a software vertex shader with a hardware pixel shader is that you can't actually pass varyings from the software vertex shader to the hardware pixel shader. As far as I remember the fixed function pipeline basically passes texture coordinates through. This is at least one way to pass varyings to the FP... -f.r.
Re: [2/8] wined3d: Select the right shader backend when creating the device
On 27.11.2006 23:53, H. Verbeet wrote: Either way, you're not going to be using software vertex shaders together with HW pixel shaders, that's just silly. Fun fact: a lot of Intel chips (up to the i945 I believe) have fragment program silicon but none for vertex programs - reality can be really silly sometimes. - Mixing ARB and GLSL backends is pretty silly as well. Why? I believe you can e.g. perfectly mix GLSL vertex programs together with multitexturing setups. So imo it just adds complexity to the code without giving much of a benefit. Not really. As Ivan said, VPs and FPs are separate concepts, and allowing the mixing of types probably leads to a more complete feature set in the end. -f.r.
Re: winhlp32 implementation
On 02.11.2006 22:04, Eric Pouech wrote: Kirill K. Smirnov wrote: Eric, there is a mess in winhelp and winhlp32 in Context and Topic concept: what winhelp calls topic, winhlp32 calls context, and what winhelp calls Context winhlp32 calls Topic without CNT section. So, the buttons are messed too. I suspect there are other features. We couldn't implement winhlp32 and winhelp in one box. well, this still could be possible, even if it's a bit more complex to handle IMO, the differences are, in most of the cases, cosmetics (name of buttons, positions of menu), but also in MS way, new features only in winhlp32 so I was calling for a unified tool that would be doing what the two original programs were doing, even if the user interface doesn't match everything perfectly FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work. -f.r.
Re: winhlp32 implementation
On 02.11.2006 22:04, Eric Pouech wrote: Kirill K. Smirnov wrote: Eric, there is a mess in winhelp and winhlp32 in Context and Topic concept: what winhelp calls topic, winhlp32 calls context, and what winhelp calls Context winhlp32 calls Topic without CNT section. So, the buttons are messed too. I suspect there are other features. We couldn't implement winhlp32 and winhelp in one box. well, this still could be possible, even if it's a bit more complex to handle IMO, the differences are, in most of the cases, cosmetics (name of buttons, positions of menu), but also in MS way, new features only in winhlp32 so I was calling for a unified tool that would be doing what the two original programs were doing, even if the user interface doesn't match everything perfectly FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work. -f.r.
Re: REGRESSION: 0.9.24 crashes on regsvr32 msvbvm60.dll, temporary workaround attached
On 29.10.2006 02:54, [EMAIL PROTECTED] wrote: Apparently, 0x2000 as a flag in FKCCIC indicates that pFuncRec-OptAttr[2] is a pointer to some string. If what little understanding I have of typelib loading is correct, these typelibs are read from DLL resources on disk. Therefore, I fail to grasp how they can possibly refer to valid memory locations. Hmm, perhaps check if interpreting the value as an offset from the start of the typelib data is sensible? -f.r.
Re: When to use SUBLANG_NEUTRAL
On 23.10.2006 02:50, Kai Blin wrote: On Saturday 21 October 2006 01:18, Mikołaj Zalewski wrote: As I wrote I've found that there is a mess in wine with the usage of SUBLANG_NEUTRAL and SUBLANG_DEFAULT. I tried to understand when to use which and wrote a wiki page about it: http://wiki.winehq.org/SublangNeutral . It contains some generic information about it but I thought that it would be best to have also a list of languages for each case. I've took the wine languages list and sorted the obvious cases. Actually there's now some differences for the German and Austrian sublang spellings of some words. I'm not sure how windows handles the new spelling rules used in Germany now, though. Judging from the wiki page, a German/Default resource would not be considered when looking e.g. for a German/Austria resource. Hence I'd use German/Neutral for most resources and add a specific resource like German/Austria or German/Swiss when there would be relevant differences in spelling or such. (A bit like English/US and English/UK, tho English/US is nevertheless special since it's a hardcoded fallback.) -f.r.
Re: [Tools/Wine.inf] Set Internet Explorer version
On 28.06.2006 21:03, Sven Paschukat wrote: Maarten Lankhorst schrieb: Windows seems to set internet explorer only during a new installation or upgrade of internet explorer, so I put it in wine.inf, which seemed appropriate. Changelog: Set version strings for Internet Explorer so programs dependent on it can install. This breaks installation of real IE. Setting version to IE 5.5 would give the users a chance to install at least version 6.0. With these keys: HKLM,SOFTWARE\Microsoft\Internet Explorer,Build,,62800.1106 HKLM,SOFTWARE\Microsoft\Internet Explorer,Version,,6.0.2800.1106 HKLM,SOFTWARE\Microsoft\Internet Explorer,W2kVersion,,6.0.2800.1106 ...IE6SP1 from microsoft.com still installs. So that would let programs that use these keys to detect the IE version to find an IE6 but also allow users to install MS' IE6. -f.r.
Re: Anybody have a RegDeleteTree[A|W] implementation lying around?
On 28.09.2006 15:26, Paul Vriens wrote: I'll have a few hours tomorrow and will have a look. The cleanest solution for now seems to create RegDeleteTree[A|W] in advapi32 and use that wherever possible (unless we find that it forwards to shlwapi). Most DLL's already import advapi32. Hmm... isn't advapi32 lower level than shlwapi? I'd expect that if forwarding takes place then it'd be shlwapi-advapi32. -f.r.
Re: H. Verbeet : wined3d: Add support for native NPOT textures.
On 27.09.2006 10:46, Alexandre Julliard wrote:
@@ -765,6 +768,12 @@ #undef USE_GL_FUNC
gl_info-max_sampler_stages = max(gl_info-max_samplers,
gl_info-max_texture_stages);
+/* We can only use NP2_NATIVE when the hardware supports it. */
+if (wined3d_settings.nonpower2_mode == NP2_NATIVE
!gl_info-supported[ARB_TEXTURE_NON_POWER_OF_TWO]) {
+WARN_(d3d_caps)(GL_ARB_texture_non_power_of_two not supported,
falling back to NP2_NONE NPOT mode.\n);
+wined3d_settings.nonpower2_mode = NP2_NONE;
+}
+
FYI, ATI r300+ hardware has some limited support for NP2 textures - that
is, 2D textures without mipmaps and repeat mode CLAMP. But since that
does not fulfill the ARB_tnpot requirements this extension isn't
published. Still, maybe you can exploit that feature somehow...
-f.r.
Re: Wine translations statistics
On 25.09.2006 13:29, Mikołaj Zalewski wrote: To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Nice one! I'll see if I can update some of the German resources. One thing I noticed is that the message table in kernel32 is treated as one resource in the statistics, although it contains quite a number of strings itself. Maybe wmc can be augmented with some --verify-translation equivalent as well... -f.r.
Re: Low-level coding
On 11.09.2006 15:24, Kuba Ober wrote: Correct me if I'm wrong, I could be looking at the wrong files :S. Are you looking at assembly files? Those have .S extension. Methinks you should focus on the C sources first, which have .c extension. :S might've been an emoticon here. -f.r.
Re: Jonathan Ernst : winecfg: French translation update.
On 10.09.2006 10:28, Alexandre Julliard wrote: -LTEXT This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version., +LTEXT Cette biblioth�que est un logiciel libre�; vous pouvez la redistribuer et/ou la modifier conform�ment aux dispositions de la Licence Publique G�n�rale GNU, telle que publi�e par la Free Software Foundation�; version 2.1 de la licence, ou encore (� votre choix) toute version ult�rieure. IDC_STATIC,119,44,124,72 It seems that all (L)GPL translations are marked unofficial by the FSF. That's why I though it wouldn't be bad to put in a translated This library is ... but keep the original English notice as well for the German translation. -f.r.
Re: shell32[1/2]: document the shell32 mini-COM functions
On 08.09.2006 21:11, Mikołaj Zalewski wrote: This patch adds the explanation why many shell32 functions are similar to ole32 ones - something I've been wondering for some time. It is not copied from MSDN. Maybe you've seen it already, but this blog post talks about the various allocators: http://blogs.msdn.com/oldnewthing/archive/2004/07/05/173226.aspx -f.r.
Re: [svrapi 2/2] realizes 3 functions of svrapi.dll
On 08.09.2006 17:20, Steven Edwards wrote: On 9/8/06, Alexandre Julliard [EMAIL PROTECTED] wrote: Since many people don't seem to understand this, from now on I'm going to reject all patches that add documentation, unless the submitter explicitly mentions that he didn't look at MSDN to write it. I'm sorry to penalize people who do the right thing, but I can't continue to waste time checking every single doc patch against MSDN. NOTE: When submitting documentation changes, you must clearly state that when creating your patch that you did not copy the function documentation from MSDN. When implementing a new function it is fine to look at the API documentation on MSDN however the api documentation must be written in your own words. Hm, but wouldn't didn't look at MSDN also include rewording? To reword something, you need to look at the original, after all. So in the strictest interpretation, it looks to me that only clean-room docs (infer the documentation by looking at the source code) would be acceptable. -f.r.
Re: [WINED3D 3/3] Add support for R32F and R16F texture formats
On 04.09.2006 07:33, Ivan Gyurdiev wrote: ... using: GL_ARB_texture_float GL_ARB_half_float_pixel The internal format is RGB16/32F, which is wasteful (2 unused colors), but there's no way around that. What about INTENSITY or LUMINANCE textures? -f.r.
Re: Adding L defines to include files ?
On 01.09.2006 09:43, Paul Vriens wrote: I've seen several occurrences of these in our own include files, so one should think there is no harm. You could look how e.g. the WC_* macros are defined in commctrl.h. -f.r.
Re: Add support for tooltips for system tray icons
On 25.08.2006 07:44, James Liggett wrote: +icon-tooltip = CreateWindowEx(WS_EX_TOPMOST, TOOLTIPS_CLASS, NULL, + WS_POPUP | TTS_NOPREFIX | TTS_ALWAYSTIP, + CW_USEDEFAULT, CW_USEDEFAULT, + CW_USEDEFAULT, CW_USEDEFAULT, + icon-window, NULL, NULL, NULL); Hm, wouldn't it be more economic to try to use one tooltip for all icons? -f.r.
Re: Add support for tooltips for system tray icons
On 25.08.2006 21:10, James Liggett wrote: On Fri, 2006-08-25 at 20:19 +0200, Frank Richter wrote: Hm, wouldn't it be more economic to try to use one tooltip for all icons? From a purely memory-consumption standpoint, yes. But there are still issues with that. One is that we'd have to handle every mouse event to see where the cursor is to make sure the tooltip had the right text for the right icon. AFAICS tooltip can contain multiple tools. Each tool is given a rectangle. So perhaps make one tool per icon, with matching rectangle? Second is the window-rectangle issue. the problem is that once a tray docks our icon, we basically don't own it, so we don't know exactly what the tray is going to do with it, and thus we don't know exactly where the window is going to be, and I don't see a viable way to find out. Is there no way to get notifications of window movements? At any rate, getting right rectangles seems crucial for tooltips to work properly. Thus, we need to have one tooltip per icon window for this to work. In fact, there's a small bug in my submitted patch. If you use it, start one program that uses a tray icon. Then start another program that uses an icon. Close out the first program so that only the second icon is left in the tray. You'll notice that the tooltip for this remaining icon doesn't work anymore, because the window's rectangle changed behind Explorer's back. My current solution is to associate tooltips with whole windows (using the TTF_IDISHWND flag in the TTTOOLINFO.uFlags parameter) instead of rectangular areas. This way, icons' tooltips continue to function even if their positions in the tray are changed. How does the tooltip track the correct rect then? If it can do it, you can, too. -f.r. signature.asc Description: OpenPGP digital signature
Re: FEAR Combat
On 25.08.2006 00:11, Frank Richter wrote: The problem is probably that a game installer may rely on the DX redistributable package to install those DLLs. I don't know if that runs on Wine, but if it doesn't, well, the DLL won't get where it should, too. FIY, my last three patches fix some issues that actually allow the redistributable installer(http://www.microsoft.com/downloads/details.aspx?FamilyID=a1788990-5e11-4ae2-b5e7-cc576822aed4DisplayLang=en) to succeed. This will also install the d3dx_XX DLLs, so technically, these DLLs are available to apps on Wine through that way. -f.r.
Re: FEAR Combat
On 24.08.2006 10:04, Andreas Mohr wrote: Hi, On Wed, Aug 23, 2006 at 10:04:01PM -0500, EA Durbin wrote: Also I've read that managed directx .dlls are supposed to be installed in the global assembly cache folder (C:\WINDOWS\assembly\GAC), but wine doesn't implement assemblies yet (Sxs.dll) as outlined in bug 5965. What you wanted to say is that due to Wine not implementing assemblies and/or the GAC directory not existing yet possibly the game installer doesn't install these DLLs yet, right? Could someone verify whether this is the case? (does the installer package contain strings for those DirectX DLLs?) I don't think this is the case. The d3dx9_XX DLLs aren't managed code, and they don't belong into any GAC directory anyway, just into plain ol' windows\system[32]. The problem is probably that a game installer may rely on the DX redistributable package to install those DLLs. I don't know if that runs on Wine, but if it doesn't, well, the DLL won't get where it should, too. -f.r.
Re: WineD3D: gpu detection
On 19.08.2006 00:09, Roderick Colenbrander wrote:
+} else if(WINE_D3D8_CAPABLE(gl_info)) {
+if (strstr(gl_info-gl_renderer, GeForce4 Ti) ||
strstr(gl_info-gl_renderer, Quadro4))
+gl_info-gl_card = CARD_NVIDIA_GEFORCE4_TI4200; /*
Geforce4 Ti4200/Ti4400/Ti4600/Ti4800, Quadro4 */
+else if (strstr(gl_info-gl_renderer, GeForce4 MX))
+gl_info-gl_card = CARD_NVIDIA_GEFORCE4_MX; /*
MX420/MX440/MX460/MX4000 */
Small note: GeForce4 MX is not a DX8 capable card. It's a souped-up
GeForce2 MX and labelled 4 for marketing reasons. So perhaps move that
check into the DX7 branch.
-f.r.
