The February newsletter is online now. There’s a review of the old methods of screen captures, the NEW Windows 10 and Windows 11 screen capture options, the Snipping Tool, and what errors tell you. And what they don’t. View the February 2023 newsletter here free, or subscribe here for free.

The post February 2023 PC Updater News: Capturing Errors appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: February 2023 PC Updater News: Capturing Errors.

Twice a year, test your backups. Make sure that every category of your computer technology is actually backing up in a way that it will be where you need it, when you need it.
Oh, and move your clocks one hour forward on the morning of Sunday, November 5th, 2017.

Time to Test Backups

Jerry Stern
Chief Technology Officer, PC410.com

The post It’s Time to Test Backups appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: It’s Time to Test Backups.

Definition: By hacker I mean someone who for the most part, cannot create something from scratch. However they are very good at morphing code that others have written.

Well, I learned a lot of programming by hacking, in the old definition, as in someone who takes stuff apart and tries to make it do more stuff. In my case, I reverse-engineered file formats for program code for a programming language that no longer exists–that was Texas Instruments Extended BASIC for the TI/994a Home Computer, back in the 1980’s. Pulling that information apart and understanding the proprietary format allowed me to write programs that modified programs, mostly to make them easier to edit; there are still online copies of that around, if you search online for ‘MICROpendium Magazine’ and the program called ‘SubIndex’. It was great training.

Now, most companies specifically prohibit reverse-engineering of their products, so when it’s done, it doesn’t get published. What’s evolved since then has been more along the lines of code sample collections on the various crowd-sourced programming language how-to sites. There are work-arounds of just about any problem you can think of, and many, many of these cover topics that the official sites for the products involved won’t cover at all because they don’t want to endorse a solution that they haven’t tested in-house.

As a programming approach, I’ve always saved every chunk of code as a function or a subprogram. And then reuse code, over and over. And I pull code out of my web sites to use on my other sites just about every month. It saves time.

Yes, I’ve gone your way, and written elegant recursive code that did the impossible in one page. But that’s too much like work for most quick tasks. A quick assembly of saved parts and my prior projects is the preferred approach for me.

Jerry Stern
Chief Technology Officer, PC410.com

The post Learning from Existing Code appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: Learning from Existing Code.

I’m wondering if the term Hacker means different things to different people. When most people hear the word hacker what are the first things that come to mind?

Hacker, back in the early days of PCs, originally meant someone who climbed into the internals of technology to make it do more stuff. In hardware, we would take an IBM diskette drive, test what happened with every jumper setting, maybe add a DIPP switch to make testing easier, and then hook up the result to a Texas Instruments 99/4a computer, where it was never designed to go. Or read program files from diskettes in pure binary format and match up numbered commands with programming symbols to make programs that could modify programs, usually to add formatting and fix line numbering. Then, it was all positive, and “no reverse engineering allowed” statements hadn’t evolved yet.

NOW, hacker is used more in the negative sense, like cracker, which generally includes creation of cheat codes, bypassing sections of code for various reasons, and so on.

The way technology words enter the mainstream vocabulary is mostly through television and movies, and Hollywood is nearly as sloppy with tech words as the evening news, so ‘hacker’ is mostly used in the negative sense by most of the mainstream media. But a hacker isn’t inherently evil.

Jerry Stern
Chief Technology Officer, PC410.com

The post Definition: Hacker appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: Definition: Hacker.

As a one-person independent software developer, what are the major challenges you faced? How did you
overcome these challenges?

There was a time before the internet, yes, even before it was still ‘The Internet’, when being a one-person development company meant you worked alone. Wrote code, wrote letters to customers, on actual paper and snail mail, did your own artwork, everything. The result was a very real reluctance to allow ANY part of a project to be done elsewhere.

That’s over. Now, our programs & apps have to run alongside other programs, share data with other users of the same apps, check for updates, sell upgrades (and power-ups), and be visually stunning and immediately obvious to use without a bound instruction manual. It’s too much. You can’t do that alone; you can’t even visualize it without loads of feedback from experts in each area.

We can outsource graphics. Or web sites, animation, speech recording, writing, even blocks of code, if it gets the project done. Now, it’s a management job, rather than doing every little piece of the project in-house. You don’t need employees, but you do need trusted partners to do the tasks you will (reluctantly) admit that you can’t do yourself in a reasonable time. Or just don’t wanna.

