In recent years Microsoft has tried to shed its image as producing "insecure" operating systems. Virii and trojans can be attached to many different file types and attack your computer in various ways, but the rise of the Internet has provided many new methods, so Microsoft has made quite a few changes in this area. But as you might expect, part of the process of making Windows "more secure by default" also breaks some existing systems and software. One example of this is the Microsoft Help system.

A number of years ago Microsoft changed the format of the standard "Help File" from the .HLP format to the newer .CHM format, where CHM is short for "Compiled HTML". Being a form of HTML, each of the "pages" in a CHM help file are displayed using Microsoft's Internet Explorer software, just in a special way so it doesn't look like that's how it's being done. Microsoft no doubt felt there were lots of good reasons for them to now do things this way, but one of the (hopefully) unforseen problems was that all the "security risks" that come with browsing the web could now also be applied to .CHM files. That is to say, while it is not very likely, somebody could craft a special .CHM file that could do damage or pose a security risk to your computer, and all they'd need to do is get you to download the file and view it.

So, sometime after the .CHM file format was in general use, Microsoft tightened up the security in Internet Explorer, but because the new Help Viewer application uses IE to do its displays, changes to IE affected how the Help Viewer functioned. It was now possible that you would try to view a help entry in your software and rather than seeing the text you were supposed to see, you'd see some sort of security message or other error instead, basically telling you that the help file was not properly accessible. Because ManuSoft is typically installed on your server and not on your actual PC it is more likely that you'll see an error message accessing our help files because Windows will decide (incorrectly in this case) that a file on your server is somehow inherently more insecure than a file on your local hard drive. And that's just one possible scenario where things go wrong.

So, if you're having trouble viewing the online help in ManuSoft, what can you do? Below are a few steps to try:

1. The file could be "blocked" because you downloaded it from the internet. Locate the .CHM file on your hard drive, right click it and select Properties. At the bottom of the dialog there may be an option to "Unblock" the file. If so, select it then try reading help again. Note that ManuSoft has 3 help files, named Manual.chm, Tutorials.chm and Seminars.chm and you may need to check all three.
2. Download the "Fixhelp" registry file from the Miscellanous Files section of the ManuSoft Support Web Site, extract the file, then double-click it to merge it with your System Registry. Try opening the help again. This fix works by adjusting the "zones" from which the HTML Help application will allow content to be displayed. See http://support.microsoft.com/kb/892675 for more information (specifically Example 2, and in this case we raise the MaxAllowedZone to 1.) 
3. Another possibility is that the PC has somehow got confused about what is part of the “INTRAnet”, and what is part of the “INTERnet”. If it thinks your local server is part of the “INTERnet”, then it places higher security on it, and that can stop Help (and other things) from working. For example, this typically means that every time you launch ManuSoft you also get a warning confirmation prompt before the program is actually started. To check for this, open a Widows Explorer Menu and select a network drive like M: or N:. Down in the bottom-right hand corner it will say either “Internet” or “Local Intranet”. (If you’re not getting a bottom status bar at all, click on the “View” menu, then select “Status bar” to tick it.) Seeing “Local intranet” is good, seeing “Internet” is bad. If it says “Internet” we need to go into "Control Panel", then "Internet Options", then go to the "Security" tab. Select “Local intranet” from the list of “zones”. This zone should already be set to “Medium-low” security, but click on “Default level” if it is not. Then click on the “Sites” button to get a further dialog box. Computers that are having a problem typically have the “Automatically detect intranet network” option ticked. Untick that option and leave the other three ticked. Click OK then OK again to close everything. If you reopen a Windows Explorer display and check a network drive again, you should see that zone has changed. And hopefully now Help will function correctly too.
4. A final posibilitiy is that the folder and/or file security on the server is set in such a way that the user has insufficient permissions to view the files. Checking and correcting these permissions can be a complicated process and describing it all is beyond the scope of this entry, so I recommend you contact your network/server support person to check these settings.

Naturally, if you are still having problems with your help files after all the above then you should contact ManuSoft Support for further help.

ManuSoft version 6.0 was our first version of ManuSoft for Windows and was written for Windows 95 specifically. We never did a version for Windows 3.11 or earlier. As such, ManuSoft 6.x has always been a 32-bit Windows program, written in pure Microsoft Visual C++.

Through Windows 95, Windows 98, Windows 2000, Windows ME, Windows XP and now Windows Vista, ManuSoft has remained a 32-bit program, and this is fine as it's what the vast majority of users out there are using. But just recently we're starting to see a few "64-bit Windows" users out there. These are people running "Windows XP 64-Bit Edition" or "Windows Vista 64-Bit Edition", sometimes also referred to as "x64" versions of Windows.

There is some software out there where special "x64" versions are produced, specifically for running on these versions of Windows. Microsoft has versions of their Microsoft Exchange Server and Microsoft SQL Server products that are designed for 64-bit computers, and Adobe has released 64-bit versions of some of their photo and video editing software. Programs that use a lot of RAM or do computationally intensive operations typically perform better as 64-bit software, but for the vast majority of programs there is little to no benefit in converting to 64-bit. You will not find a 64-bit edition of Microsoft Word, or even Microsoft Excel.

