Hi, Another random thought of mine (more towards a question): As I think about recent security discoveries and I dive into learning more about data structures and Windows CE operating system, I thought of questions that are asked on this list on roots of problems - things that cause a problem to occur and what to blame for it. Some problems we have on our units are definitely caused by KeySoft, namely braille translation, odd user interface elements (prompts) and so on. Others are thanks to the operating system, such as bad memory management on some units, somewhat long reset times and so on. Still others are caused both by KeySoft and the operating system, and in some instances, are caused by neither of these. So I'd like to ask (for your opinion): what should be the boundary between KeySoft, the operating system, both or neither of these when it comes to narrowing the source of problems with our unit? I'm asking this feedback question for three important reasons: To demonstrate that what may seem KeySoft's fault may be caused by the fault of the operating system, how to distinguish the limits between keysoft.exe (KeySoft) and nk.exe (Windows CE), and to define our understanding of how KeySoft actually works and understanding software development processes (for benefit of would-be "geeks"). In my opinion, the defining characteristics of distinguishing KeySoft and the operating system (when it comes to finding the source of a problem) is the feature set and roles of these software. The Windows CE operating system (we have three generations of these OS's), or any operating system, is the core foundation of how computers work when it comes to talking with software and hardware.--Source: The Elements of Computer Systems. Both extremes of these layer - devices and programs - need a "middle man" to help them "come to terms with each other." This "middle man" is the operating system, a special program that allows user-created software to run on many hardware. Among the operating system "box", there are bound to be many layers on top of each other, providing services such as managing RAM and what data should go there at the right time, communication between specialized hardware and software, and even representing a computer on a network (memory manager, device driver and network client, respectively). Thus Windows CE, like any computer operating system (technically a specialized operating system) would be and is responsible for providing basic foundation from where keysoft.exe (and other friends i.e. programs) would run. The most likely problem that can (and could) be traced to the operating system is memory management. In simple terms, bad allocation of memory by the operating system could cause malfunction of a program, particularly if the program uses a lot of memory to work with huge data sets. In worse case scenario, the operating system would not have enough memory to run further programs or store more files, causing slowness and requiring a reset to "fix" this problem. A typical root cause has been and still is not deallocating, or not throwing away memory which has been used for a while but it's not usable anymore (called memory leak). This problem, unfortunately, cannot be fixed on mPower units due to older operating system routines, although an optimal solution could be made (and I don't see it coming). The second most notable problem is hardware support, or malfunctioning hardware. This problem is technically a hardware issue, but a small part (or sometimes, a huge part) of the operating system is involved in this "fight." A typical routine is that the user would automatically assume that a some kind of hardware would work on a BrailleNote. For most of the time, it works, at least when we speak of theories; however, the thing that dictates whether a given hardware would work or not is vested in device driver and operating system support for that given hardware. For instance, Bluetooth headsets are not supported on the mPower due to the fact that headset support came in Windows CE 5.0; similarly, formatting a flash drive to NTFS would work on regular computers but not on Windows CE because it does not support it (technically, it means that is no NTFS driver). In rare instance, the problem itself is caused by the hardware in question - mostly because it needs more power than what the operating system (power management) would allow it, or there is simply no way of Windows CE recognizing that hardware. The notable instance is power supply problems on the BrailleNote Apex when dealing with large capacity hard drives. Thus, anything to do with the operation of the unit, particularly when it comes to hardware and basic software is vested on Windows Ce, not KeySoft. As opposed to operating system, KeySoft (keysoft.exe) is not an operating system - it is a user interface and an environment. Just like any programs, KeySoft does whatever HumanWare programmers have told it to do, such as using its own file type for storing information. An important distinction to make in this logic is that KeySoft knows "nothing" about operating system details, nor it can emulate what a typical operating system can perform in "deeper" levels. For instance, it is not keySoft which allows you to connect to the Internet via wireless communication - it's the operating system (more towards Connection manager) that provides this service; KeySoft merely tells you what the Connection Manager is doing via its own way of reporting to you. Similarly, it is not KeySoft which can control what happens if the power switch is flipped to "off" position - it's the power management portion of nk.exe (Windows CE kernel) that dictates various power states (I'll explain how they work upon the approval of our geeks group). The only concern that we can make about problems with KeySoft is when it is not displaying correct braille grade for reading, odd prompts or general features that KeySoft offers using its own way of presenting information. (And I do know that when I go further, I may hit a collision point where I might talk about more theoretical stuff, so I won't go there.) But with the advent of Apex and its supposed infrastructure, the defining characteristics of finding problems with keySoft is changing - it's now directed more towards performance of keysoft.exe when it comes to taking advantage of OS resources (yes, programs need resources from the operating system to run efficiently, and the study of efficient execution of programs is another subfield of computer science). In summary, what really allows us to narrow down the root of a problem is understanding the role of keySoft (as a user interface) and the operating system (providing basic foundation from where KeySoft can run). If we do know the roles they play and the nature of a problem, then we could (to the best of our ability) narrow down the problem to KeySoft, Windows CE, both or neither. In case of recent problems and discoveries, the FTP access was definitely an operating system problem, battery problem was hardware, spell checker was KeySoft's feature set and so forth. Personal opinion: I keep noticing that we tend to blame KeySoft for majority of our problems. Some of them did turn out to be keySoft's fault, but I think the majority was operating system and hardware. In case of reports on Apex, it is a combination of operating system, keySoft and other factors. Since the problems are too numerous to describe in this paper, I'll write two notable cases to demonstrate this phenomenon: * Is KeySoft 9.0 a redefined KeySoft 8.0? Yes. The user interface is "same" (almost the same) as 8.0 but was "tweaked" to work under the new operating system. This, in my opinion, is where the majority of the reported "problems" can be traced back to: Many users expected KeySoft 9.0 to run faster (way faster) than previous versions and have better features. As we have seen here in the past year (proven both theoretically and in user testing), KeySoft is not taking advantage of vast resources presented by the operating system. Although memory management is better on Windows Embedded CE 6.0, the way keySoft works (internally) makes us (the geeks) wonder if we do have significant changes "under the hood". The supposed free upgrade promises Word support, so when Humanware releases it (it was said numerous times that it'l come before end of this year), we'll have a field go at finding out if KeySoft has improved. * Memory woes on mPower: Is it KeySoft's fault, the OS or others? The answer: it was a combination of OS and hardware. Here, the OS is to blame the most, as it uses "old" way of working with memory. Only in keySoft 8.0 did HumanWare took steps to alerting user of that fact - the fact that resources were limited under Windows cE.NET 4.2. Then it led to the following question: Would burning a new ROM with older keysoft.exe solve this problem? No. As it is the fault of the operating system at that time, the only 'real fix" would be burning KeySoft AND an improved operating system at the same time, which led to the whole discussion on hardware suggestions. Then the question became, "what if we run KeySoft on a new platform which is more modern than that of mPower?" The answer: yes, no and perhaps. Yes, because KeySoft would have more room and, if written right, would take advantage of more modern platform. No, because rewriting keysoft.exe would take time, as developers need time to adjust to new design specifications, and simply using an old executable under newer framework would not work always (I'm sorry to disappoint you, Josh). Perhaps, because there might be something that is different about that new platform that functions from old executable would not be supported, or user demand might "cripple" some fundamental software routines (as programmers need to keep deadlines in mind). This last fact is something that I believe we as consumers need to remember the most: it takes time to write a simple routine such as creating a Blackjack game, with most of our (programmers') time spent on coming up with design and debugging our code. Don't take this argument the "wrong way" (as I could already imagine response to my email) - we do wish to write these kind of programs, but coming up with how we should do it and testing it is something that only programmers can understand - it takes time, and I'm glad I'm learning these development principles as I learn more about advanced data structures such as stacks, queues and trees. Hope this helps. As I always say, if you have any comments, feel free to email me. (Alex, I have a special treat for you later) Cheers, Joseph S. Lee University of California, Riverside
___ Replies to this message will go directly to the sender. If your reply would be useful to the list, please send a copy to the list as well. To leave the BrailleNote list, send a blank message to [email protected] To view the list archives or change your preferences, visit http://list.humanware.com/mailman/listinfo/braillenote