So does that mean hire outsource help? You could. Or if you work with other programmers, or know programmers from the ASP, you can offer to trade technical expertise for help in other areas.

Jerry Stern
Chief Technology Officer, PC410.com

The post What are the major challenges you face as a micro-ISV? appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: What are the major challenges you face as a micro-ISV?.

I have a good product in my mind and want to invest more time and money in it.
So far whatever small software I have created are for few people and with only me developing that software. Now I have some software in mind that will be for more users and big enough to include other people, and I will be the first customer of it (manufacturing is my prime business). How & where should I start ? ( people, office, location, software developing, release, sales ) ?
Any first hand experience is also welcome.

First, understand the difference between a program and a product. A program works for you. A product makes sense to other people. So you have to add error trapping, fix all possible input errors automatically and give a non-techie error message on anything else. That requires testers who don’t know anything about your product, and the best type are the ones who you can watch trying out the product. (While you don’t help, but do take notes.)

You have to make it look good. It has to be visually striking, while immediately understandable. You have to write documentation, and that, depending on the product, could be an old-fashioned instruction manual, or a video demo, or a set of slideshow tutorials.

People, office, location? There’s no short answer. Like any other business, your staff will have to be able to communicate skillfully with your potential customers. Being near those customers, or some of them, will give them a big advantage in learning what’s needed, and in beta testing, and perhaps give you leads for hiring sales staff.

Sales used to be all web downloads, and before that, mail order. Now, unless this product will be highly specialized within the manufacturing industry, your choices are web sales of a downloadable and installable product, or SAAS/software as a service/cloud. The difference will be the answer to this question: Where will it be used? On the manufacturing floor, where network access is likely to be internal only? Or in the manufacturer’s offices, which will have outside access? IOW, there’s a big difference in how you sell manufacturing control software, versus purchasing department software, because one needs tight security and the other needs access to outside product specifications and availability in real time.

Jerry Stern
Chief Technology Officer, PC410.com

The post How to start a software company? appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: How to start a software company?.

I assigned copyright to a client for an mobile app, can I develop a new similar app to sell?

That question comes down to what’s in your original agreement, and in particular whether (and how) ‘derivative works’ were included or excluded. You might want a lawyer to look it over.

Here’s my non-lawyer view: In the most restrictive case, where you sold everything as a “work for hire” and agreed not to create derivative works, you still have the right to create a new similar app to sell, but only if you use none of the code and images and development work used for the original app. Start entirely from scratch. That’s basically how the Compaq computer was created as a clone for the IBM PC, but Compaq took an extra step: One team created a set of requirements for a clone of the IBM BIOS software, and another team, with no overlap, wrote the new BIOS.

Put another way, if i write an article for a magazine (remember those?), on any given topic, and I’m paid for it, I can still write another article on a similar topic for some other magazine, and get paid for it. And I’ve done exactly that. The results changed dramatically because the audience changed, but the initial topic was the same. Your knowledge gained during the first project is yours. You’ve only sold the product of that knowledge.

Jerry Stern
Chief Technology Officer, PC410.com

The post I assigned copyright to a client, can I develop a new similar app? appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: I assigned copyright to a client, can I develop a new similar app?.

Telecommutes and remote control for business computers require software. Several types exist; not all of them work for telecommuting.

• Remote Repair: This is for remoting into a computer for repairs or training, and it requires a person at the computer being controlled, to click a link or run a program. The software used for the connection goes away after the connection is closed, so you can’t log back in without starting over.
• Managed Services: This is for working on computers unattended. I use a program like this, that lets me control hundreds of computers on-demand. While it can be used for working remotely, perhaps for an entire office, it’s not the economical choice for telecommuting.
• Remote Login: This is for telecommuting. Like the managed services software, it can connect to an unattended computer, but it will generally be easier to use, and add features like remote printing (print in the office, to your home printer), and remote sound (you hear the office computer’s sounds from home).

There are some other considerations before choosing to telecommute. If your office has gone to the cloud, just log into the cloud servers directly from home. Check with your MIS (management information systems) department first, to see if they have any limitations in place; some systems will only allow logins from work locations. If you run processor-intensive programs, like dictation and speech recognition, it’s better to install those locally, and then just send the completed documents to the work machine.

In Maryland, call us at 410-871-2877 for help getting up and running with telecommuting. We’ve worked with many programs, and can recommend both free and paid products for most requirements. Outside Maryland, we may still be able to help, by remote login, of course.

