NetLib for StormC

[tygre]

Hi all!

So, Tumo and I made great progress in compiling AmiModRadio with StormC, hopefully to use its debugger and debug crashes on Honx's and Tumo's configs...

Now, one last step: linking AmiModRadio with AmiTCP net.lib... The problem here is that AmiTCP provides a version of net.lib for SAS/C and it seems difficult for me to compile its source with StormC...

Has anyone a version of net.lib for StormC? I guess that I am not the first one to want sockets in StormC

Thanks in advance!

[patrik]

Unless you have a need for the extra functions available in net.lib, you should be fine by just opening bsdsocket.library and including <proto/socket.h> and at least <sys/socket.h>.

[tygre]

Hi Patrik!

Thanks for your help! This is what I did, I included:

clib/socket_protos.h
sys/socket.h

and my code compiles fine but at linking time, functions like

connect
recv
...

are missing...

Am I doing something wrong?

Thanks!

[tygre]

PS. Replacing clib/socket_proto.h by proto/socket.h makes no difference: still some functions are missing at linking time

[patrik]

Sorry, I should not have "helped" as I have no experience with StormC. However, I have used bsdsocket.library both with SAS/C and VBCC for more than ten years without linking with net.lib, using the method above, which should work as it is a library like any other.

[tygre]

Yes, indeed, my code compiles fine with VBCC... I have as libraries:

• amiga
• miami
• posix

so, I am thinking that I would need the equivalent of miami (net.lib?) in StormC too... Against which libs do you link your code?

Thanks!

[patrik]

Take everything below with a grain of salt as I might have missed several aspects/details.

Normally with vbcc I don't link with any specific link libraries unless I need some function or data from them. The only thing vbcc links with automatically then is vc.lib.

Say if I wanted to use NewList() from amiga.lib, then I would link it, but otherwise not.

This is when using <proto/xyz.h> though, which I have understood defines the library functions in such way that the compiler will put the arguments for the library function in the correct registers as specified in the autodoc and call the function directly, which is the most efficient way to do it. How to do it is compiler specific (vbcc for example has a proto directory supplied with such files for all amigaos libraries for example).

If you use clib/proto_xyz.h>, the library functions will be defined as normal C functions where the arguments normally are passed on the stack, which requires some stub/wrapper code to do the actual library function call with registers correctly populated. These stubs/wrappers are as far as I know supplied in link libraries. I think amiga.lib for example contains all such stubs /wrappers for the amigaos library functions. I would assume net.lib also got the stubs/wrappers for bsdsocket.library apart from the actual functions it itself contains.

Btw, I have been using the Roadshow SDK for bsdsocket.library code for quite a while and it doesn't even include a net.lib, so I guess it assumes you would want to use <proto/socket.h>.

[tygre]

Hi Patrik!

Originally Posted by patrik

Take everything below with a grain of salt as I might have missed several aspects/details.

Thanks!

Originally Posted by patrik

Normally with vbcc I don't link with any specific link libraries unless I need some function or data from them. The only thing vbcc links with automatically then is vc.lib.

Say if I wanted to use NewList() from amiga.lib, then I would link it, but otherwise not.

This is when using <proto/xyz.h> though, which I have understood defines the library functions in such way that the compiler will put the arguments for the library function in the correct registers as specified in the autodoc and call the function directly, which is the most efficient way to do it. How to do it is compiler specific (vbcc for example has a proto directory supplied with such files for all amigaos libraries for example).

Thank you for your explanations! It makes sense and I finally understand the difference between "normal" includes and "proto"s!

Originally Posted by patrik

If you use clib/proto_xyz.h>, the library functions will be defined as normal C functions where the arguments normally are passed on the stack, which requires some stub/wrapper code to do the actual library function call with registers correctly populated. These stubs/wrappers are as far as I know supplied in link libraries. I think amiga.lib for example contains all such stubs /wrappers for the amigaos library functions. I would assume net.lib also got the stubs/wrappers for bsdsocket.library apart from the actual functions it itself contains.

However, even when replacing clib/... with proto/..., StormC still asks for the functions... Here is what I have in one of my file:

#include <stdio.h>
#include <stdlib.h>
#include <dos/dos.h> // For RETURN_OK, RETURN_ERROR
#include <sys/types.h> // For u_short
#include <proto/exec.h> // For OpenLibrary() and CloseLibrary()
#include <netdb.h> // Sockets and such
#include <proto/socket.h> // Sockets and such
#include <sys/socket.h> // Sockets and such

What am I missing? Again, with VBCC, it compiles fine... only with StormC... I must be overlooking something...

Originally Posted by patrik

Btw, I have been using the Roadshow SDK for bsdsocket.library code for quite a while and it doesn't even include a net.lib, so I guess it assumes you would want to use <proto/socket.h>.

Yes, that would make sense totally but then StormC still complains

Cheers!

[Minuous]

You don't need net.lib for send(), recv(), etc.

