:Tool Chest:Interfaces & Libraries:Interfaces:CIncludes:
:Tools & Applications:Interfaces:
ftp://ftpdev.info.apple.com//Developer_Services/Development_Kits/Interfaces_%26_Libraries/Interfaces/
They should also be available for download from Apple. You'll have to search Apple's developer site for the location, though. If you find the location for download, please let me know so I can list it here. Thanks.
You'll have to redo your "MacHeaders" or "MacHeaders++" files. You may also have to change some of the library files around. Personally, I recommend holding off until Metrowerks properly integrates the 3.x Universal Headers into Codewarrior, unless there's something you really need that isn't available in the 2.x headers.
The QCAPI is distributed as part of the commercial software
"QC",
produced by
If you don't have QC, just make sure you turn off 'kCompileWithExtraQC' in "MyConfiguration.h", and don't include the QCAPI library files in your projects.
Be sure to put the "InternetConfig" folder either in your compiler folder or add it to the paths accessed for System includes (those in <> brackets).
I've added the 'libmoto' PowerPC library to the CGI PPC and WSAPI PPC targets.
This library includes optimized versions of a number of common math and string
functions. It replaces the equivalent functions in 'MathLib' and 'MSL C.PPC.Lib'.
Additionally, when linking the CGI PPC target, the 'OTXTILib' used for
OpenTransport support contains 'errno' data just like 'MSL C.PPC.Lib'.
You can safely ignore these link warnings.
With the framework you can produce both CGIs and Plug-Ins from one set of source code. The framework also includes enhancements not included in the basic WebSTAR API.
Another reason for keeping with the framework is the growing set of utility functions included.
The intention is to continue to adapt the framework to new developments in Mac based internet serving as they emerge. So, by using the framework and you should have an easier time adapting to those changes. There will always be bumps to get over, but this way you're sharing the support of a lot of people using the same code set and making it easier for all of us to focus on the end product.
Many people use MacHTTP, NetPresenz and other servers that don't (yet) support WSAPI. There will also be some sites that don't upgrade their WebSTARs. So, if you distribute your software only as a plug-in, you'll be excluding a lot of sites who might otherwise use your CGI.
Another way to use CGIs is to distribute the CGI version of your CGI/plug-in as shareware, and provide the plug-in only to registered users.
Metrowerks modified their ANSI libraries in CW8. You now need to include
"console.stubs.c", unless you are using the SIOUX
interface, in which case you need the appropriate
"SIOUX.?.lib". These files are found in the
CodeWarrior folder in: "MacOS Support:Libraries:SIOUX:"
You need to substitute the new MSL (Metrowerks Standard Libraries) library files in place of the older ANSI libs.
You will have to add the MSL paths to the "Access Paths" preferences for the target preferences.
Do a global replace of some old Mac Toolbox function names in the Framework's
source files:
Original Replace With GetMHandle GetMenuHandleGetDItem GetDialogItemGetItem GetMenuItemTextAddResMenu AppendResMenu
Your test AppleScript has to point at the project file, and not the compiled application, if you want to use the Symantec debuggers to test the CGI event.
At the end of cgiAESearchDocProcess, there is the following:
if ( (*theCGIHdl)->suspended )
{
/* We're in a suspended AppleEvent, so we'll need to resume the
AppleEvent to have it complete and return the reply properly. */
theErr = AEResumeTheCurrentEvent ( &theAppleEvent,
&((*theCGIHdl)->replyEvent), vCGIAEResumeCompleteUPP, (long)theCGIHdl );
}
else
{
/* We weren't suspended, but still need to take care of the
AppleEvent reply record. */
theErr = cgiAEComplete ( theCGIHdl );
}
Both options result in the cgiAEComplete function being
called. However, if the AE was suspended, then the
AEResumeTheCurrentEvent call resumes it using the procedure
pointed to by the vCGIAEResumeCompleteUPP
UniversalProcedurePointer. So, when the
vCGIAEResumeCompleteUPP procedure returns, it's the same as
if a normal AppleEvent handler had returned. The result from that
procedure is what is returned for the AppleEvent result.
See the mailing list info.
To get specific instruction on the grantcgi mailing lists, send email
to the mailing list address with the message Subject set to the word:
help
Yes, you will have to recode (how much depends on what your original code looks like).
Mac CGIs are full-fledged Mac applications and require all the standard event handling that implies. In order to communicate with the web server, a Mac CGI must handle and respond to the CGI AppleEvent.
Grant's CGI Framework has all the AppleEvent handling already set up.
In version 1 of the framework, you just need to extract needed data from the fields in theCGIHdl structure, instead of from stdin. Memory must also be allocated to hold the CGI output (response data) which is then 'stored' in theCGIHdl so the framework can put it into the AppleEvent Reply that gets sent back to the web server.
Further development of version 1 has been discontinued.
Version 2 is currently expected to go final before December 1997.
I'm currently looking at how to integrate the PIXO ("Plug-In Cross-Over") API into the framework. Beyond that, I cannot say when it will be ready.
The MOS API is effectivly a dead technology. Its creators have completely dropped it now that the WebSTAR API can be used by anybody. It offers no advantages over W*API and was never really complete.