The post Telecommute: Preparing for Polar Vortexes, Super-Flu, and Road Closures appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: Telecommute: Preparing for Polar Vortexes, Super-Flu, and Road Closures.

It’s getting late for backups now, but you should always have these backups for each computer:

• There should be a full-image backup of the hard drive, on a removable device, usually an external drive, less than 3 months old, for restoring a burnt/crashed hard drive
• There should be a documents backup, not older than the amount of work that you can easily recreate, on a removable device. For businesses, that’s usually one day old.
• There should be another documents backup, from a week or two older than your newest backup, in case the newest backup is incomplete, lost, or zapped.
• A backup device that is removable, but still plugged into your computer when a storm arrives, doesn’t count as a backup.
• Finally, there should be an online backup of documents. Online backups should be encrypted before leaving your computer.

Overall, you’re aiming for three copies of all data, on two different types of devices, and one copy of data that is off-site. All of these backups can be automated. Ask me how, if you’re in central Maryland.

Jerry Stern is webmaster at PC410.com and Startupware.com.

The post Backing up for Hurricane Sandy appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: Backing up for Hurricane Sandy.

OK, great program. Now, what’s next?

There are some basic differences between a program and a product. Most software developers understand many of these instinctually. As a program becomes a product, on-screen messages are made more specific. Screen layouts are more polished. Errors are trapped and result in plain-text messages that help resolve problems, or even-better, are user-proofed so that incorrect procedures still create great results.

But that’s mostly programming code and artwork. The biggest difference between programs and products is the documentation. Specifically:

• Sales pages and advertising.
• The user manuals.
• The instruction books.
• Help files.
• Screen shots, slide shows, and videos.

If these are missing or are incomplete, the product won’t sell like it could, or at all.

There are several basic and common errors in documentation for modern software that aren’t quite product-ready:

• Not writing documentation. (You know who you are…)
• Or combining the various types of documentation, and skipping over a basic need. There are five types of documentation. A real product must have all five types, and while they can have minimal overlap, all basic types should exist for nearly any software product.

Five Types of Writing

Before writing any of the documents below, stop and choose a writing style that will work through that entire
task. Changing style isn’t about formality or slang–it’s about the basic reason for writing. The basic writing styles are:

• Exposition: Writing to inform, to explain a process or an event or an object. Your main help file should be mostly expository writing.
• Persuasion: Writing to persuade. Frequently includes classical rhetorical techniques to bring the reader to your point of view. Applies to press releases and other sales-related documentation. Classical rhetoric is the most difficult writing style; use it with caution and a light touch.
• Descriptive: Writing to describe and define what a product looks like and how it behaves.
• Narrative: This writing is common in fiction, for telling about a sequence of events, but it can also apply to a wizard-style product interface.
• Creative: Novels, plays, poetry, stories. I’ve seen these used well in product documentation, but only once in a utility program. Needed in many games, but avoid them in most other products.

The majority of your product documentation should be exposition or descriptive writing, and your sales documents should be persuasion with a little rhetoric. Overlap them more than just a little, and your document will lose focus and effectiveness.

Five Types of Documents

Here too, try not to overlap the types of documents below.Breaking these into separate projects makes them easier to write, easier to understand, and more effective. (Or, for the software types among us: Less likely to result in a tech-support contact.)

Motivation

These are sales documents, your web site, press releases, your advertisements, promotional emails, logos, artwork. These include the sales pitch, the classic AIDA steps of Attention, Interest, Desire, and Action. In short:

• Attention: Something not routine. Something that stands out. Unique. Maybe bizarre, if your product isn’t a
  business application. Anything to get potential purchasers to look.
• Interest: These are the product descriptions, written as benefits, not a feature list. It’s about what the user can create, and not about the tools and instructions.
• Desire: Why they want it. Or will. This is where the “Ooooh-Ahhhh” goes. The excitement should be building.
• Action: Call for action, go for the closing, ask for the sale. Buy now!

There’s a reason that sales letters from the very largest product sales companies are four pages long–they’ve tested the letters, included every step for attention, interest, desire, and action, and they know it works. But that format is best on paper or television. Adapting a non-sequential web or software version will take more work. A video or demonstration may be a better approach to building the AIDA steps.

Instruction

Getting-Started Guides: These are the most-left-out documents in modern software, and the most likely to prevent a technical support call. These describe basic screen layout, functions, what always must be done first, and what the words on the screen mean in the context of just this product. Instructions are meant to be read by new users, not word-searched, and must be organized in a logical progression:

• What does the product do?
• What can my final project or result be?
• How do I get started?
• What’s the basic navigation through the program?
• What’s in every use of the program, or what steps are in every project?
• And finally: A description of where the rest of the help is, in the tutorials, demonstrations, and references.

This documentation should always be included in the product installation. It can be duplicated online for sales and Search Optimization purposes, but it’s so basic to using the product that it should always be included in the product in some form.

Tutorials

This is how to work through a series of introductory steps and learn the basic operations of a product. Tutorials are for new users. These may be slideshow format, or help files, or videos. These will frequently include building a project of some complexity, by starting small and working though many continuous steps to add options to the project. These are typically numbered, and build on each other to bring the user to a level of mastery, step-by-step.

There’s a trick to tutorials: keep every step strictly in the sequence that the user will take them on-screen. It’s “Go to the File menu and click on Print” and never “Click Print in the File menu.”

Tutorials can be included directly in the product, or online. Frequently, the best approach is to include basic tutorials on program layout and project steps within the help file or a ‘Getting Started’ popup, and include a link to bigger and newer tutorials online.

Demonstrations

These are step-by-step guides, frequently done as animated slideshows, for a single and specific product task. Demonstrations are for users already familiar with the basic operation of the product. These show how to do processes or projects, and leave out no steps. These can be used as needed, in isolation, and should not build on other demonstrations.

Demonstrations, like tutorials, can be within the program, or online, or split, with the advanced topics online. But tutorials are sequential and introductory, while demonstrations are standalone and project-based.

Reference

This is what programmers want. It’s the notes for the advanced features, the guide to doing complex items, and the ever-growing tips and tricks list. This works well in a Wiki format, or a searchable knowledge base. It’s not the material that most users of the product would memorize, or must know to use the most basic functions of the product.

Knowledge bases and Frequently-Asked-Question lists are mostly online. Basic FAQ topics should move into the
Instruction guide during revisions to the product. Advanced topics should usually remain in the knowledge base.

Hiring a Professional Writer

Can documentation be outsourced? Some can, but not all. If the programmers have started the reference documentation, and created a basic tutorial that a writer can follow (in any form, including a one-on-one lesson), then a writer can convert that tutorial into a form ready for a general audience, and start building the tutorials and possibly some of the basic demonstrations.

More mistakes:

Using marketing documentation as an instruction book. Selling is not teaching.

Using a feature list as a press release. Features don’t sell, and bullet lists don’t read well. Selling requires sentences that promote benefits. If your press release is made of lists, it’s not a news story, and won’t be published by any media companies.

Interviewing yourself for press releases or product sales. No, wait–are you Steve Jobs? This rule may not apply, then. Everyone else–don’t quote yourself in your press releases or on your web site.

Mixing tutorials with demonstrations: A guided tour is not a step-by-step procedure; combinations will become
large and overly complex. Again, tutorials are sequential, and demonstrations are for single tasks.

Using an online Knowledge Base or a Wiki as a help manual. These are for problem solving, and can’t replace an introductory set of lessons, which should include a tour, terminology, and getting started with some basic projects.

Consistency

Finally, use the same terminology everywhere. A folder is a folder, and not a directory. A picture is a picture, not an image. Both may be correct, but pick only one, and then stick with it.

It’s great to have a glossary that includes mentions of “This is also known as …”; that helps the search function of your help (or Google, for online help) to find entries when users look for help on topics that you don’t have listed in the menus or the help contents. But overall, be consistent-–this is more about clear communication, and normal writing rules that say not to overuse single words do not apply here.

Keep parallel sections of the documentation similar. Maybe they should all start with a definition, or a screen shot, or an image of a finished project. Pick one style, and stay with it.

Finally, read it all out loud. Well, everything except the reference materials, anyway. You’ll hear errors in your writing far more easily than if you see the words on-screen. And you’ll notice that sections of your text belong somewhere else, and that leads to better organization and betterproduct documentation.

Jerry Stern is the editor of ASPects, the ASP’s Coordinator of Anti-Spyware Operations, runs Startupware.com and WorPerfect.org, and www.sciencetranslations.com.

The post Documentation: From Programs to Products appeared first on Startupware.com. Visit to read more about software design, malware, and computer security.

Original article: Documentation: From Programs to Products.