Computing desk
< January 26	<< Dec \| January \| Feb >>	January 28 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 27

Where can I obtain the source code of Android 4.2?

It does not appear to be available on http://source.android.com/ . The latest new is about Android 4.1. — Preceding unsigned comment added by Czech is Cyrillized (talk • contribs) 03:40, 27 January 2013 (UTC)[reply]

I think they just haven't updated that page yet. I haven't tried it, but according to this [1] it should be available under the branch name "android-4.2_r1". RudolfRed (talk) 04:15, 27 January 2013 (UTC)[reply]

You can get it using the SDK manager. -- Finlay McWalterჷTalk 12:14, 27 January 2013 (UTC)[reply]

The binaries are non-free, I need the source code instead. Czech is Cyrillized (talk) 11:15, 27 January 2013 (UTC) Moved to keep thread together - Cucumber Mike (talk) 16:32, 27 January 2013 (UTC)[reply]

You need to download them from GitHub. The instructions for doing so are at [2] - as mentioned earlier you can specify which version to download and you will want "android-4.2_r1". - Cucumber Mike (talk) 16:32, 27 January 2013 (UTC)[reply]

I want the Android SDK. Is the source of the SDK included in the Android source code you link to? Czech is Cyrillized (talk) 12:23, 28 January 2013 (UTC)[reply]

Interchangeable AC chargers

If anyone here could pop over to the science desk for help on this, that'd be great! DRosenbach ^{(Talk | Contribs)} 03:43, 27 January 2013 (UTC)[reply]

Console/shell in Windows?

I know fairly well that in the Unix/Linux world, the command prompt console (terminal emulator) is just a graphical front-end for text-based applications, and it runs a separate program, called a shell, which handles all the text-based interfacing to the system. Both the graphical console front-end and the shell are interchangeable without depending on each other. How is this on Windows? Are the Windows Command Prompt and the actual command-line interface (cmd.exe) as interchangeable or are they deeply married to each other? JIP | Talk 18:30, 27 January 2013 (UTC)[reply]

Yes, cmd.exe is just another program, which uses the same APIs as other programs do. An altogether more modern (and rather more bash-like) shell is Windows PowerShell, which is built on the same common language runtime as C#, and so gives scripts written in it access to the Windows API. -- Finlay McWalterჷTalk 18:37, 27 January 2013 (UTC)[reply]

Hmm, I think I misunderstood your question. You're asking whether the terminal and cmd.exe are separate programs. That I don't know. -- Finlay McWalterჷTalk 18:48, 27 January 2013 (UTC)[reply]

Some things are evident:

One can get the black-text-window without cmd.exe: any Windows API console mode program gets that
One can run a windows shell inside another program (such as python's subprocess calls with shell=true) and interact with the cmd.exe process programatically, without it popping up a window of its own
One can run a cmd.exe interactively as a slave of another process, with the other process doing GUI and graphics for the enslaved cmd.exe (this is just a fancy extension of the above point); emacs's m-x shell mode does this on windows.

But I can't find, and I'm not sure actually exists, an API for the cmd.exe window itself. If I really wanted a program to pop one of these up, and a Winforms RichTextBox wasn't enough for me, I think I'd probably end up writing a console mode winapi program and having it talk to my master program on a socket. The only gap that leaves, I think, is where the ANSI terminal emulation exists; if you really needed that I think you may have to write it. -- Finlay McWalterჷTalk 20:16, 27 January 2013 (UTC)[reply]

The API to 'create' a console is AllocConsole. Some simple coloring and positioning of text appears to be possible with the APIs mentioned there too. Unilynx (talk) 21:29, 27 January 2013 (UTC)[reply]

Windows Command Prompt is cmd.exe 92.233.64.26 (talk) 19:13, 27 January 2013 (UTC)[reply]

Does that mean that the graphical front-end and the command-line interpreter are the same program and inseparable, different from Unix/Linux? JIP | Talk 19:57, 27 January 2013 (UTC)[reply]

Even if they were separate, I doubt you could legally exploit that fact in any way—it is all bundled together with Microsoft Windows. ¦ Reisio (talk) 20:23, 27 January 2013 (UTC)[reply]

Finlay knows a lot more than I do about this sort of thing, and I don't think I fully understand what you're asking, but once upon a time, the Windows GUI really was a program that ran on top of DOS. So when you exited out you could "get back" to the black screen and blinking cursor. Most linux distros still have that abstraction because Xwindows (and all the popular GUIs, gnome, kde, synaptics... etc.) run on top of it. But the xterm you're running is also just a program running within the gui. Fundamentally, whether windows or linux (or osx/bsd for that matter), the programs (whether it's xterm that then makes calls to bash, or whether it's bash itself, or whether it's a file manager) are just making API calls to the kernel. So I think you're working with a mental model of an operating system that works, but your question is demonstrating where that model breaks down. But again, I'm not exactly sure what you're asking so maybe I'm off base here. I hope this helps a bit though. Shadowjams (talk) 22:38, 27 January 2013 (UTC)[reply]