You might want to look at the source code for the Report+ application (http://amigan.1emu.net/releases/ReportPlus.lha); it is written for StormC and has full source included.

[patrik]

Originally Posted by tygre

What am I missing? Again, with VBCC, it compiles fine... only with StormC... I must be overlooking something...

Maybe StormC has no specific proto/socket.h and defaults to the clib/proto_socket.h file. I see that vbcc has an included proto/socket.h, which will override the proto of the badsocket.library SDK. This is correct as I cannot imagine that the old AmiTCP/Miami SDK:s had VBCC style proto support. The Roadshow SDK on the other hand is more recent and has vbcc support in its proto.

Which bsdsocket.library SDK are you using?

[tygre]

Originally Posted by Minuous

You don't need net.lib for send(), recv(), etc.

You might want to look at the source code for the Report+ application (http://amigan.1emu.net/releases/ReportPlus.lha); it is written for StormC and has full source included.

Thank you Minuous but I don't seem to find code related to sockets in Report+, am I looking not straight?

Cheers!

[tygre]

Originally Posted by patrik

Maybe StormC has no specific proto/socket.h and defaults to the clib/proto_socket.h file. I see that vbcc has an included proto/socket.h, which will override the proto of the badsocket.library SDK. This is correct as I cannot imagine that the old AmiTCP/Miami SDK:s had VBCC style proto support. The Roadshow SDK on the other hand is more recent and has vbcc support in its proto.

Which bsdsocket.library SDK are you using?

Yes, that would make sense... maybe I should use Roadshow SDK... Right now, I am using AmiTCP-SDK-4.3, could that be the cause of my troubles?

Cheers!

[Minuous]

Originally Posted by tygre

Thank you Minuous but I don't seem to find code related to sockets in Report+, am I looking not straight?

There is code for composing and sending emails in f1.c, and for downloading files from a web server in rp.c.

[patrik]

Originally Posted by tygre

Yes, that would make sense... maybe I should use Roadshow SDK... Right now, I am using AmiTCP-SDK-4.3, could that be the cause of my troubles?

Cheers!

If the problem is that your current SDK doesn't have support for StormC3 in its protos and StormC itself doesn't include overriding protos for bsdsocket.library, then changing SDK will only help if the new SDK has support for StormC3 in its protos.

It is also possible to generate missing protos for more or less any compiler from .fd files which should be included in the SDK. I don't know what tool to use for StormC, but with vbcc you use the included fd2pragma for example. Should be a chapter about this in the StormC3 manual.

[tygre]

Hi Minuous and Patrik!

Originally Posted by patrik

If the problem is that your current SDK doesn't have support for StormC3 in its protos and StormC itself doesn't include overriding protos for bsdsocket.library, then changing SDK will only help if the new SDK has support for StormC3 in its protos.

It is also possible to generate missing protos for more or less any compiler from .fd files which should be included in the SDK. I don't know what tool to use for StormC, but with vbcc you use the included fd2pragma for example. Should be a chapter about this in the StormC3 manual.

Thank you for the code and advices! I will try to compile the code and see what happens: if it can compile, I will know that something is wrong with my code... if it doesn't, then I will know that something is wrong with my install of StormC

I'll keep you posted!

Cheers!

[tygre]

Originally Posted by Minuous

There is code for composing and sending emails in f1.c, and for downloading files from a web server in rp.c.

Hi Minuous!

Was ReportPlus written with StormC 4? I tried to load its project file (.¶) in StormC 3 and it complains that the file is "not a project file"?

Cheers!

[Minuous]

Yes, it was written with StormC 4, but it uses the StormC 3 compiler.

[tygre]

Hi Minuous!

I looked at the code and I think that I understand why ReportPlus compiles with StormC 3: it "defines" the libcalls in the C files. For example, at the beginning of f1.c, there is:

struct hostent* gethostbyname(const UBYTE* name);
	LONG recv(LONG s, UBYTE* buf, LONG len, LONG flags); /* V3 */
	LONG closesocket(LONG d);
	LONG connect(LONG s, const struct sockaddr* name, LONG namelen);
	LONG send(LONG s, const UBYTE* msg, LONG len, LONG flags);
	LONG socket(LONG domain, LONG type, LONG protocol);
	LONG shutdown(LONG s, LONG how);

	#pragma libcall SocketBase gethostbyname D2 801
	#pragma libcall SocketBase recv 4E 218004
	#pragma libcall SocketBase closesocket 78 001
	#pragma libcall SocketBase connect 36 18003
	#pragma libcall SocketBase send 42 218004
	#pragma libcall SocketBase socket 1E 21003
	#pragma libcall SocketBase shutdown 54 1002

which allows compiling the code Now, I can sure do the same thing in my code (caveat: find the proper arguments for other functions that I use, like inet_addr()) but is it "clean" to do that?

Cheers!

[Minuous]

I don't recall the exact reason why I did it that way. It's generally considered better to use include files. Presumably there was some issue with the include file/compiler/linker etc. that made this the easiest way. Either way, of course, the resulting executable will be the same.