Hi,
I've been working through my Dell Inspiron 1545 with Linux/Ubuntu
10.04 LTS experiences with ongoing reviews. I'd like to provide some
help to others considering making the transition from Windows to
Linux. I'm trying to get my Garmin GPS to talk to its Mapsource
(running under WINE) a
On 05/25/2011 09:27 AM, Maarten Lankhorst wrote:
> Hi mark,
>
> 2011/5/25 Mark Page :
>>
>> I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ...
>> GNU Lesser General Public License 2.1
>>
>> It would be useful to add the font to the ClanLib SDK resources (ClanLib has
>> a
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11183
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11184
Your paranoid android
On Wednesday 25 May 2011 23:04:02 Frank Richter wrote:
> The underlying issue is probably the _CRTIMP - that's most likely
> _declspec(dllimport) in MSVC.
I suspected something like this, but msvc didn't want to tell me what _CRTIMP
was. Either way it doesn't get me much closer to a fix.
signat
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 st
On Wed, 2011-05-25 at 18:49 +, Dan Kegel wrote:
> wow, msi has really come a long way!
Thanks. In hindsight we should have implemented rollbacks
early on, when installers still failed regularly ;-)
Hi,
This is one of the last remaining hacks needed to compile the d3d parts of
Wine with Visual Studio. Our definition of **environ is conflicting with one
already in the Windows SDK headers:
1>..\..\wine\libs\wine\loader.c(54): warning C4273: '_environ': Inkonsistente
DLL-Bindung.
1>
On 05/25/2011 08:37 PM, Stefan Dösinger wrote:
On Wednesday 25 May 2011 00:39:46 Ričardas Barkauskas wrote:
My first try for COM cleanup. Please donėt be too harsh :)
If this is too large for one patch, please suggest how to split it.
This is not automatic clean up so I don't really expect it t
wow, msi has really come a long way!
On Wednesday 25 May 2011 00:39:46 Ričardas Barkauskas wrote:
> My first try for COM cleanup. Please donėt be too harsh :)
> If this is too large for one patch, please suggest how to split it.
>
> This is not automatic clean up so I don't really expect it to be good on
> first try.
I can't find any
On Wed, May 25, 2011 at 6:23 PM, Dylan Smith wrote:
> The layout doesn't group all values, param names, or defaults, so it
> actually seems to be best described using loops. Does the the
> following comment help summarize the layout?
Yes.
Patch looks more readable now, thanks. Maybe an assert
a
Hi Dan,
On Wed, May 25, 2011 at 10:31 AM, Dan Kegel wrote:
> A comment or two about the layout of the output buffer might
> be nice.
>
The layout doesn't group all values, param names, or defaults, so it
actually seems to be best described using loops. Does the the
following comment help summari
On 05/25/2011 12:36 PM, Adam Martinson wrote:
On 05/24/2011 03:37 AM, Huw Davies wrote:
+static IDropTarget* WrapDropTarget(IDropTarget* inner)
+{
+DropTargetWrapper* This = HeapAlloc(GetProcessHeap(), 0,
sizeof(*This));
+
+if (This)
+{
+This->iface = (IDropTarget){&DropTar
On 05/24/2011 03:37 AM, Huw Davies wrote:
+static IDropTarget* WrapDropTarget(IDropTarget* inner)
+{
+DropTargetWrapper* This = HeapAlloc(GetProcessHeap(), 0, sizeof(*This));
+
+if (This)
+{
+This->iface = (IDropTarget){&DropTargetWrapper_VTbl };
This->iface.lpVtbl =&DropTarg
Hi mark,
2011/5/25 Mark Page :
>
> I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ...
> GNU Lesser General Public License 2.1
>
> It would be useful to add the font to the ClanLib SDK resources (ClanLib has
> a zlib style license)
>
> It is not clear how a font can be li
I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU
Lesser General Public License 2.1
It would be useful to add the font to the ClanLib SDK resources (ClanLib has a
zlib style license)
It is not clear how a font can be licensed using LGPL, since LGPL is based
a
+static const char diffuse_paramname[] = "Diffuse";
+static const char power_paramname[] = "Power";
+static const char specular_paramname[] = "Specular";
+static const char emissive_paramname[] = "Emissive";
+static const char ambient_paramname[] = "Ambient";
+static const D
Marcus Meissner writes:
> @@ -348,7 +348,7 @@ static BOOL find_pe_resource( HFILE lzfd, DWORD *resLen,
> DWORD *resOff )
> /***
> * find_version_resource [internal]
> */
> -DWORD find_version_resource( HFI
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11170
Your paranoid android
Damn ... I have attached the wrong diff.
Michael Stefaniuc wrote:
> Ričardas Barkauskas wrote:
>> My first try for COM cleanup. Please donėt be too harsh :)
>> If this is too large for one patch, please suggest how to split it.
>>
>> This is not automatic clean up so I don't really expect it to be
Hello Ričardas!
Ričardas Barkauskas wrote:
> My first try for COM cleanup. Please donėt be too harsh :)
> If this is too large for one patch, please suggest how to split it.
>
> This is not automatic clean up so I don't really expect it to be good on
> first try.
Heh! I have attached the raw diff
On Tue, May 24, 2011 at 8:32 PM, Stefan Dösinger wrote:
> On Tuesday 24 May 2011 19:56:06 Michael Mc Donnell wrote:
>
>> Sorry I phrased that in a wrong way. In the UpdateSemantics function I
>> call IDirect3DDevice9_CreateVertexDeclaration which allocates a new
>> Vertex Declaration on the heap.
On Tuesday 24 May 2011 22:57:34 Henri Verbeet wrote:
> I'm not sure that's really worth it. If the GL lock is really such a
> concern, you should probably change the calls in context.c to already
> be under the GL lock anyway. You can easily change
> context_apply_draw_buffers() for example to requ
24 matches
Mail list logo