Re: [Fwd: Re: French LTEXT correction]
Hello, On lun, 2008-01-07 at 08:54 +0100, Jonathan Ernst wrote: From: Vincent Hardy [EMAIL PROTECTED] Date: Mon, 07 Jan 2008 08:45:19 +0100 Jonathan Ernst a écrit : On ven, 2008-01-04 at 11:24 +0100, Vincent Hardy wrote: Regedit displays Rechercher::. Now Regedit displays Rechercher : and so on... It doesn't here (?). Furthermore in French : should be preceded by an unbreakable space (like it's the case now) and not a normal space. Thank you for your explanation. Nevertheless, it is not normal ::. See capture... As I said, I don't have this problem here. We first have to understand why you have a different rendering than mine. What is your locale ? (I have fr_CH.UTF-8) Is it a font problem (missing nbsp; character) ? Does someone else here know about the difference we are seeing and how to fix it properly ? (sorry for my poor english, I'm french speaking) So do I, don't worry. Best regards. Jonathan attachment: me.png
Re: Can't figure out how to link a program
Dear Alexandre, Thank you for your response. With that little information I was able to get my entire system working. Two or three very simple examples showing all the steps in the docs would be worth their weight in gold and would be so easy to do. It's also a shame I had to send the inquiry through three different channels before getting an answer. Thank you very much for your quick response. I t made all the difference. Respectfully, Blake McBride Alexandre Julliard wrote: Blake McBride [EMAIL PROTECTED] writes: I apologize for bothering you with this. I have tried getting an answer to this on comp.emulators.ms-windows.wine and on wine-devel@winehq.org without any responses. Actually, I am quite surprised that neither is this information available in the documentation, the examples, nor the faq. It seems like being able to compile and link a simple hello-world program without all kinds of convoluted / cygwin compatible / shared library wrapper stuff is either impossible or a deeply guarded secret. I used to use Willows and everything build cleanly and simply. Basically I'm just trying to compile a C program that uses the Win32 API. I would think there would be some simple way of compiling with your include files and linking with your libraries in a straight forward and simple way (like every other development system). There is, you have to use winegcc instead of plain gcc. It does all the magic for you.
Fwd: [alkyproject-announce] End of an era
Forwarding in case this might be useful to anyone here. -- Forwarded message -- From: Cody Brocious [EMAIL PROTECTED] Date: Jan 7, 2008 3:46 AM Subject: [alkyproject-announce] End of an era To: [EMAIL PROTECTED] It is with great sadness that I announce the closing of Falling Leaf Systems, LLC. We set out over a year ago to provide users of both old and unsupported as well as alternative Operating Systems the ability to run the latest games for the PC. Unfortunately, Falling Leaf Systems was unable to achieve that goal. However, every ending tends to open another door for opportunity and though we are saddened to announce our departure, we are almost as excited to announce the immediate availability of ALL source code for the Alky Project! It is licensed under the LGPL and includes both the orginal Alky Converter source used to convert the popular Prey Demo to run on OSX and Linux, as well as the alpha release of the Alky Compatibility Libraries which attempted to provide a DirectX10 compatible runtime for Windows XP. All of this is available at http://www.fallingleafsystems.com/ We have also created some new forums on the site for users to discuss the coming cycle of DirectX 10 based games. We hope that you'll pop in there from time to time, and we also hope you join our mailing list to receive an announcement in case some other Open Source project decides to carry on the Alky banner. We appreciate all your past support; Happy gaming! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Alky Project Announcements group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/alkyproject-announce?hl=en -~--~~~~--~~--~--~--- -- Vincent Povirk
Re: d3dx implementation senseless?
Am Montag, 7. Januar 2008 07:29:48 schrieb Maarten Lankhorst: [EMAIL PROTECTED] schreef: Since everybody agrees that we need a built-in d3dx9, we could begin to implement it. In the last talk about it, no plan was found to implement it: does one create a wined3dx or implement on the top of the last d3dx9 dll? So, I think that a definitive answer should be given very quickly. David As far as I read, we decided to create the dlls/d3dx9_** directories, use the latest one for all the code and forward all calls from older dlls to this one. However, I don't think that it is a problem if a dll contains more functions than the native dll, so we could also just use 12 (sth. around that) copies of the same dll. And about starting development: I have already began to implement the D3DXRenderToSurface interface, but I'm new to COM programming so the progress is quite slow, so I'd recommend someone other to do the base of the dll. A suggestion I'd like to do is a message that Wine should print out when a program wants to use the d3dx9 dll, sth. like: MESSAGE(The application you want to run makes use of the D3DX9 library!n); MESSAGE(tIts implementation under Wine is very young and far away from complete.n); MESSAGE(tYou may be better off using a native d3dx9_24.dll file.n); Just copy the DllMain from sfc/sfc_main.c for example. Just make WINE_DLL_PREATTACH return FALSE and wine will prefer the native version if available
Re: Can't figure out how to link a program
Blake McBride [EMAIL PROTECTED] writes: Thank you for your response. With that little information I was able to get my entire system working. Two or three very simple examples showing all the steps in the docs would be worth their weight in gold and would be so easy to do. Patches are welcome... -- Alexandre Julliard [EMAIL PROTECTED]
Fwd: [alkyproject-announce] End of an era
Can that code be used in wine? the DX implementation could help I think
Re: d3dx implementation senseless?
Okay, I have a bit time now and tomorrow, so I'll probably have submitted a basic d3dx9 dll patch until Wednesday. So I'll create a new d3dx9 directory inside dlls, but I'm not that familiar with Wine's makefile system (not very much with makefiles in general honestly), so can anyone tell me how to tell make that it should create several copies of our dll?
Re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
Michal Piaskowski [EMAIL PROTECTED] writes: Hi! This is my first patch for wine. It fixes bug 824. The problem is that wine stores REG_MULTI_SZ as null terminated string and sometimes looses information about data length. Without this information wine can't tell if the original string was null terminated or not. I don't think a non null-terminated MULTI_SZ string is very useful. Do you really have an app that depends on this? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [Fwd: Re: French LTEXT correction]
Jonathan Ernst a écrit : Hello, On lun, 2008-01-07 at 08:54 +0100, Jonathan Ernst wrote: From: Vincent Hardy [EMAIL PROTECTED] Date: Mon, 07 Jan 2008 08:45:19 +0100 Jonathan Ernst a écrit : On ven, 2008-01-04 at 11:24 +0100, Vincent Hardy wrote: Regedit displays Rechercher::. Now Regedit displays Rechercher : and so on... It doesn't here (?). Furthermore in French : should be preceded by an unbreakable space (like it's the case now) and not a normal space. Thank you for your explanation. Nevertheless, it is not normal ::. See capture... As I said, I don't have this problem here. We first have to understand why you have a different rendering than mine. What is your locale ? (I have fr_CH.UTF-8) I have fr_BE.UTF-8 (on gentoo) Is it a font problem (missing nbsp; character) ? Does someone else here know about the difference we are seeing and how to fix it properly ? (sorry for my poor english, I'm french speaking) So do I, don't worry. Best regards. Jonathan
Re: dlls/kernel32/task.c -- minor improvement
Alexandre Julliard wrote: Gerald Pfeifer [EMAIL PROTECTED] writes: Index: dlls/kernel32/task.c === RCS file: /home/wine/wine/dlls/kernel32/task.c,v retrieving revision 1.2 diff -u -3 -p -r1.2 task.c --- dlls/kernel32/task.c 13 Oct 2006 10:27:19 - 1.2 +++ dlls/kernel32/task.c 3 Jan 2008 21:33:44 - @@ -57,7 +57,7 @@ typedef struct WORD magic; /* Thunks signature */ WORD unused; WORD free; /* Head of the free list */ -WORD thunks[4]; /* Each thunk is 4 words long */ +WORD thunks[]; /* Each thunk is 4 words long */ } THUNKS; That syntax is not portable. We have the ANYSIZE_ARRAY macro in include/winnt.h for this exact purpose. -- Rob Shearman
Re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
Michal Piaskowski [EMAIL PROTECTED] writes: I don't know of any such application. It's just an old bug and one of very few bugs marked as tasklets. And it seemed very easy to fix, so i tried fixing it. Plus it's different from the way windows XP does it. If you think it should stay the way it is now, maybe it should be resolved with WONTFIX? I'm not opposed to fixing it, but changing all strings to hex format is not a good solution, it makes the file much harder to read and modify. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
I don't know of any such application. It's just an old bug and one of very few bugs marked as tasklets. And it seemed very easy to fix, so i tried fixing it. Plus it's different from the way windows XP does it. If you think it should stay the way it is now, maybe it should be resolved with WONTFIX? -- Michał Piaskowski On Jan 7, 2008 6:11 PM, Alexandre Julliard [EMAIL PROTECTED] wrote: Michal Piaskowski [EMAIL PROTECTED] writes: Hi! This is my first patch for wine. It fixes bug 824. The problem is that wine stores REG_MULTI_SZ as null terminated string and sometimes looses information about data length. Without this information wine can't tell if the original string was null terminated or not. I don't think a non null-terminated MULTI_SZ string is very useful. Do you really have an app that depends on this? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Fwd: [alkyproject-announce] End of an era
Am Montag, 7. Januar 2008 15:46:43 schrieb Marco da Silva: Can that code be used in wine? the DX implementation could help I think Not really, no. I had a quick look at it, and it is at best a hello world implementation. Looking at their D3D10 implementation, it is comparable to Andras' soc code, with the difference that Alky has a few lines to create a gl context and send off vertices, but Andras has written a D3D10.idl header. Adding the functionality of Alky to Andras' code is a matter of hours, if we do it the hacky way. So all in all I think that the not yet integrated d3d10 that Wine has is more advanced. (Andras: Do you plan to continue working on that somewhen?) As far as other libraries go, there isn't much to see either. D3D9 isn't even comparable to the very first out-of-tree patch Oliver put onto Sourceforge years ago. No handling for stateblocks or shaders, no proper texture handling, no vertex arrays, etc. The other libraries are in a similar state. D3DX has a few math functions implemented, but we have all of that already thanks to David and the other D3DX hackers. While the code may not be of any use for us(or anyone else, since Wine exists), Cody seems to have written a lot of code. It might not be comparable to Wine, which has enjoyed the work of almost thousand developers and is almost 15 years old, it seems to be quite some accomplishment for a project which has been developed by apparently one(two?) persons. (I have no comparison how Wine started though. I only had a Gameboy back then :-) ) And kudos to them for releasing the source!
re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
Alexandre wrote: I don't think a non null-terminated MULTI_SZ string is very useful. Do you really have an app that depends on this? http://www.xpregistrycleaner.com/embedded-null-characters/ claims some software vendors use the embedded-null registry key technique as a way to enforce the software license agreement and to reduce the ability of users to tamper with the license information stored in these registry keys. http://forum.sysinternals.com/forum_posts.asp?TID=6030 claims iuVCR (www.iulabs.com) 4.11.0.374 might be such an app. http://forum.sysinternals.com/forum_posts.asp?TID=2628 says The Aladdin Privilege Software Commerce Platform (SCP) may be a common denominator for instances of Registry keys with embedded nulls detected by RKR. ... [One app that seemed to use them was] a free trial of Adobe Acrobat Professional 6.0. http://forum.sysinternals.com/forum_posts.asp?TID=8882PN=1 mentions that Windows itself uses keys with trailing nulls for some things. And of course there's all that splendid malware. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
Dan Kegel [EMAIL PROTECTED] writes: Alexandre wrote: I don't think a non null-terminated MULTI_SZ string is very useful. Do you really have an app that depends on this? http://www.xpregistrycleaner.com/embedded-null-characters/ claims some software vendors use the embedded-null registry key technique as a way to enforce the software license agreement and to reduce the ability of users to tamper with the license information stored in these registry keys. Embedded nulls should work just fine. The case that doesn't work is string values that aren't properly null-terminated. -- Alexandre Julliard [EMAIL PROTECTED]
Dead in the water because of bug 11080
Today's git (or perhaps Friday's?) seems to cause every oldish microsoft runtime installer to fail; see http://bugs.winehq.org/show_bug.cgi?id=11080 This makes it kind of hard for me to verify my old bugs.
Re: [PATCH] Fix REG_MULTI_SZ save fromat - bug 824
Michal Piaskowski [EMAIL PROTECTED] writes: I think it can be done without changing every string to hex. How about adding \0 at the end of every null terminated sting, and \0\0 at the end of proper REG_MULTI_SZ value which should end with an empty string? It would work, but this can't be changed now, the file format needs to remain backwards compatible. It turns out that it's fairly easy to use hex format only for non-terminated strings, I put in a fix. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Commit stats
Hans Leidekker wrote:
$ for y in {2002..2007}; do \
n=$( git log | grep ^Date: | grep $y | wc -l ); \
echo Number of commits in $y: $n; \
done
Number of commits in 2002: 3094
Number of commits in 2003: 3283
Number of commits in 2004: 3851
Number of commits in 2005: 6006
Number of commits in 2006: 8431
Number of commits in 2007: 9526
Got reminded but by the WWN that i wanted to send the numbers of authors.
$ for y in `seq 2002 2007`; do
echo -n Number of authors in $y:
git shortlog -s --since=$y-01-01 00:00 --until=$y-12-31 24:00 |
wc -l
done
Number of authors in 2002: 185
Number of authors in 2003: 167
Number of authors in 2004: 183
Number of authors in 2005: 212
Number of authors in 2006: 195
Number of authors in 2007: 218
bye
michael
signature.asc
Description: OpenPGP digital signature
Re: Dead in the water because of bug 11080
On Jan 7, 2008 4:02 PM, Dan Kegel [EMAIL PROTECTED] wrote: Today's git (or perhaps Friday's?) seems to cause every oldish microsoft runtime installer to fail; see http://bugs.winehq.org/show_bug.cgi?id=11080 This makes it kind of hard for me to verify my old bugs. It's fixed in current git.
Re: question about fixing D3DRENDERSTATE_TEXTUREMAPBLEND
Am Montag, 7. Januar 2008 07:55:08 schrieb Alexander Dorofeyev: D3DTBLEND_MODULATE Modulate texture-blending is supported. In this mode, the RGB values of the texture are multiplied with the RGB values that would have been used with no texturing. Any alpha values in the texture replace the alpha values that would have been used with no texturing. D3DTA_TEXTURE has a somewhat strange behavior. If no texture is set, it behaves like D3DTA_PREVIOUS. Perhaps for alphaarg it behaves similarly if there is a texture, but it has no alpha. If that is the case, then I think it matches what you need for D3DTBLEND_MODULATE. Otherwise I think a private value like your D3DTOP_DX6MODULATE is the only way. So I'd say test how D3DTA_TEXTURE should behave, maybe we implement it incorrectly at the moment.
Re: Spelling fixes - round 6
Hi Austin, -case 0x32: /* ENABLE/DISABLE VIDEO ADDRERSSING */ +case 0x32: /* ENABLE/DISABLE VIDEO ADDRRESSING */ That's still misspelled. - * special virtualalloc, allocates lineary monoton growing memory. + * special virtualalloc, allocates linear monoton growing memory. Monoton isn't a word. Monotone is, as is monotonic, and monotonically, which is probably what's meant. -/* Volume functions derived from Alsaplayer source */ +/* Volume functions derivated from Alsaplayer source */ This change doesn't look correct to me. --Juan
Re: Spelling fixes - round 6
On Jan 7, 2008 11:57 PM, Juan Lang [EMAIL PROTECTED] wrote: Hi Austin, -case 0x32: /* ENABLE/DISABLE VIDEO ADDRERSSING */ +case 0x32: /* ENABLE/DISABLE VIDEO ADDRRESSING */ That's still misspelled. Thanks for catching that/these. After looking at all these misspellings, some of the incorrect start to look correct. I've got a replacement patch ready, this time triple checked :-). - * special virtualalloc, allocates lineary monoton growing memory. + * special virtualalloc, allocates linear monoton growing memory. Monoton isn't a word. Monotone is, as is monotonic, and monotonically, which is probably what's meant. I changed it to monotonically. I wasn't sure what it meant, I was correcting linear. -/* Volume functions derived from Alsaplayer source */ +/* Volume functions derivated from Alsaplayer source */ This change doesn't look correct to me. There was one correct and one incorrect spelling. I apparently switched around my find and replace on that one. I fixed this as well. I'm sending a replacement patch now. Sorry for the mistake. I'll be more careful in the future. -Austin
re: Spelling fixes - round 6
A few issues: 1. * DPMI_xalloc - * special virtualalloc, allocates lineary monoton growing memory. + * special virtualalloc, allocates linear monoton growing memory. Um... Probably should be 'linearly'. But if you're opening the can of worms, might as well really improve it. I suspect this would be better: * DPMI_xalloc - * special virtualalloc, allocates lineary monoton growing memory. + * Try to VirtualAlloc the len bytes just past the last block we allocated + * If that's not available, try 64K beyond; if still not available, fail. 2. -/* Volume functions derived from Alsaplayer source */ +/* Volume functions derivated from Alsaplayer source */ What? What's wrong with derived? Derivated isn't even a word?! 3. -# include unistd.h +#include unistd.h That's not a spelling fix, and you would have to fix a whole lot of those. Best leave alone. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
