2008/8/8 Stefan Dösinger <[EMAIL PROTECTED]>:
>
>> Very likely but you run into the following:
>> 1. Windows programs are written for the x86 processor. Is there an
>> x86 emulator for the ARM arch?
> You could run wince / windows mobile apps which are often ARM native.
>
Unfortunately WinCE isn'
> At the risk of getting even more off topic, Objective-C is one of gcc's
> dialects and works on Linux and *BSD just as fine as on Mac OS X.
Yes, I know, and so is C++. Nevertheless, neither is allowed in
Wine's source. I can argue rationale if you like, e.g. we don't want
to restrict ourselves
On Fri, 8 Aug 2008, James Mckenzie wrote:
> Tomasz Czapiewski <[EMAIL PROTECTED]> on Aug 8, 2008 10:05 AM (PNT) wrote
> about Is Wine portable to ARM arch?
>>
>> I wonder if someone has done successfull port of Wine for
>> mobile/PDA Linux distributions on hardware with ARM processors.
> No.
>> I
Am 08.08.2008 um 20:24 schrieb Juan Lang:
> It happens that the only platform
> on which there might be some reason to write objective C is the Mac
At the risk of getting even more off topic, Objective-C is one of
gcc's dialects and works on Linux and *BSD just as fine as on Mac OS X.
MarKus
> Actually, THIS is what I really wanted to read about in a FAQ.
Ah :) Fortunately, the Developers' Faq is on the wiki, so feel free
to add to it:
http://wiki.winehq.org/DeveloperFaq
--Juan
On Fri, Aug 8, 2008 at 2:24 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
>> Correct, there is code that will only be used on when the system is an Apple
>> (Mac). However, Mac specific code, such as ObjC code is not allowed per
>> Alexandre.
>
> Huh? This statement is nonsensical. You mean objecti
> Correct, there is code that will only be used on when the system is an Apple
> (Mac). However, Mac specific code, such as ObjC code is not allowed per
> Alexandre.
Huh? This statement is nonsensical. You mean objective C is not
allowed in Wine. Neither is C++. It happens that the only pla
Lei Zhang <[EMAIL PROTECTED]> on Aug 8, 2008 10:58 AM (PNT) wrote about Is Wine
portable to ARM arch?
>
>On Fri, Aug 8, 2008 at 10:39 AM, James Mckenzie
><[EMAIL PROTECTED]> wrote:
>> NO! Even MacOSX specific code is not allowed
>
>grep -rI __APPLE__ wine-git/ | wc -l
>returns 68.
Correct, there
Vladimir Pankratov wrote:
> -GetLastErrorText(strErrorText, 260);
> +GetLastErrorText(wstrErrorText,
> sizeof(wstrErrorText)/sizeof(WCHAR));
The same as of try2. You changed argument type in patch 1/12 but
function GetLastErrorText will change later in 12/12.
So
Tomasz Czapiewski wrote:
> There are many Linux users of such hardware (like Neo FreeRunner etc.)
> which would like to use Windows applications on their portable
> ARM-based devices.
Wine does not emulate CPU. You will not be able to run native windows
programs without recompiling them as winel
> Very likely but you run into the following:
> 1. Windows programs are written for the x86 processor. Is there an
> x86 emulator for the ARM arch?
You could run wince / windows mobile apps which are often ARM native.
> >If no then are there any plans for multiplatform code in Wine?
> NO! Even
>>>If no then are there any plans for multiplatform code in Wine?
>> NO! Even MacOSX specific code is not allowed
>
> Is there an FAQ that explains why this is so?
I don't think this statement is accurate. The problem is
"multiplatform" is ambiguous. If a "platform" is an operating system,
mult
On Fri, Aug 8, 2008 at 10:39 AM, James Mckenzie
<[EMAIL PROTECTED]> wrote:
> NO! Even MacOSX specific code is not allowed
grep -rI __APPLE__ wine-git/ | wc -l
returns 68.
http://www.winehq.org/site/docs/wine-faq/index#WHAT-DO-I-NEED-IN-ORDER-TO-USE-WINE
Not an answer specific to ARM, but this section of the FAQ describes
the situation with respect to running Windows applications on non-x86
platforms using Wine.
-Gal
On Fri, Aug 8, 2008 at 8:05 PM, Tomasz Czapiews
On Fri, Aug 8, 2008 at 1:39 PM, James Mckenzie
<[EMAIL PROTECTED]> wrote:
>>If no then are there any plans for multiplatform code in Wine?
> NO! Even MacOSX specific code is not allowed
Is there an FAQ that explains why this is so?
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~mill
Tomasz Czapiewski <[EMAIL PROTECTED]> on Aug 8, 2008 10:05 AM (PNT) wrote about
Is Wine portable to ARM arch?
>
>I wonder if someone has done successfull port of Wine for
>mobile/PDA Linux distributions on hardware with ARM processors.
No.
>Is it possible?
Very likely but you run into the followi
I wonder if someone has done successfull port of Wine for
mobile/PDA Linux distributions on hardware with ARM processors.
Is it possible?
If no then are there any plans for multiplatform code in Wine?
There are many Linux users of such hardware (like Neo FreeRunner etc.)
which would like to use W
> Glad to hear that you have sorted out the problem with a new version
> of the application. I think the general rule is that if wine
> doesn't provide some component (such as mfc and vc++ 80), using
> winetricks to install the additional components is preferred over
> installing application's bu
--- On Thu, 7/8/08, Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> From: Werner LEMBERG <[EMAIL PROTECTED]>
> Subject: Re: Networking problems with IDU Verwaltung software
> To: [EMAIL PROTECTED]
> Cc: wine-devel@winehq.org
> Date: Thursday, 7 August, 2008, 11:33 PM
> > It is probably irrelevant, but
I was distracted by my trip to Linuxworld (trip report:
http://lula.org/pipermail/lula_lula.org/2008-August/015218.html )
but am still slowly making progress on the patch
robot. It now looks at all mime parts of a message,
and properly flags messages with multiple patches
attached as violating lis
"Ilya Shpigor" <[EMAIL PROTECTED]> wrote:
> - /* why do we notify to es->hwndParent, and we send this one to GetParent()?
> */
> -hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg,
> (WPARAM)hdc, (LPARAM)es->hwndSelf);
> +/* We must send all notifies to es->hwndParent.
Dmitry Timoshkov wrote:
>
> I don't see how changing Wine internal implementation could lead to
> failing tests under Windows.
My confusion. Late at night. Found the problem, the inside the if
block. Resent the patch.
Jeff
"Hongbo Ni" <[EMAIL PROTECTED]> wrote:
> Changes since TRY2 - thanks to Dmitry Timoshkov for advice.
>
> 1. adds extra bulitin classes: ScrollBar,Message,DDEMLEvent & all #327xx;
> 2. make sure created hwnd is valid;
> 3. more tests for unicodeness of built-in-class window before subclassing;
> 4
> This discussion really would be better taken up in bugzilla.
Fortunately, it isn't necessary. Running an updated version of IDU, I
can continue, so maybe the version I tried first was buggy.
Werner
24 matches
Mail list logo