> What do I need to do to be able to mix socket based code with a
> MSL/PowerPlant application ?
As well as <arpa/inet.h>, <netdb.h> will give you trouble too. The code
below was of use during MSL->BSD conversion in my latest project. Got it to
compile without excessive whining and bitching, anyway.
> Should I remove all vestiges of MSL and use whatever standard library
> the machine comes with ?
I did eventually for said project and haven't had any reason to regret the
decision and several to consider it a good one. Mind you, it's not
PowerPlant based, which could very well throw some wrinkles in the works for
you.
Anyway, the code, from the header to my Winsock emulation routines.
"VS_TARGET_OS_MAC" is our cross-platform flag doing the same job as
TARGET_OS_MAC in Apple-headered code and can be ignored by you.
#include <sys/types.h>
#include <sys/time.h>
#include <sys/fcntl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include </usr/include/unistd.h>
#if VS_TARGET_OS_MAC && _MSL_USING_MW_C_HEADERS
/* not in <string.h> */
#define bzero(b,len) (memset((b), '\0', (len)), (void) 0)
/* MSL <climits> */
#undef CHAR_BIT
#undef MB_LEN_MAX
#undef SCHAR_MAX
#undef SCHAR_MIN
#undef UCHAR_MAX
#undef CHAR_MAX
#undef CHAR_MIN
#undef USHRT_MAX
#undef SHRT_MAX
#undef SHRT_MIN
#undef SHRT_MAX
#undef UINT_MAX
#undef INT_MAX
#undef INT_MIN
#undef ULONG_MAX
#undef LONG_MAX
#undef LONG_MIN
#undef LLONG_MIN
/* MSL <csignal> */
#undef SIGINT
#undef SIGILL
#undef SIGABRT
#undef SIGFPE
#undef SIGSEGV
#undef SIGTERM
#undef SIG_DFL
#undef SIG_IGN
#undef SIG_ERR
#endif /* VS_TARGET_OS_MAC && _MSL_USING_MW_C_HEADERS */
#include <netdb.h>
#include <arpa/inet.h>

Signature
Alex Curylo -- alex@alexcurylo.com -- http://www.alexcurylo.com/
"Wow you're quite the Casanova! We can tell you're a real woman-magnet and
are never without an admirer or three. When combined with your significant
charm, your attentive, sensitive demeanor makes you irresistible."
-- 'Are You a Suave Guy?', www.emode.com
Kent Sorensen - 25 Aug 2003 02:51 GMT
> > Should I remove all vestiges of MSL and use whatever standard library
> > the machine comes with ?
[quoted text clipped - 3 lines]
> PowerPlant based, which could very well throw some wrinkles in the works for
> you.
Thank you for the reply. I will look into applying the changes. However,
I think that abandoning MSL is the better approach. Can you tell me what
I need to do ?
The application will be OS X only.
It doesn't appear like CW's new project templates contain any samples
that uses the standard library.
Thanks
Kent
MW Ron - 25 Aug 2003 15:12 GMT
>> > Should I remove all vestiges of MSL and use whatever standard library
>> > the machine comes with ?
[quoted text clipped - 7 lines]
>I think that abandoning MSL is the better approach. Can you tell me what
>I need to do ?
Change the precompiled header so it doesn't use MSL Headers. I forget
the exact which one but you'll find where it is defined if you check on
it.
>The application will be OS X only.
>
>It doesn't appear like CW's new project templates contain any samples
>that uses the standard library.
MSL is the Standard Library, but you probably mean the BSD lib and it's
POSIX functions.
Anyway it is simple to do, change the access path order and change the
define in one of PowerPlants prefix files.
What I'd do is create a copy of that header with the change and create
your own precompiled header source (.pch++) file so it doesn't bite you
later.
If you need detailed information or the exact header and line to change
let me know and I'll dig it all up.
Ron

