http://catholictechgeek.blogspot.com/2012/08/does-windows-8-and-winrt-mean-death-to.html
The article above has my full thoughts, but I wonder if there is a bit too much push for the graphical user interface in Windows 8 (and WinRT) and because of this, the survival of the command line in Windows (the thing that a bunch of the rom tools run on) is in jeopardy.
Given how worthless winRT is, useful programs like kitchens will never, ever appear on them. MS will have to keep the command line unless they want to lose everyone to linux/mac.
Even android phones have a working command line.
Just thought I would confirm that the Command line (cmd) is still present in Windows 8. As far as I'm aware there was never any talk about removing it.
they will never remove the command prompt, neither the new powershell....
on RT version, the final user will never use it.. but I think that will be present...
m0nkf1sh said:
Just thought I would confirm that the Command line (cmd) is still present in Windows 8. As far as I'm aware there was never any talk about removing it.
Click to expand...
Click to collapse
Correct, the command line is still there as well as PowerShell.
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
It's like comparing an Android Device to a Desktop PC and wondering why you can't run the same programs on them.
Talderon said:
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
hem.
Click to expand...
Click to collapse
actually it is still the NT kernel in WInRT adapted to ARM underneath I believe, similar to Windows phone, but yeah possibly no command line but i'd hope maybe powershell might be there...
And now the whole situation of "same program, different architectures" is back (after about 6 years).I remember back in the early days of Windows Mobile, you had the issue a developer releasing different builds of the some program for ARM, MIPS, and SH3. Eventually, ARM won out and program installation packages were (somewhat) standardized. Now, we have the issue between ARM and x86. Luckily, Microsoft has made this easier with the windows 8 store, so things aren't fragmented like before. This is probably why there is no real Desktop mode included in the ARM build of Windows 8.
Steven855 said:
And now the whole situation of "same program, different architectures" is back (after about 6 years).I remember back in the early days of Windows Mobile, you had the issue a developer releasing different builds of the some program for ARM, MIPS, and SH3. Eventually, ARM won out and program installation packages were (somewhat) standardized. Now, we have the issue between ARM and x86. Luckily, Microsoft has made this easier with the windows 8 store, so things aren't fragmented like before. This in probably why there is no real Desktop mode included in the ARM build of Windows 8.
Click to expand...
Click to collapse
I don't see an issue with ARM vs. x86 in this same context as the x86 tablet will run like an Ultra Mobile PC.
ARM will be treated the same as Mobile Phones of the same architecture as it is today.
>However, there is still no word yet on whether Microsoft will include the command line for the ARM build of Windows 8.
According to this presentation slide of PowerShell 3.0 (at TechEd 2012), PS3 will support Windows RT. If PS is present, by extension CLI is available.
http://video.ch9.ms/teched/2012/na/WSV414.pptx
e.mote said:
>However, there is still no word yet on whether Microsoft will include the command line for the ARM build of Windows 8.
According to this presentation slide of PowerShell 3.0 (at TechEd 2012), PS3 will support Windows RT. If PS is present, by extension CLI is available.
http://video.ch9.ms/teched/2012/na/WSV414.pptx
Click to expand...
Click to collapse
And there we have it folks!
I am still waiting on word on when we can pre-order the MS Surface. So far, from the Spec's everyone else has shown for their offerings, not much reason to jump ship to another brand. (yet)
Press Windows Key +X and you'll see two command prompts shortcuts...
this should be clarified - ROM tools in Windows RT aren't going to have a barrier in the shape of a command line so much as they'll have a barrier in that all current windows ROM utilities are either for x86 CPUs or Java (and java has no Windows ARM VM) and as such wouldn't run on WinRT's command line anyway.
I don't think an X86 emulator will be an option for Windows RT and the ARM architecture either.
The command line is actually alive and well in Windows 8 and Windows Server 2012. If anything Microsoft is moving the capabilities of the command line forward in recent years. The Power Shell allows to configure a huge part of Windows and Server Software based upon it (e.g. Exchange) that previously was not easily configurable through scripts.
Concerning Windows RT on ARM tablets the problems go much deeper than the command line. The RT-Apps won't be able to install device drivers for Smartphones to access them - this will also be true for official companion apps. Unless there is a class driver like for many printers, keyboards, etc. Windows RT simply won't support connection to those devices (again, this only applies to the ARM version).
For many reasons x86 isn't going anywhere and this limited support of peripherals is just one of them.
According to the Synofsky blog post, RT does support at least the v4 print class driver, but not v3. No mention is made for other peripherals, however.
http://blogs.msdn.com/b/b8/archive/2012/07/25/simplifying-printing-in-windows-8.aspx
It depends on what role MS sees for RT going forward. If RT is to be a limited OS to compete with Android/iOS, then printing support may be it. But if RT is to be a full counterpart of x86, other peripherals support will need to happen.
Looking long term, ARM will play a larger role than x86 in the trend of ever-smaller devices, with increasing emphasis on battery life. From this, my educated guess is that RT won't be the ugly duckling for long.
Let's face it, RT is a work-in-progress. Peripheral support is Windows' strongest card against the other mobile OS'es (and Linux). My take is that it will happen contigent to the above, but it won't be this initial iteration.
In short, don't take the limitations of this v1.0 as being cast in stone.
Talderon said:
Correct, the command line is still there as well as PowerShell.
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
It's like comparing an Android Device to a Desktop PC and wondering why you can't run the same programs on them.
Click to expand...
Click to collapse
Actually, that is factually incorrect. Windows RT shares substantial code with Windows 8, as Microsoft has confirmed many times in the Windows 8/RT development blog.
Related
I am writing from my pocket pc:
http://www.windowsfordevices.com/news/NS2632317407.html
"Microsoft officially launched the sixth generation of its flagship device software "platform, today. "Windows Embedded CE 6.0" boasts kernel architecture enhancements, new software stacks targeting three high-volume device categories, enhanced development tools, and, for the first time, 100 percent availability of Windows CE's kernel source code. "
Doesn't this mean we can port to any device?
This is for links:
http://msdn.microsoft.com/embedded/community/community/communityprojects/
http://www.codeplex.com/
---
Develop now, pay later
A free 180-day evaluation version of Windows Embedded CE 6.0 is available for download, here. The kit includes the operating system, the standard shared source components described above, and Visual Studio 2005 Professional.
http://www.windowsembeddedkit.com/
sorry to burst your bubble, but CE6.0 is NOT WM6
WM6 is BASED on CE5.2
WM7 will be BASED on CE6.0
Neither will be creatable/editable using the CE shared source as windowsmobile is not shared source.
True hehe
forgot Windows Mobile 6.0 is based on CE 5.2
Was a quick read and post on my pocket pc
Apologies
Might still be useful,
If we can get Windows CE 6.0 to run on a device...
It may be possible to get Windows Mobile 6 to run using a CE 6 core?
Windows CE 6 should be backward compatible with Windows CE 5.2 (although new drivers will probably be needed)
Long shot, but just might work...
(isn't Windows Mobile just a pretty shell for Windows CE?)
Problems:
*Probably against the Microsoft license. (Donations? Maybe can even buy Windows CE 5.2 Tool Suite)
*Windows CE 6 Core needed for Windows Mobile might be significantly bigger than Windows CE 5.2 Core.
*Need to know everything Windows Mobile uses in Windows CE to build a working core.
*Device Drivers may have to be rewritten depending on how much Windows CE 6 differs form Windows CE 5.2 (Will be easier with source code)
*Getting it to work will require quite a bit of development and research
basically, it's not impossible, just highly unlikely.
hehe any volunteers
I know its crazy, but there are huge benefits in getting this to work.
(Far less limitations in what we can do)
I would investigate myself but it looks like I am about to be computerless for the next 4 weeks!
OK, I hate to burst your bubble even further, but I don't think it will be possible at all.
Why?
1) They are only publishing the Kernel, and there is a lot more to the OS than that.
2) Because of the different kernel architecture the drivers will defiantly need to be rewritten and for that they will have to be reverse engineered first. Just look a the state of various Linux projects to see how long and hard something like that would be.
3) M$ is notorious for making OSs that are not forward compatible - namely although the difference between WM 6 and 5 is almost non existent compiling a simple "Hello word" app with WM 6 SDK will prevent it from running on a WM 5 device (bad exe error).
Also, the fact that they are "releasing" the code does not make it open source. It will still require a ton of paper work to get and you will probably have to be a real company or at least an academic establishment to get it.
M$ already gives out a lot of code for previous embedded OSs under special license.
So by the time someone leaks the code, figures out a way to patch together new kernel and additional required components from previous OS, plus reverse engineers and rewrite drivers for a given device not only that device will become obsolete but the whole CE line.
My guess is, a few years from now phone size devices will be powerful enough to run a normal OS like UMPCs do today.
levenum said:
1) They are only publishing the Kernel, and there is a lot more to the OS than that.
Click to expand...
Click to collapse
I don't want to compile the whole of Windows Mobile 6, just the parts that don't allow it to be run on older devices (or newer) e.g. nk.exe
(I haven't downloaded the kit yet so I don't know if this is possible or not, could be, could not be)
levenum said:
2) Because of the different kernel architecture the drivers will defiantly need to be rewritten and for that they will have to be reverse engineered first. Just look a the state of various Linux projects to see how long and hard something like that would be.
Click to expand...
Click to collapse
Many Windows CE 4 (Windows Mobile 2003 SE) drivers are used on a Windows CE 5.2 (Windows Mobile 5) platform. So there is a slight chance they may work in Windows CE 6.
levenum said:
3) M$ is notorious for making OSs that are not forward compatible - namely although the difference between WM 6 and 5 is almost non existent compiling a simple "Hello word" app with WM 6 SDK will prevent it from running on a WM 5 device (bad exe error).
Click to expand...
Click to collapse
An application written in a new operating system will not work in the old operating system.
but an application written in the old operating system usually works in the new operating system.
Otherwise microsoft would have many very unhappy customers.
Windows Mobile (non core parts) are basically old applications...
levenum said:
Also, the fact that they are "releasing" the code does not make it open source. It will still require a ton of paper work to get and you will probably have to be a real company or at least an academic establishment to get it.
M$ already gives out a lot of code for previous embedded OSs under special license.
Click to expand...
Click to collapse
You can already download it
http://www.windowsembeddedkit.com/
levenum said:
So by the time someone leaks the code, figures out a way to patch together new kernel and additional required components from previous OS, plus reverse engineers and rewrite drivers for a given device not only that device will become obsolete but the whole CE line.
My guess is, a few years from now phone size devices will be powerful enough to run a normal OS like UMPCs do today.
Click to expand...
Click to collapse
This thing runs WINDOWS VISTA
http://www.htc.com/product/03-product_HTC_Shift.htm
Heres another one, running windows XP
http://www.sonystyle.com/is-bin/INT...AIONotebookComputers_UX_Series&Dept=computers
We will not know the true amount of work needed until someone tries.
And if it is not a lot of work it will make a few people quite happy.
Well...
Me, i can not see the point in a project like this... Why would you even want to re-do microsofts sh--t.
Use the manpower and resources for the UNI Linux project.. They are allmost done... Just a few glitches now...
I wanna get away from MS asap... but i like this HW...
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools
so your bottom line says: no w8 on arm (ever)?
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?
mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)
That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.
netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.
I am waiting to hack my iPad and put win8 on it
I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App
Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.
The Windows Phone Software Development Kit (SDK) 8.0 provides you with the tools that you need to develop apps and games for Windows Phone 8 and Windows Phone 7.5.
Overview
The Windows Phone SDK 8.0 is a full-featured development environment to use for building apps and games for Windows Phone 8.0 and Windows Phone 7.5. The Windows Phone SDK provides a stand-alone Visual Studio Express 2012 edition for Windows Phone or works as an add-in to Visual Studio 2012 Professional, Premium or Ultimate editions. With the SDK, you can use your existing programming skills and code to build managed or native code apps. In addition, the SDK includes multiple emulators and additional tools for profiling and testing your Windows Phone app under real-world conditions.
System requirements
Supported operating systems: Windows 8, Windows 8 Pro
Windows 8 64-bit (x64) client versions
Hardware:
4 GB of free hard disk space
4 GB RAM
64-bit (x64) CPU
Windows Phone 8 Emulator:
Windows 8 Pro edition or greater
Requires a processor that supports Second Level Address Translation (SLAT)
If your computer meets the hardware and operating system requirements, but does meet the requirements for the Windows Phone 8 Emulator, the Windows Phone SDK 8.0 will install and run. However, the Windows Phone 8 Emulator will not function and you will not be able to deploy or test apps on the Windows Phone 8 Emulator.
Instructions
Choose the language version you want to install and click the Download button for the WPexpress_full.exe file. Follow the instructions to install the SDK. Note that each localized version of Windows Phone SDK 8.0 is designed to function with the corresponding localized operating system and localized version of Visual Studio 2012.
Note - Windows Phone SDK 8.0 installs side-by-side with previous versions of the Windows Phone SDK. You don't need to uninstall previous versions before beginning this installation.
Download the release notes which are in a separate file. For Windows Phone SDK 8.0 documentation and samples, see the Windows Phone Dev Center.
To start VS Express for Windows Phone, click the application in the Apps list. If you have Visual Studio Professional, Premium or Ultimate installed on the computer, the VS Express for Windows Phone shortcut won't appear. Instead, start your Visual Studio instance as usual and then create Windows Phone SDK 8.0 projects using the installed Windows Phone templates.
If you try to run a project in Windows Phone Emulator and Hyper-V is not enabled, you will be prompted to turn on Hyper-V. Turning on Hyper-V requires you to restart your computer.
Note: this release is also available in .iso format. Choose one of the following options for handling downloaded ISO images:
(Recommended) Write the image file to a blank DVD.
(Alternative) Mount the image file virtually as DVD devices.
Download WebSite: http://www.microsoft.com/en-us/download/details.aspx?id=35471
So how do you learn how to use an SDK? I've always had an interest but there is never any obvious guide of how to program. I picked up UE3 SDK quickly but that is because there was like 30GB of tutorials on it, where can I do the same for this SDK?
Thanx.
You learn visual C#/B/C++. You do not directly use the SDK, you use the development tools in it
Venekor said:
So how do you learn how to use an SDK? I've always had an interest but there is never any obvious guide of how to program. I picked up UE3 SDK quickly but that is because there was like 30GB of tutorials on it, where can I do the same for this SDK?
Thanx.
Click to expand...
Click to collapse
First learn Silverlight/C# and then read the SDK documentation,
To put it in simple words SDK just gives all the functions that u can use on Windows Phone.
Typically, if you learn any C# API (other than windows forms) you will learn all the others. They are very similar to each other, only some few twinks here and there due to platform differences.
---------- Post added at 11:46 PM ---------- Previous post was at 11:28 PM ----------
The SDk is bugged, emulator does not work. Says it wants virtualization and my PC doesn't have it, when it clearly does. Both Android and Windows Phone 7.5 emulators work fine.
Kinda failish...from Microsoft.
oh well...the SDK system requirements are pretty damned huge. My CPU does not support SLAT apparently...
So I can just go to the Visual Studio website and follow the tutorials there? I have bad eye sight so I learn better from videos and listening instead of reading lots of text which takes me far longer to do. Luckily typing is easier as you know what you're typing on the keyboard so you don't have to pay as much attention on reading the text on screen.
Your processor needs SLAT support (extended Virtualization) also called VT-x by Intel. It is available from the Core i3/i5/i7 processors or newer AMD processors. This is due to the fact that the WP8 Emulator relies on Hyper-V instead of VirtualPC which was used for WP7. So if you have a Core 2 processor your hardware does lack required features. This is not a bug in the SDK.
On learning development of WP Apps there are series that take you around the SDK like this one: http://www.jeffblankenburg.com/2010/09/30/31-days-of-windows-phone-7/ It's still for WP7 but almost everything said there still applies for WP8, although in WP8 it was much extended. There are also Development Webcasts and Hands-On Labs you can try out. You can Google for those - there is lots of content on the topic.
But as was said before - it would be beneficial to know some C# beforehand.
I keep installing the SDK but visual studio express 2012 for windows phone doesnt appear in my start menu, says everything is installed fine, Any ideas?
Edit:btw using windows 8 x64 Evaluation Version
Do you have a regular version of Visual Studio 2012 installed? In that case the SDK integrates itself with the regular version and just adds the project type there.
StevieBallz said:
Do you have a regular version of Visual Studio 2012 installed? In that case the SDK integrates itself with the regular version and just adds the project type there.
Click to expand...
Click to collapse
That will be the one,, Cheers for reply.
Since no college near me teaches any programming and I have to work, I better start teaching myself.
Can any one tell me where to start?
Thanx.
Venekor said:
Since no college near me teaches any programming and I have to work, I better start teaching myself.
Can any one tell me where to start?
Thanx.
Click to expand...
Click to collapse
https://dev.windowsphone.com/en-us
http://www.windowsphonegeek.com/Resources
http://www.freebookspot.es/Comments.aspx?Element_ID=259285 (book)
Does WP8 have any new ringtones/notifications or wallpapers?
I dunno if that stuff would be in the SDK, but it'd be cool to have a dump of those files.
Weird Visual Studio basically does everything for you, I was expecting you'd have to make everything from scratch. Not what I wish'd for really as I did want that experience, those guides don't teach you how to understand the language, just how to create something quickly. Kinda like when you were at school reading from a text book and they never taught you the foundations of how to create your own sentences, always taught pre existing ones.
You can look for manuals for Visual C# around the web, there are a couple of free ones created by Microsoft, but you won't find any videos.
Once you understand the basics, it will be pretty easy to get started on creating complex apps. This is the beauty of C#
can anyone give me MD5 or SHA-1 hash of the iso? thx.
If you want to learn programming from the ground up I guess it would be best to start with a regular book on programming with Visual C# 2010 or something along those lines (2012 books are still rare I guess).
The problem with starting out on Smartphone platforms is simply that there is nothing like Console programs that allow you to easily experiment with language features without having to care a lot about more complex concepts like asynchronicity, Event-models, data-binding, etc.
While I can do a simple:
public static void main(String[] args) {
Console.WriteLine("Hello World!");
}
on the Desktop to arrive at a program that outputs those famous words to the screen on the phone it is more like with a PCs GUI programming.
There you have to instantiate a Window (or Page on the Phone), place a Label control (both of which are classes) and assign a property of the label to the text. Algorithmically a lot of information is hidden in those classes. This is mainly due to the fact that during actual development people don't want to and don't need to care about the details behind those things but for learning how to do things the effect is pretty devastating.
So my suggestion would be: Take a book on C# development and work through the basic concepts of Methods, Classes, Properties, EventHandlers and then before diving into the details of WinForms development switch over to the Phone SDK and acquaint yourself with the workings of the according UI Toolkit.
how can i tell if my computer has a processor that supports Second Level Address Translation (SLAT)
my laptp is intell pentum and my desktop is amd phantom x4?
Your laptop won;t support it.
I am not entirely sure about the AMD though.
There is a tool for that in the SDK download page.
Can anyone tell me when / why I want to use desktop mode (I've got a Surface for Windows RT)?
I know the Office apps force you there. Otherwise, is it only when I want to hit up the control panel or Explorer?
Is there anything else to do in Desktop mode?
Also, stupid question, but is there any way to launch an app (other than the 5 pinned to the taskbar) directly in desktop mode?
When you don't have a tablet?
Sent from my SCH-I510 using Tapatalk 2
JihadSquad said:
When you don't have a tablet?
Sent from my SCH-I510 using Tapatalk 2
Click to expand...
Click to collapse
Sorry, I should have specified, I'm asking about the Surface for Windows RT
I think when Microsoft releases the next visual studio it will be compatible with rt in desktop mode. Also you have calculator, paint etc. on the desktop.
Sent from my SCH-I510 using Tapatalk 2
I believe Desktop mode is short term legacy support. Should disappear in the next version of RT.
junialum said:
I believe Desktop mode is short term legacy support. Should disappear in the next version of RT.
Click to expand...
Click to collapse
And quite possibly in a couple iterations of Windows itself...
Thanks.
Sent from my Nexus 7 using xda app-developers app
Windows explorer? IE with addons? Control Panel?
Sent from my RM-820_nam_att_100 using Board Express
junialum said:
I believe Desktop mode is short term legacy support. Should disappear in the next version of RT.
Click to expand...
Click to collapse
JihadSquad said:
And quite possibly in a couple iterations of Windows itself...
Click to expand...
Click to collapse
No. Desktop mode is never going to be phased out, "legacy" is just a marketing ploy to accentuate that the new UI is "modernUI".
Desktop mode is for desktop things. Like when you plug a keyboard and mouse into your Surface, and you browse the internet with IE desktop and manage your files with explorer or use office. The full functions of office could never and will never be crammed into an app: it would violate the simplicity/stylistic/touchfriendly guidelines.
Desktop will never be phased out of RT or Windows, I don't know why people think this.
Other things to use Desktop Mode for:
Scripting (CMD, Powershell, etc.).
Proper multitasking (more than two windows at once).
Task Manager.
Advanced management tools (Management console and all its snap-ins, diskpart and netsh and other command-line tools, etc.).
IE developer tools.
Setting up file and folder sharing.
anything else that apps can't do...
Oh, and (especially once we get this working better), running existing apps that have ben recompiled for ARM.
link68759 said:
Desktop mode is for desktop things. Like when you plug a keyboard and mouse into your Surface, and you browse the internet with IE desktop and manage your files with explorer or use office. The full functions of office could never and will never be crammed into an app: it would violate the simplicity/stylistic/touchfriendly guidelines.
Desktop will never be phased out of RT or Windows, I don't know why people think this.
Click to expand...
Click to collapse
Yeah, that's how I've been using it. I picked up a bluetooth mouse that works nicely without a dongle. I used desktop mode to copy some files around - it was nice. I plan to use Remote Apps and some other stuff that will only work well in desktop mode.
Its nice. I can switch back and forth with ease. Some things (content consumption with ass parked on a couch) are easier with the don't-call-it-metro mode and some things (content creation/manipulation while sitting at a desk) are easier to do in desktop mode. I can't do that with any of my iOS or Android tablets. Because of this, I see desktop mode as an advantage WinRT has over iOS and Android. Neither of those have anything similar and probably never will have.
But hey - don't like desktop mode? Don't use it.
I see the don't-call-it-metro mode and desktop mode as similar to the way DOS and Windows used to be. Win95/NT/2000 was nice, but sometimes you just needed to drop into DOS to do some things easier. I still use ipconfig /all quite a bit now that I am thinking about it.
I sincerely hope desktop mode is never phased out. I can't imagine why it would be - DOS Command Prompt is still around after all these years and it still has its uses.
Just to clarify, because this is a pet peeve of mine: THAT IS NOT DOS! It is a command-line shell which emulates certain portions of the DOS user interface and, on 32-bit machines, also the DOS API... but it's not DOS. CMD can do all kinds of things that DOS can't, ranging from UI features like path or command completion to system capabilities like running apps in the background (DOS had no multitasking capability). 32-bit builds of Windows NT (including 2000, XP, Vista, Win7, and Win8, plus corresponding server builds, which all use NT) include NTVDM - the NT Virtual DOS Machine - for running 16-bit DOS apps with emulated hardware (DOS granted full access to the hardware for any app; NT doesn't, so it had to provide virtual hardware for compatibility). NTVDM will *claim* to be a version of DOS, for compatibility's sake, but that's no more true than Wine on Linux claiming to be a version of Windows.
However, I absolutely agree that some things are best done in the command line. I actually rather dislike CMD; its command completion sucks, its scripting language is lame, its quotation parsing rules are bizarre and archaic, and it's missing some capabilities such as what you get from `command-goes-here` on POSIX shells. On versions of Windows which can run it, I prefer to use bash via SUA; on versions which can't, Cygwin is an almost-acceptable alternative. I'm slowly learning Powershell (accelerated somewhat by the fact that the Surface RT has both CMD and Powershell, but neither SUA nor Cygwin) as well; it's very powerful but its scripting syntax feels weird to me and the software itself is very heavyweight and tends to run slowly at times (such as when loading new modules).
GoodDayToDie said:
Just to clarify, because this is a pet peeve of mine: THAT IS NOT DOS! .
Click to expand...
Click to collapse
Yeah... I know... But its much easier to type DOS than it is to type "a command-line shell which emulates certain portions of the DOS user interface and, on 32-bit machines, also the DOS API..." Don't you agree?
or "CMD", "CLI", "command line", "command-line interface", "terminal", "command prompt", "TUI", "text user interface", "text shell", "cmd.exe", "powershell", even "NTVDM", ...
Sorry, totally off-topic, I know. It's just frustrating when people claim that 'Windows is just a graphical interface over DOS" (hasn't been true since the early 90s) or 'Windows is still built on a DOS core" (hasn't been true since ME), or "Windows still includes a copy of DOS" (not true at all for 64-bit or ARM or Itanium or anything other than x86, and arguable even there). To people who actually heavily used (or, haven forbid, still use) DOS, or have old DOS apps they need to run, that just results in problems which, annoyingly often, I end up needing to solve. It would help a lot of people who knew better didn't perpetuate the untruths.
Oh, and back on-topic: if you use desktop IE, you can add Tracking Protection lists (and edit the automatic one) and also enable ActiveX filtering (which might not be needed on RT due to its limited Flash list and lack of many other plug-ins, but I still prefer it).
Raspberry Pi 2 spec:
A 900MHz quad-core ARM Cortex-A7 BCM2836 CPU (up from a single-core 700Mhz part)
1GB LPDDR2 SDRAM (up from 512MB)
Complete compatibility with Raspberry Pi 1 (software will need to be recompiled to take advantage of the new multi-core processor)
Identical form factor to the existing Raspberry Pi, which means it can fit into existing enclosures
10/100 Ethernet port
40-pin extended GPIO
4 x USB 2.0 ports
4 pole Stereo output and Composite video port
Full size HDMI
CSI camera port for connecting the Raspberry Pi camera
DSI display port for connecting the Raspberry Pi touch screen display
Micro SD slot
Micro USB power source
Its not going to be a full Win 10 like on a PC, its Win 10 IoT.
Well yeah it can not be full version still there is a windows support, I'm still waiting for Android support
Wonder if they will have proper display drivers with Win 10... Those are the reason Android hasn't been 100% successful in being ported over
Nypan sr said:
Its not going to be a full Win 10 like on a PC, its Win 10 IoT.
Click to expand...
Click to collapse
But hopefully it will be more like more like the x86 Windows version without any dumb restrictions, as opposed to the Windows on ARM SKUs we've seen so far (Windows RT and phone) that have too many restrictions. I believe the current IoT version is prrety stripped down and runs win32 executables, but I guess it remains to be seen exactly what the Windows 10 IoT SKUs (x86 or ARM) will be like.
Either way this is good news, and especially as it's the first Windows on ARM release (that I'm aware of) that isn't pre-installed on a device, and can be installed and removed at will (again, unlike Windows RT/Phone device with a locked bootloader). So that at least is encouraging.
I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.
vulcanize said:
I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.
Click to expand...
Click to collapse
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.
black_blob said:
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.
Click to expand...
Click to collapse
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that
xsoliman3 said:
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that
Click to expand...
Click to collapse
I should clean the UEFI implementation and adapt the HalExtTegra3 to something cleaner without a hacked VersatilePB target. How to disassemble that lib?
A bluescreen is the result with the RTSM emulator. Does anyone have Windows RT BSP documentation or a disassembler?
Just noticed someone else who has done amazing things with Windows RT on generic ARM hardware
http://winocm.moe/projects/bringup/osports/2015/01/12/giving-windows-on-arm-a-hand/
I think Linux is much more important than windows support.