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
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 really love
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
On Tue, Jan 10, 2012 at 4:20 PM, Martin v. Löwis mar...@v.loewis.de 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
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
Am 09.01.2012 07:13, schrieb Jeff Hardy:
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou solip...@pitrou.net 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
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 still
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 involve
: 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 solip...@pitrou.net wrote:
Depending on the extent of removed/disabled functionality, it might
not be very interesting to have a Metro port at all.
Win 8
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou solip...@pitrou.net 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
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 functionality. For example, everything
related to subprocess
2012/1/7 Martin v. Löwis mar...@v.loewis.de:
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
Zitat von Benjamin Peterson benja...@python.org:
2012/1/7 Martin v. Löwis mar...@v.loewis.de:
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
On Sat, Jan 7, 2012 at 16:07, mar...@v.loewis.de 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
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, 07 Jan 2012 18:57:41 +0100
Martin v. Löwis mar...@v.loewis.de 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
On 1/7/2012 4:47 PM, Benjamin Peterson wrote:
2012/1/7 Martin v. Löwismar...@v.loewis.de:
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
On 7 January 2012 22:56, Eli Bendersky eli...@gmail.com 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
On Sat, Jan 7, 2012 at 18:04, Paul Moore p.f.mo...@gmail.com wrote:
On 7 January 2012 22:56, Eli Bendersky eli...@gmail.com 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
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
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 does
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
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.
Zitat von Eli Bendersky eli...@gmail.com:
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,
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
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
Zitat von Antoine Pitrou solip...@pitrou.net:
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.
28 matches
Mail list logo
