[PATCH] fix tools/c2man.pl perl syntax
Fellas,
tools/c2man.pl have buggy pieca code which work only for accident
reasons. The patch fixes perl syntax for upcoming perl-5.8.9 who
ain't not gonna tolerate the buggy pieca coda.
http://www.nntp.perl.org/group/perl.perl5.porters/119879
http://www.nntp.perl.org/group/perl.perl5.porters/119881
http://www.nntp.perl.org/group/perl.perl5.porters/119882
http://www.nntp.perl.org/group/perl.perl5.porters/119883
--- tools/c2man.pl- 2006-12-24 00:17:04 +
+++ tools/c2man.pl 2007-01-12 07:13:05 +
@@ -627,7 +627,7 @@ sub process_comment($)
# When the function is exported twice we have the second name below the first
# (you see this a lot in ntdll, but also in some other places).
- my $first_line = [EMAIL PROTECTED]>{TEXT}}}[1];
+ my $first_line = $comment->{TEXT}[1];
if ( $first_line =~ /^(@|[A-Za-z0-9_]+)
+(\(|\[)([A-Za-z0-9_]+)\.(([0-9]+)|@)(\)|\])$/ )
{
@@ -642,14 +642,14 @@ sub process_comment($)
my $alt_export = @{$spec_details->{EXPORTS}}[$alt_index];
@$alt_export[4] |= $FLAG_DOCUMENTED;
$spec_details->{NUM_DOCS}++;
- [EMAIL PROTECTED]>{TEXT}}}[1] = "";
+ $comment->{TEXT}[1] = "";
}
}
if (@{$spec_details->{CURRENT_EXTRA}})
{
# We have an extra comment that might be related to this one
-my $current_comment = [EMAIL PROTECTED]>{CURRENT_EXTRA}}}[0];
+my $current_comment = $spec_details->{CURRENT_EXTRA}[0];
my $current_name = $current_comment->{COMMENT_NAME};
if ($comment->{COMMENT_NAME} =~ /^$current_name/ &&
$comment->{COMMENT_NAME} ne $current_name)
{
@@ -986,7 +986,7 @@ sub process_extra_comment($)
if (@{$spec_details->{CURRENT_EXTRA}})
{
-my $current_comment = [EMAIL PROTECTED]>{CURRENT_EXTRA}}}[0];
+my $current_comment = $spec_details->{CURRENT_EXTRA}[0];
if ($opt_verbose > 0)
{
@@ -1072,7 +1072,7 @@ sub process_index_files()
if (@{$spec_details->{CURRENT_EXTRA}})
{
# We have an unwritten extra comment, write it
-my $current_comment = [EMAIL PROTECTED]>{CURRENT_EXTRA}}}[0];
+my $current_comment = $spec_details->{CURRENT_EXTRA}[0];
process_extra_comment($current_comment);
@{$spec_details->{CURRENT_EXTRA}} = ();
}
@@ -1468,7 +1468,7 @@ sub output_api_synopsis($)
my $biggest_length = 0;
for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++)
{
-my $line = [EMAIL PROTECTED]>{PROTOTYPE}}}[$i];
+my $line = $comment->{PROTOTYPE}[$i];
if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/)
{
my $length = length $1;
@@ -1482,19 +1482,19 @@ sub output_api_synopsis($)
# Now pad the string with blanks
for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++)
{
-my $line = [EMAIL PROTECTED]>{PROTOTYPE}}}[$i];
+my $line = $comment->{PROTOTYPE}[$i];
if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/)
{
my $pad_len = $biggest_length - length $1;
my $padding = " " x ($pad_len);
- [EMAIL PROTECTED]>{PROTOTYPE}}}[$i] = $1.$padding.$2;
+ $comment->{PROTOTYPE}[$i] = $1.$padding.$2;
}
}
for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++)
{
# Format the parameter name
-my $line = [EMAIL PROTECTED]>{PROTOTYPE}}}[$i];
+my $line = $comment->{PROTOTYPE}[$i];
my $comma = ($i == @{$comment->{PROTOTYPE}}-1) ? "" : ",";
$line =~ s/(.+?)([A-Za-z_][A-Za-z_0-9]*)$/
$fmt[0]$1$fmt[2]$2$fmt[3]$comma$fmt[1]/;
print OUTPUT $line;
pgpKOOP2tuVeI.pgp
Description: PGP signature
Re: OpenGL in child windows
I have to ask, is there a reason each thread uses its own display connection (which are all different from gdi_display), and leaves the window data to only be available from the thread the window was created in? Besides the aforementioned problem with the GL context, I'd imagine it would be problematic even in current Wine.. for example, if something creates a window in one thread, passes it to another, then kills the thread it was originally created in while still using the window. In MS Windows, windows die if the creating thread exits for any reason.
Re: wine kills X
The debian answer is a linking method that allows mesa to live on and for the nvidia driver to have everything it's own way. In theory and practice I've found it to be a very good solution with two big draw backs: the mess created by either system makes it a night mare to remove one in place of the other and it takes them a good while to update to each new release of the driver due to the testing required. Some people choose to use the package; others don't... Install instructions are available on the debian wiki. Also I've had a number of odd problems with directx and wine over the last two weeks. Including a very strange one where the second time I run the application it's speed is slower than an ant in the range of 0.7fps instead of the normal 10fps - furthermore it's ability to grab data seems to also be slowed. This is all while using the same resources that the application does at full speed. I'm forced to restart my xserver every time I wish to play it (which is twice a day) and if I don't I can kill X or even lock up my system. Though I've been unable to work out the cause beyond 'it's probably some thing to do with the nvidia driver'. If some one could offer a some debugging advice on what I should be looking for it'd be very nice. System is Debian sid 6600gt (have tested with the last three drivers) amd 2400+ On 1/10/07, Kuba Ober <[EMAIL PROTECTED]> wrote: > My system is: > Athlon XP 2700 > NVIDIA GPU GeForce4 Ti 4200 (with NVIDIA driver version 1.0-9631) > Debian Etch > > Last system modification was an update of the debian system with the > availabe patches on 05.01.2007. This is most probably the root of the > problem. Isn't there a "sister" package repository somewhere that would have the NVidia drivers that install in a package-controlled way, and update automatically with the rest of stuff? Livna provides that for RedHat/Fedora distros and it solved it for me (not having to reinstall drivers after every update). Cheers, KUba
Re: [PATCH 1/1] msi: MsiGetPropertyA return wrong length when called from a custom action.
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
This is a hack, however the correct way to achieve bug compatiblity is
complicated.
MSI should run custom actions in a separate process and communicate with
the main installer process via COM. This is quite a lot of work which
needs to be done anyway, but this patch will make us bug compatible with
Microsoft's implementation in the mean time.
Furthermore, writing a test case for this behavior requires adding a dll
contain custom action code to the dlls/msi/tests directory. I can
supply an MSVC project showing the problem.
See bug 5768 (http://bugs.winehq.org/show_bug.cgi?id=5768) for more details.
Does behaviour of MsiGetPropertyA and MsiGetPropertyW differ in that case?
I'd be interested to have a look at the test case.
--- a/dlls/msi/custom.c
+++ b/dlls/msi/custom.c
@@ -439,6 +439,8 @@ static DWORD WINAPI ACTION_CallDllFunction(thread_struct
*stuff)
TRACE("calling function (%s, %s)\n", debugstr_w(stuff->source),
debugstr_w(stuff->target));
+TlsSetValue( tls_slot, (void*) 1 );
Shouldn't this be reset to 0 once a custom action has finished?
--
Dmitry.
Re: dsound/tests: The tests link with dsound.dll so use GetModuleHandle() instead of LoadLibrary().
On Thu, 11 Jan 2007, Felix Nawothnig wrote: [...] > No it's not, that causes test failure on native when DirectX is not installed > (NT4 out-of-the-box I believe?). How can the DirectSound tests not be linked with dsound.dll on Windows? They sure are on Linux as shown by the Makefile.in: IMPORTS = dsound ole32 version user32 kernel32 Not only that, but ds3d.c makes a direct call to DirectSoundEnumerateA(). So even if msvcmaker ignored it when generating the dsp files, it would still fail to link unless it also disabled a bunch of tests. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Re: GreenVille font, is it still available? I have a question about it.
Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis Wierd_w <[EMAIL PROTECTED]> wrote: --- "Louis. Lenders" wrote: > Hi, i got your email address from one of the Reactos > developers. AFAIK you have been working on a Tahoma > compatible font called Greenville. I was wondering > if you still have it, and if you were willing to > license this LGPL, so that it could be included in > Wine project. Sure I could. I would be happy to release the glyphset that I have started on, but the reason I never finished the project was because of "Differences" between the rasterizers in FreeType and MS Windows. These differences would have required me to learn native truetype assembler to resolve, because of (in my opinion) "overzealous" freetype developers attempting to take full advantage of the hint system's tolerances. (Better explanation: MS Windows' rasterizer only blends to 16 shades of grey, instead of the theoretical maximum of 256 shades. There is a REASON for doing this: Namely, it makes it possible for visual hinting systems, like the software that I used to work on Greenville, to produce a visually high-quality font, without using exact binary precision with the use of hinting instructions; It allows for a degree of "leniency" in the rasterizer's interperetation of a glyph outline. Because Freetype wants to use the full theoretical maximum to achieve more shades of grey, you must be "Spot on dead on the money" accurate with the use of hinting instructions, or else the font will have 'blurry' edges. Throw into that the fact that the "Delta" instruction is patented by Apple computer corporation, and refuses to sell Freetype a license, it makes it VERY VERY VERY difficult to get Freetype to even render the glyph even kind-of correctly to begin with. It is possible to 'patch' freetype to turn off some of this overzealousness, and even to turn on the native bytecode interpereter-- but even then the test case TTF files I generated (that look just fine in windows) look asthetically gut-wrenching in freetype.) After spending 6 months trying (and failing) to resolve these internal rendering troubles, (and even considering the implementation of Scalar Bitmaps (SBIT)data so that I wouldnt HAVE to mess with Freetype's CRAP, and ending up with a 600kb font file.) I decided that enough was enough. Since the software that I used was VERY expensive (over 300$ US for the STUDENT DISCOUNTED version), and uses a proprietary working format, I would instead be happy to send you the glyph metrics and kerning data in Adobe format, and the actual Glyph set in your choice of vector format. (Note, I spent 2 weeks looking for a suitable TTF editing suite from the freesoftware community (You know, one that would *gasp!* Run on windows, where I could quickly test the fonts!), and came up empty handed. this is why I shelled out the big bucks for FontLab. The Free Software community's gestalt predjudices have shot it in the foot this time.) The actual HINTING process would then be up to you, but be prepared to have your hair turn grey, and to develop ulcers. In order to achieve a strong level of clean resemblence to Tahoma, you *WILL* need to use Truetype, OR, a bitmapped font set. Adobe Type-1 fonts (God, so many tools for that in the FOSS community, but not a SINGLE ONE for TTF hints!...) will not be suitable, because they lack the necessary hinting control (Only stem and leaf, instead of Vector Node Deform, like TTF-- Means that round contours, like in the letter O or G, will NEVER be as clean in an adobe type-1, as they will be with TTF.) I am currently at the college, and dont have access to my software at the moment, but when I get home this evening I will begin cleaning up my old resources and packaging them. Any particular preference on a vector format? I CAN package the raw glyphs into an unhinted Adobe Type-1, but you will have to do a vector conversion to work on them as a TTF. That shouldnt be a problem though. Likewise, I could also send an unhinted TTF, with the kerning data allready merged. If one of these would be suitable, let me know, and if not-- please specify one. Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index - To help you stay safe and secure online, we've developed the all new Yahoo! Security Cen
Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
Christoph Frick wrote: > On Thu, Jan 11, 2007 at 10:25:51AM -0700, Vitaliy Margolen wrote: > >>> @@ -128,11 +122,20 @@ struct JoystickImpl >>> /* The 'parent' DInput */ >>> IDirectInputImpl *dinput; >>> >>> + /* autodetecting ranges per axe by following movement */ >>> + LONGhavemax[8]; >>> + LONGhavemin[8]; >> I could never understood why we need these? In other joystick_linux the >> range assumed to be 0 - 0x. > > linux/input.h reports us the proper ranges from the device. these > numbers will also be used as teh want(min|max). so what this numbers are > good for. apps that want the input as "pure" as it gets dont > SetProperty some something and just get what the hardware tells them > (e.g. RBR does so). What you described is SetProperty(DIPROP_RANGE). What I'm talking about is the range we get from device itself. In the map_axis we have: if (val > hmax) This->joydev->havemax[axis] = hmax = val; if (val < hmin) This->joydev->havemin[axis] = hmin = val; We either need to query the device for what it's ranges are, or use default range (as it's done in joystick_linux). Auto-detecting range will work only if you move joystick on all axes from min to max. And even then it still doesn't work here. I'm using joystick sample from DXSDK and it always shows 0-128-256 range for accelerator - brake pedals (as a combined Z axis). joystick_linux shows it correctly - 0..1000 (it sets this range for all axes). >>> +fake_current_js_state(newDevice); >> Can you explain what this suppose to do? Why do we need to "fake >> current state" everywhere? > > after e.g. SetProperties and initializing the device we have to put the > values of the DIJOYSTATE2 in a sane state. e.g. GPL set the ranges to > 1000-25k; where my pedals are in 0..512; so the app gets in the next > step after the setting a default value of 512 (clutch not pressed) and > gets nuts. > Right. But can we query device for the current axes position? They are analog devices, and should provide absolute position. Vitaliy.
Re: Looking for sound testers
On Thu, 28 Dec 2006 16:04:25 +0100 "Maarten Lankhorst" <[EMAIL PROTECTED]> wrote: > Hi all, > > I've forward ported the old patches of Davin McCall (dsound.patch). > With them I have no more sound underruns etc, I'm therefore looking > for other people to test them as well. I'm welcoming comments on how > it works and possible issues with it. > > I also attached my patch to alsa, I'm aware of the things I need to > fix for that, but I thought it might be good to test dsound with > winealsa, to see if other things still need to be fixed. > > Cheers, > > Maarten > Hello Maarten, I have installed your patchs on wine-0.9.29. I tested it with Warblade (www.warblade.as), an old fashioned shoot'em up, with which sound was very choppy. Your patches remove all buffer under run errors... but sound is still as choppy as it was. I tried both hardware acceleration and emulation but none work. i have alsa 1.0.14rc1 installed. Please let me know if you some more detailed informations. Thanks for your efforts anyways! Séb.
Re: gecko download busted?
Hello > trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302 > Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 > (Debian GNU/Linux)\r\nLocation: > http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConne >ction: close\r\nContent-Type: text/html\r\n\r\n" > > but no connection request to that new URL, and the cabextract failed. > > I guess I'll try with a newer wine once I get to the office... Sourceforge changed the mirror schema. The wine-gecko element is downloading correctly again since 0.9.29. -- Pozdrawiam Wojciech Arabczyk Administracja sieci -- home.pl - http://home.pl - [EMAIL PROTECTED] - 0801 88
Re: WineD3D: Fix my name
Hi Dmitry, On 11/01/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: I'd say that since converting resources to UTF-8 makes them not compatible with any other resource compiler except wrc, IMO that's a bad idea At least one free resource compiler that claims to support UTF-8: http://www.jorgon.freeserve.co.uk/#rc Also, there are not much editors in the Windows world that support UTF-8, since it's a multibyte encoding and in general is very cumbersome encoding to work with. Please don't do that. At least Notepad on Windows XP does support UTF-8. -- Ph.
Re: dsound/tests: The tests link with dsound.dll so use GetModuleHandle() instead of LoadLibrary().
Francois Gouget wrote:
This is a NOP, it just seems a bit cleaner to me.
-hDsound = LoadLibraryA("dsound.dll");
-if (!hDsound) {
-trace("dsound.dll not found\n");
-return;
-}
-
+hDsound = GetModuleHandleA("dsound.dll");
+ok(hDsound != NULL, "dsound.dll not loaded!\n");
No it's not, that causes test failure on native when DirectX is not
installed (NT4 out-of-the-box I believe?).
Re: Stub fro GetRawInputDeviceList
Michał Majchrowicz escreveu: Hi. I hope this time it is correct patch and will be accepted. Regards Michael. I think the spec file is incorrect. diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec index f857105..0517ebc 100644 --- a/dlls/user32/user32.spec +++ b/dlls/user32/user32.spec @@ -345,7 +345,7 @@ # @ stub GetRawInputData # @ stub GetRawInputDeviceInfoA # @ stub GetRawInputDeviceInfoW -# @ stub GetRawInputDeviceList +@ stub GetRawInputDeviceList maybe: @ stdcall GetRawInputDeviceList(ptr ptr long) # @ stub GetReasonTitleFromReasonCode # @ stub GetRegisteredRawInputDevices @ stdcall GetScrollBarInfo(long long ptr) diff --git a/include/winuser.h b/include/winuser.
WinZip regression
Hello, automated CxTest testing shows WinZip regression: Jan 8 - WinZip ran 9 times (5 Francois + 4 Jozef), all succeeded Jan 9 - WinZip ran 1 time (Francois), failed with http://www.cxtest.org/triage/failures?dl=364121 (Out of resources error, unable to continue) Jan 10 - WinZip ran 2 times (1 Francois + 1 Jozef), both failed with same screenshot So there is a regression between Jan 8 and Jan 9 - unfortunately, I do not know GIT_ID. Should I create bug for this? If you want to join Wine automated testing process, go to http://www.cxtest.org/download and install CxTest. Martin
Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
On Thu, Jan 11, 2007 at 10:25:51AM -0700, Vitaliy Margolen wrote:
> > @@ -128,11 +122,20 @@ struct JoystickImpl
> > /* The 'parent' DInput */
> > IDirectInputImpl *dinput;
> >
> > + /* autodetecting ranges per axe by following movement */
> > + LONGhavemax[8];
> > + LONGhavemin[8];
> I could never understood why we need these? In other joystick_linux the
> range assumed to be 0 - 0x.
linux/input.h reports us the proper ranges from the device. these
numbers will also be used as teh want(min|max). so what this numbers are
good for. apps that want the input as "pure" as it gets dont
SetProperty some something and just get what the hardware tells them
(e.g. RBR does so).
> > /* joystick private */
> > /* what range and deadzone the game wants */
> > - LONGwantmin[ABS_MAX];
> > - LONGwantmax[ABS_MAX];
> > - LONGdeadz[ABS_MAX];
> > + LONGwantmin[8];
> > + LONGwantmax[8];
> > + LONGdeadz[8];
> Can we move these into separate struct like it's done in
> joystick_linux? It's much cleaner end eventually will allow a better
> integration of two.
i will do this.
> And can you use spaces instead of tabs please?
of course
> > @@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid,
> > const void *jvt, IDirectInputIm
> > /* Supported Axis & POVs should map 1-to-1 */
> > for (i = 0; i < 8; i++)
> > {
> > -if (!test_bit(newDevice->joydev->absbits, i)) continue;
> > +if (!test_bit(newDevice->joydev->absbits, i)) {
> > + newDevice->axes[i] = -1;
> > + continue;
> > +}
> Can you please don't brake the good readable style? Please put that
> curly bracket into separate line, and use 4 space indentation.
sorry - to a K&R guy that uses ts=8 as default this all is unreadable
gibberish; i will try my best here.
> > +fake_current_js_state(newDevice);
> Can you explain what this suppose to do? Why do we need to "fake
> current state" everywhere?
after e.g. SetProperties and initializing the device we have to put the
values of the DIJOYSTATE2 in a sane state. e.g. GPL set the ranges to
1000-25k; where my pedals are in 0..512; so the app gets in the next
step after the setting a default value of 512 (clutch not pressed) and
gets nuts.
> > +int axe = This->axes[ie.code];
> It's an "axis" not an "axe" :)
it was 0300 and i guess i wished for an axe there ;)
--
cu
pgptmUBvH3A6e.pgp
Description: PGP signature
Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
Christoph Frick wrote:
> with Vitaliy's patches i tried my games yesterday and everything seemed
> ok (RBR works again). but my clutch on the wheel did not work and also
That's a good news. I was hopping not to brake too many things while
reorganizing the dinput.
> @@ -128,11 +122,20 @@ struct JoystickImpl
> /* The 'parent' DInput */
> IDirectInputImpl *dinput;
>
> + /* autodetecting ranges per axe by following movement */
> + LONGhavemax[8];
> + LONGhavemin[8];
I could never understood why we need these? In other joystick_linux the
range assumed to be 0 - 0x.
> /* joystick private */
> /* what range and deadzone the game wants */
> - LONGwantmin[ABS_MAX];
> - LONGwantmax[ABS_MAX];
> - LONGdeadz[ABS_MAX];
> + LONGwantmin[8];
> + LONGwantmax[8];
> + LONGdeadz[8];
Can we move these into separate struct like it's done in joystick_linux?
It's much cleaner end eventually will allow a better integration of two.
And can you use spaces instead of tabs please?
> @@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid, const
> void *jvt, IDirectInputIm
> /* Supported Axis & POVs should map 1-to-1 */
> for (i = 0; i < 8; i++)
> {
> -if (!test_bit(newDevice->joydev->absbits, i)) continue;
> +if (!test_bit(newDevice->joydev->absbits, i)) {
> + newDevice->axes[i] = -1;
> + continue;
> +}
Can you please don't brake the good readable style? Please put that
curly bracket into separate line, and use 4 space indentation.
> +fake_current_js_state(newDevice);
> +
Can you explain what this suppose to do? Why do we need to "fake current
state" everywhere?
> +int axe = This->axes[ie.code];
It's an "axis" not an "axe" :)
Vitaliy.
Re: gecko download busted?
Bill Medland wrote: > On Thu, 2007-11-01 at 07:56 -0800, Dan Kegel wrote: >> Wine-0.9.27's iexplore.exe isn't downloading gecko for me. >> It tries, but then gives up, and says html rendering is disabled. >> +wininet shows that it did connect to winehq.org and got >> a redirect to sourceforge: >> >> trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302 >> Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 >> (Debian GNU/Linux)\r\nLocation: >> http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConnection: >> close\r\nContent-Type: text/html\r\n\r\n" >> >> but no connection request to that new URL, and the cabextract failed. >> >> I guess I'll try with a newer wine once I get to the office... >> - Dan >> >> > Yes, I noticed that a couple of days ago. I thought it was just that I > hadn't been doing Wine recently. > > As I remember, it complained that the CAB was invalid. > > Bill > > > Works with 0.9.29. It seemed to be the same regression in ole that caused lots of installers to abort/hang. Vitaliy
Re: gecko download busted?
On Thu, 2007-11-01 at 07:56 -0800, Dan Kegel wrote: > Wine-0.9.27's iexplore.exe isn't downloading gecko for me. > It tries, but then gives up, and says html rendering is disabled. > +wininet shows that it did connect to winehq.org and got > a redirect to sourceforge: > > trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302 > Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 > (Debian GNU/Linux)\r\nLocation: > http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConnection: > close\r\nContent-Type: text/html\r\n\r\n" > > but no connection request to that new URL, and the cabextract failed. > > I guess I'll try with a newer wine once I get to the office... > - Dan > > Yes, I noticed that a couple of days ago. I thought it was just that I hadn't been doing Wine recently. As I remember, it complained that the CAB was invalid. Bill
gecko download busted?
Wine-0.9.27's iexplore.exe isn't downloading gecko for me. It tries, but then gives up, and says html rendering is disabled. +wininet shows that it did connect to winehq.org and got a redirect to sourceforge: trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302 Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 (Debian GNU/Linux)\r\nLocation: http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n" but no connection request to that new URL, and the cabextract failed. I guess I'll try with a newer wine once I get to the office... - Dan
Re: WineD3D: Fix my name
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > I'd say that since converting resources to UTF-8 makes them not compatible > with any other resource compiler except wrc, IMO that's a bad idea. I > personally > time from time edit Wine resources in Visual Studio and compile them with > rc.exe > from PSDK and Visual Studio for testing. Also, there are not much editors in > the Windows world that support UTF-8, since it's a multibyte encoding and in > general is very cumbersome encoding to work with. Please don't do that. Well, yes, you'd have to remember to run iconv on the file when you want to use it on Windows. OTOH it makes it easier to mail patches, and more importantly to detect when the encoding has been mangled by the mailer, which is IMO a more frequent operation than compiling them under Windows. -- Alexandre Julliard [EMAIL PROTECTED]
Re: WineD3D: Fix my name
Hi Dmitry, On 11/01/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > At least one free resource compiler that claims to support UTF-8: > http://www.jorgon.freeserve.co.uk/#rc Unfortunately it's not Microsoft's rc.exe, i.e. not something I'm interested to compare wrc output/compatibility with. Agreed. >> Also, there are not much editors in >> the Windows world that support UTF-8, since it's a multibyte encoding and in >> general is very cumbersome encoding to work with. Please don't do that. > > At least Notepad on Windows XP does support UTF-8. If that was supposed to be a joke I didn't buy it. No it was not a joke. I only tried to say that there is a UTF-8 enabled editor included in standard Windows distribution. If you don't like Notepad (yes, it's very limited) you can always find another editor (I use Vim in Windows as well as in Unices). In other words, your second reason to not switch to UTF-8 does not look like a good reason to me. But the first one does. -- Ph.
Re: WineD3D: Fix my name
"Phil Krylov" <[EMAIL PROTECTED]> wrote: On 11/01/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: I'd say that since converting resources to UTF-8 makes them not compatible with any other resource compiler except wrc, IMO that's a bad idea At least one free resource compiler that claims to support UTF-8: http://www.jorgon.freeserve.co.uk/#rc Unfortunately it's not Microsoft's rc.exe, i.e. not something I'm interested to compare wrc output/compatibility with. Also, there are not much editors in the Windows world that support UTF-8, since it's a multibyte encoding and in general is very cumbersome encoding to work with. Please don't do that. At least Notepad on Windows XP does support UTF-8. If that was supposed to be a joke I didn't buy it. -- Dmitry.
Re: WineD3D: Fix my name
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Actually the encoding for source files is Latin-1 at the moment. This should probably be changed once we convert resources to utf-8, to make all files use the same encoding. I'd say that since converting resources to UTF-8 makes them not compatible with any other resource compiler except wrc, IMO that's a bad idea. I personally time from time edit Wine resources in Visual Studio and compile them with rc.exe from PSDK and Visual Studio for testing. Also, there are not much editors in the Windows world that support UTF-8, since it's a multibyte encoding and in general is very cumbersome encoding to work with. Please don't do that. -- Dmitry.
Re: WineD3D: Fix my name
Stefan Dösinger <[EMAIL PROTECTED]> writes: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Actually the encoding for source files is Latin-1 at the moment. This should probably be changed once we convert resources to utf-8, to make all files use the same encoding. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Electron Microscope III (EMIII)
"Seth Shelnutt" <[EMAIL PROTECTED]> wrote: I am trying to get EMIII to run via wine. I'm perfectly willing to debug this. I just don't know how. I think my issue is with MSVBVM60.DLL (MSVBVM60.dbg)? I just sent a patch that should fix the crash. P.S. wineconf mailing list is not an appropriate place for a bug report. -- Dmitry.
dual displays
Hi,
dlls/winex11.drv/opengl.c:820
if(!display || !display) {
ERR("Invalid display or visual\n");
}
My guess is that second 'display' is supposed to be 'visual'.
--
James Hawkins