On reading up various things, here's how cmd.exe seems to work. It seems that, depending on context, it can be the command interpreter and the owner of the terminal emulator, or just the command interpreter alone. The actual black texty window thing is, as Unilynx linked to, created with the Windows Console API; lots of other programs use that, including rxvt and Windows PowerShell, and there's a wrapper library that wraps "console mode" applications so they use the console. cmd.exe is just another of these. cmd.exe also works analogously to bash. In addition it detects if its been run under _popen (or an IO redirect in which case it doesn't make its own consoleAPI calls, and just shoves characters down the file descriptors to its owner (just like bash does). cmd.exe also implements some basic ANSI functionality, which isn't in the ConsoleAPI. It's very instructive to read the source of an alternate command-terminal program like ANSIcon. One thing of note is where the command-terminal has to host a console mode program which is linked with that library (the one that makes its stdin/stdout work using the Console API) - the "terminal" has to use dll hooking to intercept these calls so that they instead go to its own calls instead (which ANSIcon does in injdll32.c). So, tldr, there isn't quite a comparable mapping between the unix and windows way of working, but mostly the display stuff that xterm does is done by the Console API and mostly the stuff that bash does is done my cmd.exe. -- Finlay McWalterჷTalk 01:13, 28 January 2013 (UTC)[reply]

I should say that this is all utterly different to how COMMAND.COM worked when you ran "command prompt" on say Windows 3.1/95. If anyone cares about that, let me know, and I'll write it up tomorrow - it's weird, clever jumble. -- Finlay McWalterჷTalk 01:30, 28 January 2013 (UTC)[reply]

The console window is a terminal emulator running as a separate process much as in Unix, but unlike Unix, where there's a documented interface (ptys) for writing your own terminal emulator, the communication between Win32 console applications and the terminal emulator happens through an undocumented interface (using LPC) and there's no provision for putting another emulator in its place. In Windows 7, the console windows are displayed by conhost.exe, and you'll see one conhost.exe process in Task Manager for each open console window. In XP and earlier all console windows were put up by the single privileged process csrss.exe, but after one or two instances of bugs in the terminal emulation leading to a compromise of csrss.exe and hence the whole system, they switched to the current model.

In Windows 3.1, each DOS program (such as command.com) ran in its own preemptively multitasked VM (while Windows apps were cooperatively multitasking in a single shared VM). They could write to the screen by calling DOS/BIOS functions or by directly writing to the screen memory, which usually started at B800:0000. When they were running in a window, the text memory was (I assume) scraped by Windows which then displayed it in a window. You could switch into a graphics mode and that would be rendered in the window as well—a nice feature that I wish existed in modern terminals on Unix and Windows. Modern Windows still limits you to 16 colors in console windows, which is a relic of the IBM PC text mode, and it still (in many locales) uses a special code page for console windows which contains box-drawing characters and other weird IBM PC stuff. In Windows 9x I think it was the same, except that Win32 apps could also run in console mode, and I don't know how that was implemented. -- BenRG (talk) 03:25, 28 January 2013 (UTC)[reply]

To expand a bit on the first paragraph, in contrast to Unix, all of this is implemented in user mode; the kernel doesn't know anything about console windows. "Console handles" are not real kernel handles but magical values with meaning only to kernel32.dll (and kernelbase.dll these days, I guess). There are special checks for these handles in some general APIs—e.g., WriteFile calls WriteConsoleA instead of its usual NtWriteFile syscall. It's in the bowels of those DLLs that the private interface with the console process is handled. In principle it would be possible to reverse-engineer the protocol and make a replacement terminal, but it would be a systemwide change and seems kind of dangerous. If you look in HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows, there's a part of the command line that says "ServerDll=winsrv:ConServerDllInitialization,2". That's the handler for console-related messages. You could replace winsrv (which is a DLL) with a work-alike. Probably not worth it, though... -- BenRG (talk) 03:52, 28 January 2013 (UTC)[reply]

In Windows NT, cmd.exe is THE command prompt. It shows the command prompt window, interprets the commands, and carries out their executions. If you typed, say, "DEL *.TMP" in a command prompt window, it is the code inside cmd.exe that interprets it as a command to delete files and calls the appropriate APIs. 180.245.210.151 (talk) 04:50, 29 January 2013 (UTC)[reply]

As I said above, it doesn't draw the window. Also, modern Windows ships with a second shell, Windows PowerShell, and there's no barrier to installing third-party alternatives because that side of the interface is documented. Other than that you're right. -- BenRG (talk) 17:54, 29 January 2013 (UTC)[reply]