The Software Purist |

CAT | Developers



How to Create a Windows 7 Kiosk

A friend of mine recently posted an article on how to create a Windows 7 Kiosk, which would basically restrict a user to running only a particular program, and provide no shell access or access to windows explorer. The original article is in Russian and can be found here: Fortunately, through the magic of Google Translate and my limited understanding of Russian, I’ve translated the instructions to English.

It starts out by saying that he recently learned, and is publishing, so he doesn’t forget the instructions. This can cover the case where you have to put a payment terminal or control program, but done in such a way as to ensure that nothing more than what can be seen on the computer screen can be accessed. Performing this action on Linux or Unix is very simple, just replace the current window manager. To do this on Windows, perform the following steps:

  1. Create a user which will use the kiosk. Give him administrative privileges.
  2. Login as this user.
  3. Change the window manager by default on a program that will completely own the session:
    1. run regedit
    2. Find the following key: HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
    3. Add a new field of type string named Shell and set its value in the full name of your program for example: C:\Myprog\myprog.exe
    4. Close the session and login again. Instead of the usual screen, this should start our program and nothing else should be on the screen of should exist (no desktop or Start button). When you close the program you should just see a black screen. This is very useful if the program closes the output at the same time as the Windows session.
  4. Now all polish, as the primary administrator login and drop kiosk user to normal levels. It should not be an administrator. Then, in Windows 7 is the mode of parental control. Include it (for natural kiosk user) and allow run only one program, then for user, all attempts to start something else will be prevented and the fact all, the process can be automated to a simple script if you need to configure a lot of machines.

· · ·

I was interviewing a candidate recently, and we were talking about some of the programming languages he claimed to know, which was mainly focused around C++ and C#. We started to discuss some of the types of problems he finds easier to solve in each when he said something I found very misleading: “A programming language is really just syntax”. As we talked more, I started to ponder what a shallow understanding of a language this really was. It’s kind of like questioning whether a dollar is a dollar is a dollar. Smart financial people know that the source of the dollar is very important, and so the utter simplification is misleading.

Before I get too far into this, I will note that if you’re using .Net, you can get a lot closer to making the premise of the initial argument, because the .Net languages all can support the same APIs. That wasn’t the case for this individual, as he was using C++, not C++/CLI. With that being said, let’s get into some of the real substantial differences:

1) The standard libraries that the language supports. I find this to be one of the most underrated aspects of working with a language. I think part of the reason is that when you use some languages (C++) there’s a large population of programmers who don’t really make good use of the standard libraries. In my experience, this is often because they sometimes fall into using non-portable APIs, such as Microsoft’s ATL or MFC instead of STL containers, or libraries that may be considered more suitable for an embedded environment. Anyway, I think this is a critical feature, because, again consider the example of C++: Something as commonly used as XML is not standard. This is almost unfathomable for programmers of languages like Java or C#. Meanwhile, the flipside is .Net, which is immense and becomes very difficult for a developer to be proficient in all of it.

2) Third party libraries the language supports. I would consider this almost as important as the standard libraries issue. Unlike the standard libraries, there’s a much better chance that the third party libraries have API interfaces to be used in multiple languages. This will be one of the the top things you would consider when choosing the appropriate language for a task.

3) Language Paradigms: This is another feature which gets underrated at times. Does the language properly support Object-Oriented Programming? Template Meta-Programming? Functional? How easily does it support multi-threading? Again, all of these are critical differences between languages which go well beyond syntax.

4) Static Typing or Dynamic Typing or Both (coughC#cough)? With static typing, you can potentially find a lot of structural errors during compile time and need less code coverage during your unit tests. With dynamic typing, you don’t have these luxuries, but have much better support for rapid development.

5) The tools that are supported for your language.

6) Syntax. I consider this one of the least important differences between languages. It’s very easy for a professional programmer to adjust to a new syntax, assuming it isn’t completely nonsensical.

In the end, I think of this like deciphering any sort of spoken or written language. At the end of the day, if you aren’t able to communicate effectively, then your words are meaningless. This goes far beyond sentence structure. When discussing programming languages, it goes far beyond syntax.

· · · · · · · · ·

Theme Design by