Feb 96 Factory Floor
| Volume Number: | | 12
|
| Issue Number: | | 2
|
| Column Tag: | | From The Factory Floor
|
From the Factory Floor 
A monthly column of assorted news, interviews, and technical information from Metrowerks.
By Dave Mark
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
In last month’s issue, we introduced a brand new column with little in the way of explanation. Here’s the skinny. At Neil’s persistent urging, the folks at Metrowerks asked me to put together a regular monthly column, but with no particular agenda. For example, last month’s column was a Java interview with Greg Galanos, Metrowerks’ President and CEO. This month, we’ll go through a pile of Metrowerks tech support questions and answers. Got any ideas? Any interviews you’d like to see? As always, your feedback is most welcome. Check out page 2 of the magazine for contact information.
The questions were provided by Stephen Chong, Khurram Quereshi, and the folks at Metrowerks tech support. I did a little bit of editing just to clean up the questions but I tried to keep with the spirit of the original question. Since not everyone wants their name up in lights, I didn’t include names with the questions.
Top Ten Tech Support Questions
Q: My program makes extensive use of SIOUX for console i/o, and I frequently generate more than 32K worth of output in the console window. I’ve noticed that when I scroll down to the bottom of my console window, I occasionally end up with garbage in the window and sometimes the window stops scrolling. Any ideas?
A: Our SIOUX output window can only handle 32k of output at a time, and after you send it more than that, results are unpredictable. The solution is to either redirect stdout to a file (via the ccommand() function/dialog in console.h) or change the printfs to fprintfs and write to a file.
Q: How can I use the debugger for debugging MPW tools and how can I specify command-line arguments when I am debugging?
A: Currently, our debugger doesn’t support debugging MPW tools. One option is to build your tool as an application that uses the ccommand() function to take its command-line arguments and I/O redirection. Once it is debugged, you would change the project type back to MPW tool, swap ANSI libraries, and remove the ccommand call. Another option is to purchase Steve Jasik’s The Debugger, which can debug 68K MPW tools, and possibly PPC ones.
Q: In the following code snippet, the scope of the variable i inside the for-loop doesn’t conform to the ARM when I compile using the CodeWarrior C++ compiler. Why is that?
void scopeOfVars()
{
long a = 0;
if (a)
for (long i = 0; i < 12; ++i)
a = i;
else
for (long i = 0; i < 12; ++i)
a = i + 1;
}
A: The scope of the index is just within the for-loop; this agrees with the draft ANSI Standard for C++ which is what CodeWarrior follows. If you instead want to force ARM conformance, which allows the index to live outside the for-loop, you can do this by checking the ARM Conformance checkbox in the C/C++ Language Preferences panel.
Q: I have two source code files I am linking together. One is written in C and one in Pascal. Here’s the Pascal source code, from source file Foo.p:
unit Foo;
interface
var
myGlobalVariable : Integer;
implementation
end.
Here’s the C source code:
extern short myGlobalVariable;
void main(void)
{
myGlobalVariable++;
}
When I compile and link these files using CodeWarrior I get a linker error complaining that myGlobalVariable referenced from main is undefined. What gives?
A: You will need to do either (but not both) of the following to make your code link:
• In the Pascal source, enclose the variable declaration with the compiler directive {$J+} and {$J-}. The $J directive controls the case conversion of global identifiers when building object files.
or
• Use all uppercase in the variable name in your C source code.
Q: I just upgraded to CW7 and I’m having problems getting a CW6 Pascal 68K project to link under CW7. When I recompile my code, I got the following linker errors:
Link Error : StrOp.c 'memchr' referenced
from '__POSITION__' is undefined.
Link Error : MWP.Stub.lib: '%_X2STR' referenced
from 'NUM2STR' is undefined.
Link Error : MWP.Stub.lib: 'STR2DEC' referenced
from 'STR2NUM' is undefined.
A: Under CW7, the IDE is now integrated, allowing Pascal and C to use the same set of ANSI C libraries. You’ll need to make sure these libraries have been added to your project. To find out all the libraries needed for a typical 68k project in CW7, you might want to create a new project using the MacOS 68k Pascal.µ project stationery, then compare your new project to your old project.
Q: In CW6, I used the libraries P/ANS.68K.lib and SetLib.Lib (A5). What are the CW7 equivalents?
A: Neither of these libraries are needed under CW7.
Q: I have a simple ANSI C console-based program I wrote on the Mac and that I am trying to get working under Windows ’95. The program works just fine under MacOS but I can’t get it to build using the Win32/x86 environment. I am using the Win32s libraries as used in the CW7 Win32/x86 tutorial but I can’t get my project to link sucessfully.
A: Inside the (Project Stationery) folder is a folder called Additional Project Stationery. Drag the Win32 Console application stationery from there into the (Project Stationery) folder. Next, create a new project using the Win32 Console app stationery. The binary created from there should run without problems under Windows95. I just tried it with Hello World and it ran fine on my Win95 machine.
Q: Is there a way to “Import” the template I made in version 1 of Constructor into version 2 of Constructor?
A: Unfortunately, Constructor 1 and 2 are completely different programs (literally), and they use a different mechanism for custom types. Right now it isn’t possible to import 1.0.1 templates into 2.0.
Q: How can I get a SIOUX-based program to quit without pausing when the program ends or without waiting for the user to select Quit from the File menu?
A: Try this: #include the file <SIOUX.h>, then add the following code at the beginning of main():
SIOUXSettings.autocloseonquit = true;
SIOUXSettings.asktosaveonclose = false;
Q: I’m trying to debug a code resource. However, after I set a breakpoint at the beginning of the resource and then run the application that calls this resource, I never drop into the debugger. What’s happening?
A: Under CW7, you can debug only 68K code resources. Debugging PPC code resources will be available in CW8 (contact tech support to request a beta). If you are debugging a code resource under CW7, carefully follow the instructions in the Debugger manual on debugging code resources. Here is the basic procedure:
After creating the .SYM file for the code resource, change its name (to anything). Double-click on it, and then (since the name no longer corresponds to any executable), the debugger will ask you for the name of the executable to look at. Give it the name of the executable you’ve created that contains this resource. You can now set breakpoints. Next, leaving the .SYM window open, double-click on the application itself and control should be transferred to the Debugger. Let us know if this sequence of steps doesn’t work. (In that case it might be necessary for us to look at a copy of the project in order to diagnose the problem.)