Similarly, we have no plans to produce a 64-bit edition of ManuSoft. There is simply no benefit for the user in us doing so. It would not make ManuSoft run any faster, or be any more efficient. 

So what happens when you run 32-bit software on your 64-bit edition of Windows? The answer is that the 32-bit program is run in a special way, launched through a process called WOW64 or "Windows on Windows64". WOW64 essentially provides an emulated 32-bit environment so that the older software thinks it is still running on a 32-bit machine. Any time the software tries to talk to the 64-bit operating system the WOW64 process steps in and provides a translation service so things continue to run smoothly.

 (Incidentally, a very similar thing was done back when Windows 95 was first released. Windows 3.x was a 16-bit operating system, whereas Windows 95 was 32-bit. In order for all the older 16-bit software to continue functioning, Microsoft provided a service called WOW32, which performed in exactly the same way.)

All this happens silently and seamlessly. You'll have absolutely no idea that the WOW64 process is being used while you are running ManuSoft.

There is one small discrepancy that you must be aware of though. Because ManuSoft is 32-bit, it will only talk to 32-bit ODBC drivers. This is fine as the 32-bit ODBC drivers continue to function on 64-bit Windows. But if you go into the "ODBC Administrator" on a 64-bit edition of Windows (found by going into "Control Panel", then "Administrative Tools", then double-clicking "Data Sources (ODBC)"), then what you have in fact started is the "64-Bit ODBC Administrator".  You'll find the ManuSoftDAT and ManuSoftDBF User DSNs are listed, but if you try to configure them you'll get error messages about "The setup routines... could not be found."

Instead, you need to run the "32-Bit ODBC Administrator", which you can do by clicking "Start", then "Run", then entering "%WinDir%\SysWOW64\odbcad32.exe" as the program you wish to open. This will launch an almost identical looking program, but this time you will be able to successfully click on the "Configure" button and modify the ManuSoftDAT and ManuSoftDBF entries (should you need to.)

MDBC Reports are a powerful part of the ManuSoft System. They allow users to view Crystal Reports based on your ManuSoft data even if they don't have the full Crystal Reports product installed. We have many sample reports on our Support Web Site, and also run training sessions on creating Crystal Reports.

The MDBC Reports menu allows for up to 100 reports to be defined in the system. For each report you do several things: give it a name, enter the path to the report, and if any .DAT files are being used they all have to be ticked so that the program knows to copy the files into your User folder, so that the report is run using the latest data. After a while, this last part in particular can be hard to keep control of, and it's particularly tedious to change all these settings if, as part of your v6.4 or v6.5 upgrade, you change many of your reports from using the .DAT files to the .DBF files (and so they no longer need to be ticked.)

