Winbee Thin Client Os
Windows 2003 Terminal Server, Remote Desktop, thin clients and all thatI've removed advertising from most of this site and will eventually clean up the few pages where it remains.While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.If you found something useful today, please consider a small donation.Some material is very old and may be incorrect today© November 2004 Tony LawrenceCitrix, Terminal Server, Tarantellla, Web Enabled, Thin Client,Diskless Workstation, Dumb Terminal, Smart Terminal, Client Server,or related Remote Desktop, VNC, GotoMyPC, Screen Scraping, blah,blah, blah. No wonder people get confused.
Lots of similar orrelated things, no end of licensing confusion, no end of generalconfusion.Let's try to cut through some of it. First, let's move back andlook at the original Unix style multi-user model: dumb terminals,green screens (even if they were orange or white), the characterbased environment that all Windows folk loathe and disparage. Howdid that work? The application ran on the Unix server, and onlysent characters back to the terminal, and the terminal only sentkeystrokes to the Unix box.
This is the hateful environment ofUnix, disliked not just for its esoteric character based commands,but also for the centralized control, the lack of empowerment forthe user, and for the priesthood of the central serveradministrators. Funny, but the priesthood is back, along withcentralized control, lack of empowerment, and all that. All that'sdifferent is GUI vs.
Character based.And that's not even fair either, because Unix has had GUI remoteaccess for some time: X Windows. Again, the real application runson the CPU of the server, and the client (the X Terminal) justsends key and mouse events and then displays the screens that thecentralized server app sends back.
The X Terminal can be a standalone device not a whole lot smarter than a dumb terminal, or itcan be a piece of software running on a PC or other computer.Whatever it is, we're still in the same 'mainframe' mindset: theapp runs on the server. Client ServerAt some point, someone realized that it might make sense to havethe client do some of the grunt work. Maybe it's as simple as justcaching some graphics, but more likely it means hiding anunfriendly server app from the user. This can make things easierall around: put raw power in the server application, but don'tconcern yourself with user friendliness.
If you need a list of A/Rtotals, just have the server dump that information: no formatting,no prettiness, no grand totals, no headers, etc. Put some smarts inthe client to do the pretty-it-up stuff. The server side might belittle more than a database that takes SQL queries and spits backresults, but the GUI-fied client running on a PC (or whatever -could be running on a Solaris SparcStation) hides all that.Now, the important question: is that a 'fat' client or a 'thin'client? And the answer is: who knows? It depends on who is lookingat what and what they think is important about each side of thesystem. Who does most of the heavy lifting?There's also a very special kind of client, designed for oldcharacter based apps. This GUI-fies the old Unix app, adding menusand mouse capability etc.
It may involve a new app added to theserver that helps it talk to the old app, or it might do 'screenscraping' - figuring out what's going on by reading characters fromthe screen. Or it might do both.
Windows, the single user OS that isn't reallyEnough about Unix, at least for now. Enter Windows. Windows appswere originally very 'fat client'. If they used a server at all, itwas for file and print services: the data might be stored at theserver, but the app ran at the local PC. That's as 'fat client' asyou can get: the server's involvement is very small.
Important, ofcourse, but it's not doing much real work. There are still lots of'multi-user' Windows apps that work that way. But eventually peoplerealized that the server could run the app just like it did on Unix(except with more interruptions from crashes, of course) and a thin(or thinner) client would run at the PC.In this situation, the Windows server is acting just like theUnix server did: the central app runs on the server, clients onPC's send commands to it and process the results.
In fact, this isso much like Unix that some app vendors let you choose your serverOS: they have Windows versions, Unix versions, Commodore 64versions. Well, maybe not that, but the idea that the server partof the app could run on Windows or various flavors of Unix is stillpopular with bigger and more important apps. There's a Windowsclient, but the server can be whatever you want. Remote Desktop, VNC, etcThese types of products have nothing to do with what we aretalking about, except in the sense that they are thin clients forthe biggest app of all: the OS desktop. They all have differentfeatures and capabilities: they make take total control, they may'share' with the machine's real user (great for training), but theimportant point is that they are running the machine's desktop. Ona Windows machine, that's as far as you go, though of course with aUnix box there could be multiple possibilities.
But let's notcomplicate that.However, Remote Desktop is extremely similar to the WindowsTerminal Server client we'll be talking about next. So similar thatyou may find the clients talked about in the same context, and atleast on some platforms, you might use the same client software toaccess either Remote Desktop or a Windows Terminal Server. Even ifthere is different software, you might me able to use the TerminalServer Client to access Remote Desktop. I only mention all that soyou know that is why some discussions of one or the other may beconfusing. Terminal Server, Citrix, TarantellaNow we come to the more interesting stuff.
The idea behind allall of this is to let the Windows machine run more than one copy ofan application. Why limit yourself to one desktop? Why nothave a copy that the client off at the other PC can individuallycontrol? Think of the benefits: one application to keep patched andcurrent. One big muscular server to run this stuff, much weakermachines for the clients. Control the environment they see: maybethey only get one specific app rather than a whole desktop!
Or ifthey do get more general purpose use, we can lock them down muchmore easily to specific settings that they absolutely cannot messwith no matter how much they may know about their PC. Centralizedcontrol, money saved, security improved, wow, this is great!Well, except that it really wasn't so great, at least so notwhen it first came out.
Nothing wrong with the base idea, heck,that had been proven and tested on Unix for many years. And nothingreally wrong with the server software or the PC clients that letall this magic happen - oh, there may have been bugs here andthere, but those get cleared up. No, the real problem was theWindows applications. Design BasicsThe problem was that the Windows apps were seldom designed to bemulti-user. They were written to run by themselves on their ownmachines, and they tended to not like keeping separateconfigurations etc.
For multiple users. The multi-user software onthe server could do a few things to fool the apps, but a poorlywritten app would still screw you up royally. So the early promiseof this fell very flat: I saw many a business embrace this idea andtoss it out a year or so later.That was some time ago though. Nowadays, most Windows apps (theimportant ones, anyway) have been rewritten to be multi-userfriendly. You can run Terminal Server (or Citrix, Tarantella, andwho knows what else) and access apps with much weaker clients.
Winbee Thin Client Os Download
Theclients may not have to run on Windows PC's either:Macs, maybe evenyour can have clients to access the apps.All you need is licenses - both licenses for the multi-user accesssoftware AND licenses to run the apps multiple times. That can allbe very confusing, see for some help with that.By the way: Microsoft makes you buy licenses for products like Wordetc. For each computer (terminal, whatever) that will connect and usethe product. No 'floating' licenses are allowed.This can get really confusing: see Let's get really complicatedOK, time for a test. Here's the situation: we have a Unix serverthat runs a Cobol application.
It uses what it calls a 'thinclient' app that you install on Windows machines. You also haveremote offices and they tell you that the best way to handle thatis to install Terminal Server. Their thin client, installed on thebig Windows 2003 Terminal Server, will access the Unix box. So -remote clients access the Terminal Server to run the thin clientwhich actually talks to the server app on the Unix box.
Need apicture? Windows Machine Running Terminal Server Client Windows 2003 Terminal Server running application's Thin Client Unix box running application server component Do you see that a thin client is running another thin client?OK, two questions?
Do they need the Terminal Server? If I do usethe Terminal Server, does that mean ALL my Windows PC's have to useit?If you've read and understood all of this, you know the answers.First, no, they don't absolutely need the Terminal Server. Theirconcern probably is speed because your remote machines aren'trunning at local network speeds.
It's possible that theirapplication doesn't like waiting for things too long and willmisbehave if you don't use this method, but more likely it's justthat performance will suffer. Still, app vendors are always lookingfor excuses when their software bombs, so if they say they wantTerminal Server, you probably should do it their way. But thatdoesn't mean that your local PC's need to access the app that way.Assuming they have the horsepower and appropriate OS to run theapp's thin client, they can bypass the Terminal Server and gostraight to the Unix box. However, you may have other reasons tosend them the circuitous route: you may have older, weaker machinesthat can't handle the app's not-so-very-thin client, but could runthe Terminal Server Client. Or maybe you've just had it withMicrosoft's never ending problems and you want to run Linux or MacPC's - they can run the app's Windows Client by way of TerminalServer. Carried to the extreme, you might need only ONE Windowsmachine to care for. That's a comforting thought, isn't it?Also, here is a nice chart that.From Linux:.If you found something useful today, please consider a small donation.Got something to add?
November 19, 2004Hehe. And people get confused by X Windows networking.Mostly terminology.
Too ancient for todays PC's server/client model:X Servers = X Windows software that runs on the X terminalsX Clients = Programs that run on X Servers. (like Firefox Web browser is a X Client)Think about it like the X Server serves the keyboard, pointing device, and monitor I/O 'up' to the X client program. Also remember the X Server runs on the same computer as you are on.Quite weird. Well, that's 1986 for you.Also VNC works differently when it's served up from a Unix/Linux machine then what it does on Windows. Because with X windows you can have multiple X Servers you can setup VNC with a completely new and unique X Server for each user that connects. No remote control mouse thing like you get on Windows, each vnc session gets a unique desktop.(this is what originally VNC was made for, if I remember correctly)So when going from a X Windows served VNC to a VNC client on another PC that would mabye be a medium client? Or a think, or half-baked client?:PGood article, though.
Who wrote it?-Drag-November 19, 2004I wrote it (if you don't see an author credit at the top, it's me).I didn't want to confuse the VNC stuff on Unix - obviously VNC can be multi-user on Unix because Unix is automatically multi-user.-TonyLawrence-November 19, 2004Oh.For a long time I figured VNC was the same in Unix as it was in Windows, until I tried it and it confused the snot out of me for a little while. So that's why I mentioned it.-Drag-November 19, 2004I think it's good you did - I just didn't want to get the original article all confused by it.
Comments are a good place to talk about it.-TonyLawrenceFri Jun 24 15:: 704 LytleDavidSmithVNC on Unix is very much like Terminal Services on Windows. Each user gets his own desktop.When you use a VNC client on Windows to access Unix, it may seem like the VNC client is simply an X-Windows server that runs on Windows, but that it not the case. VNC does act as an X-Windows server, but the VNC X-Windows server actually runs on the Unix system. The VNC client then acts to remotely control the VNC X-Windows server from the Windows system.It is very much like the example in the article where you use Terminal Services to execute a mainframe thin-client, only with VNC accessing Unix, the mainframe thin-client (VNC X-Windows server) actually runs on the mainframe (Unix server), so to speak.Tue Oct 25 14:: 1241 taplintoysI just recieved and set up an HP T5500 I won on eBay for $100 + shipping.
It runs WindowsCE with Internet Explorer (OK), Media Player (buffers poorly), etc. Plus an RDP terminal client and emulation of some traditional UNIX clients, which might be nice for an aging cross-platformer like me. I have not yet tested the non-RDP client apps.WindowsCE is both impressive and underwhelming. The learning curve is near zero for anyone who knows Win98, 2K, or XP, but limited storage and features frustrate a desktop app junkie. Microsoft did pack a lot of familiar goodies into a small package. I was able to use the CE control panel to setup its IP seconds after plugging in, with almost no earlier WindowsCE experience.I tried to play a small video off my website with the built-on Windows Media Player. The clip started and sounded OK at first, but choked ten seconds in.
No biggie, I thought, except this box lacks the space to download and play locally even a tiny video. Still pictures looked great once I right-clicked the desktop (just like XP) to raise the default resolution to 1024x768 true color.I concentrated next on using the RDP client with my test Windows Terminal Server. Worked as well as any other RDP client I've tried. The only things missing are the GUI speed necessary for most games and multimedia, sound (why?), and a current Java runtime. I am unsure why RDP gets no sound when the CE-based apps play it nicely. Maybe I'll find a software fix for that.For kicks I also tried the original Unreal over RDP.
It ran, but the response time was intolerable and again, no sound. Civilization 2 with its minimal requirements played better. All my 'business' apps and Visual Studio 2003 loaded and ran via RDP without trouble, and surfing was fine - this posting is evidence of that, being written in an RDP connection.So first impressions of the HP T5500 are:1. Cheap, small, and silent are all selling points2. Great work-pony if you do not need multimedia3.
Near-zero client maintenance = good kiosk box4. Can surf even if Terminal Server is briefly down5. No games and no multimedia.
I guess I won't giveup those traditional PC capabilities willingly.Good, not great. Big step up from a Sun Ray - which I tested thoroughly before selling off - because I can run most of my apps, including open source apps - smoothly on Server 2003.
If nothing else, this HP might make a nice travel tool in any hotel room with a LAN port. Also on our porch in the summer, or later in my son's room when he's old enough to study but not old enough to be trusted with a PC.Thu Sep 6 18:: 3113 MarcAnother tool worthy of consideration is NX, which is quite a bit faster than VNC and can also proxy VNC and RDP and provide some speedup.Here's the free server for Linux:-Marc.
Thin client users squawk about their desire to get the latest and greatest look for their thin client desktop. Running Windows 7 on a thin client is possible, but constitutes challenges caused by its more robust set of minimum hardware requirements. The process of installing Windows 7 on a thin client, therefore, is similar to installing Windows 7 on any machine that lacks the horsepower and other resources we would prefer to have supporting it.The following are some special considerations to make when installing Windows 7 on a thin client to maximize your chances for success.Image Credit: Wikimedia Commons/Cspurrier Hard Drive SpaceMicrosoft’s official minimum system requirements for Windows 7 say that 16 GB of free disk space is necessary for installing the product. Although some thin clients may have more than enough drive space available, double check the storage capacity on your thin client before attempting installation. This is especially important if you have a thin client such as the, which comes equipped with a very small amount of flash memory for storage. Standard PCs that are usually present a simpler upgrade path.If you want to be Installing Windows 7 on a thin client computer that is still in use, consider removing the existing hard drive and attempting the installation on a freshly formatted drive. This will preserve your thin client’s configuration in the event the upgrade to Windows 7 doesn’t work.
Additionally, the Windows 7 upgrade process may introduce problems with disk space, resulting in a failed install.Once the operating system is installed, consider compressing the drive if you need additional space to install local Windows applications. Memory and CPUWhen installing Windows 7 on a thin client, memory could be a factor. Although Microsoft calls for Windows 7 to be supported by 1 GB of RAM, many people have successfully configured it for use on as little as 512 MB. A thin client with less than 512 MB of RAM, however, will pretty much rule out the installation of Windows 7 without first performing a hardware upgrade.For many new thin client computers, memory is no problem. For example, the HP GT7725 comes equipped with 2 GB of RAM, more than enough to handily run Windows 7.CPU requirements can also be a deal breaker for thin client installation of WIndows 7. Although the OS will install on machines running slower than 1 GHz, the system will run very slow, especially if limited to only 512 MB of RAM. Modern thin clients, however, have different considerations because many run Eden processors by VIA or other non-Intel compatible CPUs.
Hp Thin Client
Thin clients like the GT7725 can run the OS with ease because they are equipped with x86 CPUs.