> Just wondering, do Metro apps define UNDER_CE or _WIN32_WCE? The point
> is that the old ANSI functions (CreateFileA etc) have been removed from
> the embedded MS Windows CE long ago, too, and MS Windows Mobile used to
> be a custom CE variant or at least strongly related. In any case, it
> could
Am 07.01.2012 18:57, schrieb "Martin v. Löwis":
I just tried porting Python as a Metro (Windows 8) App, and failed.
Metro Apps use a variant of the Windows API called WinRT that still
allows to write native applications in C++, but restricts various APIs
to a subset of the full Win32 functionali
Dino wrote:
> Martin wrote:
> > See the start of the thread: I tried to create a "WinRT Component
> > DLL", and that failed, as VS would refuse to compile any C file in
> > such a project. Not sure whether this is triggered by defining
> > WINAPI_FAMILY=2, or any other compiler setting.
> >
> > I'd
Martin wrote:
> See the start of the thread: I tried to create a "WinRT Component DLL", and
> that failed, as VS would refuse to compile any C file in such a project. Not
> sure whether this is triggered by defining WINAPI_FAMILY=2, or any other
> compiler setting.
>
> I'd really love to use WINA
On Tue, Jan 10, 2012 at 4:20 PM, "Martin v. Löwis" wrote:
>> Win 8 is practically a new OS target - the nt module may need to be
>> replaced with a metro module to handle it well.
>
> No, it's not. Everything continues to work just fine on Windows 8,
> as long as we keep developing desktop apps.
>
Let me see if I can try this. Hopefully I still have my VM w/ this
all setup and
I can see if I can get it building this way. I can always ping some
people on the
C++ team and ask them for help if I run into issues. I'll give it a
shot tomorrow
and get back to you.
Hi Dino,
I reported
Martin wrote:
> Does that hold for all versions of the C runtime (i.e. is msvcr80.dll also
> exempt from the ban, or just the version that comes with VS 11)?
Just the VS 11 CRT is allowed.
>
> > So to the extent that Python is just a C program the "port" should be
> > pretty easy and mostly invo
> I haven't been following this thread so maybe this was already
> discussed, but on the whole "new OS target" thing - if people want to
> write immersive apps in Python then there will need to be a new build
> of Python. One thing that might make that easier is the fact that
> the C runtime is st
Am 09.01.2012 07:13, schrieb Jeff Hardy:
> On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote:
>> Depending on the extent of removed/disabled functionality, it might not
>> be very interesting to have a Metro port at all.
>
> Win 8 is practically a new OS target - the nt module may need to be
>
January 08, 2012 10:13 PM
To: Antoine Pitrou
Cc: python-dev@python.org; Dino Viehland
Subject: Re: [Python-Dev] Python as a Metro-style App
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote:
> Depending on the extent of removed/disabled functionality, it might
> not be very interesting
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote:
> Depending on the extent of removed/disabled functionality, it might not
> be very interesting to have a Metro port at all.
Win 8 is practically a new OS target - the nt module may need to be
replaced with a metro module to handle it well.
A
Zitat von Antoine Pitrou :
> When you say MoveFile is absent, is MoveFileEx supported instead?
WinRT strongly prefers asynchronous methods for all lengthy
operations. The most likely call to use for moving files is
StorageFile.MoveAsync.
http://msdn.microsoft.com/en-us/library/windows/apps/
Perhaps this is better for another topic, but is anyone using the PGO
stuff? I know we have PGInstrument and PGUpdate build configurations
but I've never seen them mentioned anywhere.
I'm using them in the 32-bit builds. I don't use them for the 64-bit
builds, as the
build machine was a 32-bit
When you say MoveFile is absent, is MoveFileEx supported instead?
Or is moving files just totally impossible?
I can't check the SDK headers right now, but according to the online
documentation, MoveFileExW is indeed available. I'm not sure whether
you are allowed to pass arbitrary file names in
Zitat von Eli Bendersky :
A then-related question is whether Python 3.3 should be compiled with
Visual Studio 11. I'd still be in favor of that, provided Microsoft
manages to
release that soon enough.
Martin, I assume you mean the Express version of Visual Studio 11 here,
right?
*Here*,
On 2012-01-08, at 01:27 , Antoine Pitrou wrote:
>>> When you say MoveFile is absent, is MoveFileEx supported instead?
>> WinRT strongly prefers asynchronous methods for all lengthy
>> operations. The most likely call to use for moving files is
>> StorageFile.MoveAsync.
>> http://msdn.microsoft.co
Antoine Pitrou:
> How does it translate to C?
The simplest technique would be to use C++ code to bridge from C to
the API. If you really wanted to you could explicitly call the
function pointer in the COM vtable but doing COM in C is more effort
than calling through C++.
> I'm not sure why "r
> > When you say MoveFile is absent, is MoveFileEx supported instead?
>
>WinRT strongly prefers asynchronous methods for all lengthy
> operations. The most likely call to use for moving files is
> StorageFile.MoveAsync.
> http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
How
Antoine Pitrou:
> When you say MoveFile is absent, is MoveFileEx supported instead?
WinRT strongly prefers asynchronous methods for all lengthy
operations. The most likely call to use for moving files is
StorageFile.MoveAsync.
http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
On Sat, Jan 7, 2012 at 18:04, Paul Moore wrote:
> On 7 January 2012 22:56, Eli Bendersky wrote:
>>
>>> A then-related question is whether Python 3.3 should be compiled with
>>> Visual
>>> Studio 11. I'd still be in favor of that, provided Microsoft manages to
>>> release
>>> that soon enough.
>>
On 7 January 2012 22:56, Eli Bendersky wrote:
>
>> A then-related question is whether Python 3.3 should be compiled with
>> Visual
>> Studio 11. I'd still be in favor of that, provided Microsoft manages to
>> release
>> that soon enough.
>
>
> Martin, I assume you mean the Express version of Visua
On 1/7/2012 4:47 PM, Benjamin Peterson wrote:
2012/1/7 "Martin v. Löwis":
I just tried porting Python as a Metro (Windows 8) App, and failed.
Is this required for Python to run on Windows 8?
No, normal 'desktop' programs will still run in desktop mode.
Sorry if that's a dumb question. I'm
On Sat, 07 Jan 2012 18:57:41 +0100
"Martin v. Löwis" wrote:
> For example, everything
> related to subprocess creation would not work; none of the
> byte-oriented file API seems to be present, and a number of file
> operation functions are absent as well (such as MoveFile).
When you say MoveFile
> A then-related question is whether Python 3.3 should be compiled with
> Visual
> Studio 11. I'd still be in favor of that, provided Microsoft manages to
> release
> that soon enough.
>
Martin, I assume you mean the Express version of Visual Studio 11 here,
right?
Eli
___
On Sat, Jan 7, 2012 at 16:07, wrote:
> A then-related question is whether Python 3.3 should be compiled with Visual
> Studio 11. I'd still be in favor of that, provided Microsoft manages to
> release that soon enough.
I'm guessing the change would have to be done before the first beta?
It would
Zitat von Benjamin Peterson :
2012/1/7 "Martin v. Löwis" :
I just tried porting Python as a Metro (Windows 8) App, and failed.
Is this required for Python to run on Windows 8?
No. Existing applications ("desktop applications") will continue to work
unmodified. Metro-style apps are primaril
2012/1/7 "Martin v. Löwis" :
> I just tried porting Python as a Metro (Windows 8) App, and failed.
Is this required for Python to run on Windows 8?
Sorry if that's a dumb question. I'm not sure if "Metro App" is a
special class of application.
--
Regards,
Benjamin
27 matches
Mail list logo