Enter another Excel Spread Sheet to the rescue! The MDBCReptSetup.xls spread sheet (you'll find it in the Miscellaneous Files section of the Support Web Site) allows you to quickly and easily see and change all the settings related to your MDBC Reports Set Up. Simply open the spread sheet (making sure you allow Macros to be enabled), click the "Load Settings" button and enter the path to your WORK.DAT file  (usually "N:\", though you may wish to initially start by working on your "C:\ManuPlay\" folder.) The spread sheet will be filled with all the entries in your MDBC Reports menu. The initial columns are fairly self explanatory, simply following the fields in the setup dialog of the MDBC Reports program. The columns with the titles rotated 90 degrees correspond to all the check boxes for the .DAT files. There are a handful which have titles in curly braces (e.g. {Unused}); these columns should be ignored and left blank. For the other columns, enter either a "1" where you do want the file to be copied down (equivalent to ticking the entry), or a "0" or blank where you do NOT want the file copied down (equivalent to leaving the option unticked.)

Once you've made the changes you need, simply click the "Save Changes" button to write the new settings back to your WORK.DAT file. Like most of these "outside the system hacks" that I've talked about, only rudimentary error checking is made of the values you enter, so take care with any changes you make, and if in doubt, make the changes inside the system itself using the standard menu. (You did make a back up of your WORK.DAT file first, didn't you?)

All the current versions of ManuSoft contain a powerful feature called the Report Generator. This routine lets you create custom reports on your data, so you can extract the information you need quickly. In today's blog post I'm going to give an example of what you can do with the Report Generator. In the example I use version 6.4 of ManuSoft. I'd also recommend trying this in a play system first, if you're new to the report generator.

The scenario: you have a particular raw material and you want to find all manufactured parts which include this raw material in its bill of materials.

If you only want to search for one material you can just select the standard report format, then click printout. In the search criteria form that pops up search for "Material" equal to and enter a stock code. The generated report should list a part code and a description on each line, corresponding to a part which uses the material code you searched for. The image below is an example of the search I mean.

Now that report is reasonably useful, but we probably want to see some details about the material being used, for example the quantity. To do so we will need to create a new report format of our own. 

To start off, open the report generator menu and select the part file. Then choose the standard report format from the drop down menu. Once the standard report is selected and appears on the screen, click the build/copy button to the right of the format selector. Give the new report a name and click ok. The image below shows this.

Now to show some details about the material we need to add a reference to the material file in our report. To do so click the "Secondary" button in the bottom left of the screen. The display in the Format Layout should now show two rows of headings. The first is from the standard report and the data under these will come from the Part file as usual. The second row is for the Material file, and allows you to select the information you wish to show about the material items. Add the following columns in this order: "Stock Code", "Units", "Price ($/U)", Quantity. If you did this correctly your report format should look like the following screen shot.

Before we print the report, click on the Primary button (in fact you have to as the print button will be "greyed out" while you edit the secondary columns). Select the material details column on the primary file and delete it. The reason for doing this is that we already have too much data and the font on the generated report will be far too small if this is the case.

Now we're ready to print. Click printout and use the same selection criteria as before. The new report should show details about how much material each part actually requires, and the associated cost per unit.

Another useful feature of this report is that if you do a wildcard search (say for all materials beginning with a specific prefix) then you can see all uses of a related set of materials quite easily, as per the sample report output seen in the image below.

Long time ManuSoft users will probably already know that NULLs in your ManuSoft data files are a problem, but you probably don't know exactly what they are and why they are problem or how they get there. This entry is a quick discussion on the topic of NULLs.

So, firstly why "NULL" in all capitals? This is because we are referring to a particular 'control code' as defined by the ASCII character set. All modern PCs use the ASCII character set which defines how all the letters, number and symbols on your keyboard are stored as numbers in memory, as well as defining a number of non-displaying characters, like "CR" (Carriage Return), "LF" (Line Feed) and also one called "NULL". These non-displaying 'control codes' take up the first 32 positions in the ASCII table, numbered from 0 to 31, and NULL takes position 0.

ManuSoft has always attempted to avoid all control codes in its data files, for several reasons, but avoiding the NULL character is particularly important because in the C/C++ programming language that ManuSoft is written in the NULL character has a special meaning; it marks the end of a string of characters. So, say ManuSoft wants to read some information, like the standard wording for a Purchase Order, from your WORK.DAT file. In the C++ code we open the WORK.DAT file, position the read pointer at the particular location where that standard wording is saved, and issue a command to read in a block of 600 characters (the maximum length of the standard wording text.) If, for whatever reason, there was a NULL character at the 200 character mark then only the first 200 characters would actually be read by the C++ file sub-system. All the text you had typed in to positions 201 through 600 would be ignored and would not get printed.

Now that example is not particularly dramatic, but when you start considering other possibilities, like a NULL in the middle of a stock record, so that the stock code and description read and update just fine, but the quantity in stock seems to never change, and you can see what sorts of problems can appear. Sometimes quite inexplicable behaviour can be traced back to a NULL in an odd spot.

So how do NULLs appear in your files? ManuSoft obviously tries to avoid creating them itself wherever possible, but some further facts about the behaviour of C/C++ and Windows makes them crop up from time to time. Firstly, there's the problem of buffers. When ManuSoft wants to create a brand new stock record, for example, we initialize a 1024 character "buffer" in memory. We would then normally fill that buffer with exactly 1024 characters before writing the contents to the end of the file. But if for some reason the buffer was only filled with 500 characters then position 501 would contain a NULL (to mark the end of the string), and that NULL could then be written to the file along with the rest of the buffer.

A second main cause is a file being expanded when it is written to. If a file is 50,000 bytes long and a C/C++ program asks Windows to write some characters to the file at position 55,000, then characters 50,001 to 54,999 in the file will end up being NULLs.

And then there are just the regular glitches that can happen on any computer network given enough traffic and enough time. Because the NULL character is the "default" for unallocated memory, etc. if anything goes wrong with any transferring of information inside a computer or around a network then there's a good chance a NULL could end up in the data somewhere.

I said earlier that ManuSoft has always tried to avoid control characters in its data files, but over time we've had to compromise our position on this. The first was when we made the ManuSoft .DAT files compatible with ODBC access, back in Version 6.1. To allow the Microsoft ODBC Text Driver to read our .DAT files we had to insert the control characters "CR" and "LF" at the end of every record in the database, as this is the Microsoft DOS/Windows standard for marking the "end of a line". The next big change was when we converted to using the .DBF file format in Version 6.4 of ManuSoft. The .DBF file format defines a "header" that must appear at the start of every file, before the actual data. This header information includes many NULLs and other control codes. But despite these changes over the years the actual data itself inside our data files continues to exclude all control characters.

Because NULLs in particular are a problem in our data files we created a utility called "FixNULLs" which you can use to clean up your data files, changing all NULL characters to the harmless "space" character instead. This utility used to be a very ordinary looking "DOS mode" program which you had to run at the command prompt. After changing to the .DBF file format this utility has been updated to have a Windows interface and to be a lot more user friendly. You can queue up a number of files to all be checked (by browsing for them, or by drag-and-dropping the files from Windows Explorer) and when run the program gives more feedback and will automatically skip "safe" NULL characters in the the header section of any .DBF files.

The FixNULLs program can be downloaded from the Miscellaneous Files section of the support web site. It would be very hard for you to do any unwitting damage to your data files using this utility, but we would generally recommend you only use it after consulting with ManuSoft Support personnel.