Signature
CodeWarrior Development Studio for Macintosh v9
Enhance Your Productivity and Shorten your Development Cycles
<http://store.metrowerks.com/>
Sales and Support 512-996-5300 800-377-5416
Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com
Kent Sorensen - 26 Aug 2003 15:11 GMT
> Change the precompiled header so it doesn't use MSL Headers. I forget
> the exact which one but you'll find where it is defined if you check on
> it.
<snip>
> If you need detailed information or the exact header and line to change
> let me know and I'll dig it all up.
Thanks for the reply. I tried doing this and there is a few problems
since this is a PowerPlant application.
The first one is the #include <exception> in LException.h and the second
one is #include <cstddef> from LString.h
There's also some issues with debugnew which is getting included
somehow. Of course that will have to go.
Kent
MW Ron - 26 Aug 2003 16:40 GMT
>> Change the precompiled header so it doesn't use MSL Headers. I forget
>> the exact which one but you'll find where it is defined if you check on
[quoted text clipped - 8 lines]
>The first one is the #include <exception> in LException.h and the second
>one is #include <cstddef> from LString.h
those are C++ headers and you only want to use the C headers and
libraries.
>There's also some issues with debugnew which is getting included
>somehow. Of course that will have to go.
Again that is C++ and nothing to do with C lib. But you don't need to
use that.
Ron

Signature
CodeWarrior Development Studio for Macintosh v9
Enhance Your Productivity and Shorten your Development Cycles
<http://store.metrowerks.com/>
Sales and Support 512-996-5300 800-377-5416
Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com
Alex Curylo - 25 Aug 2003 15:43 GMT
> Thank you for the reply. I will look into applying the changes. However,
> I think that abandoning MSL is the better approach. Can you tell me what
> I need to do ?
1) Get rid of all the MSL access paths and replace them with system access
paths, and turn on 'Require Framework Includes'. My System Paths in Access
Paths pane then looks like
( ) {OS XVolume}usr/include
( ) {OS XVolume}usr/lib
(f) {OS XVolume}System/Library/Frameworks
(r) {Compiler}MacOS X Support
where ( ) is not recursive, (r) is recursive, and (f) is that little
frameworks script f. (Yes, this is Mach-o, I figure if you're doing a CFM
project you probably want OS 9 compatibility, and that means you're going to
use MSL, right?)
2) Lose all the MSL libraries and replace them with
usr/lib/crt1.o
MacOS X Support/Libraries/Runtime/Libs/MSL_Runtime_Mach-O_D.a
3) That's pretty much it far as I remember. Here's the debug target .pch++,
the portions relevant to stdlib usage anyway, I believe most of these
defines are irrelevant now that MSL headers are rooted out completely but
they'll probably help you during the conversion process. The various pragmas
are just there because I like them on, I don't think they have any
particular affect on the BSD v. MSL question.
#pragma precompile_target "MacSIPClientBSDDebug++"
#define TARGET_API_MAC_CARBON 1
#define DEBUG 1
// see <CarbonCore/Debugging.h>
#define kComponentSignatureString "MacSIPClient"
#define DEBUG_ASSERT_COMPONENT_NAME_STRING "MacSIPClient"
#define COMPONENT_SIGNATURE '????'
#pragma once on
#define __dest_os __mac_os_x
#define MSL_USE_PRECOMPILED_HEADERS 0
#define _MSL_USING_MW_C_HEADERS 0
#define _MSL_MACHEADERS_INCLUDES_CMATH 0
// notes about <cmath> vs <fp.h> in here -- we're not using MSL C
//#include "MacHeadersMach-O.c"
#define __NOEXTENSIONS__
#define __CF_USE_FRAMEWORK_INCLUDES__
//#include <ansi_prefix.mach.h>
#include <Carbon/Carbon.h>
#pragma check_header_flags on
#pragma warn_no_side_effect on
#pragma warn_padding on
No guarantees of correctness made for these instructions past that they
apparently produce a functioning program for me, if anybody has any
corrections to make they probably know more than I do.

Signature
Alex Curylo -- alex@alexcurylo.com -- http://www.alexcurylo.com/
"As good a writer as Kevin is, he is only human. I think that for
an effective "three strikes and you're out" policy on this list,
we should let Alex deal with the third-time offenders..."
-- John Wiseman