Re: [mobius-development] Yet more questions...sorry :)

[Tim R. <tim...@pr...>]

On 10 Dec 2002 at 18:13, Francis David Rounds wrote:
> 1) Welcome back Tim! I saw your post on alt.os.development, and all I
> can say is...you lucky bugger! :) (For those who don't know what I'm
> on about, a certain someone just managed to get the all-elusive
> broadband).  So does this mean we'll see more Mobius hd images
> uploaded so those who can't get the source to compile can still try it
> out? ;)

Sure :). But I don't want to start releasing images that only half work. I can certainly 
release a new hard disk image after adding and testing a new feature.

> 2) Well, I've been giving the Mobius a break for a while, then came
> back to it again the other day. I digged out my trusty Cygwin
> installation, grabbed the latest cvs sources of 'mn' and tried
> compiling again. I've tried everything, from tweaking the makefiles to
> voodoo magic :) and it still doesn't work :(. WARNING! Favour request:
> could someone tell me *exactly* (version numbers, too) which Cygwin
> packages they have installed, what they tweak in the sources &/or
> makefiles to get it to compile...just about everything that they do to
> get it to compile. I'm getting desperate here. Then again, if no one
> wants to, then fair enough. A hd image uploaded every 2 weeks (or when
> a major change takes place) would be *extremely* useful... ;)

This is getting silly. It seems like nobody except me can build the Mobius sources. The 
tool dependencies aren't too great (a working copy of Cygwin gcc/binutils and NASM 
will suffice), so there's clearly something wrong with the makefiles I've got set up.

It would be a good idea for someone to volunteer to take the source files and set up a 
new build process that worked everywhere.

> 3) Right, time for me to at least try to earn my keep. I think I'm
> going to have a go at porting some programs to Mobius, and also to
> create some new ones. Nothing fancy, just more-or-less essential stuff
> that one would use from day to day, really. This is where the hd image
> comes into play again. A hd image that is up to date with the latest
> cvs sources and a SDK uploaded at about the same time would be very
> very useful, and would allow me to start getting to work. Failing
> that, if anyone could help me compile the Mobius (read the above; I'm
> no newbie at compiling, but I honestly don't know why this isn't
> working :() then I'd be greatly grateful :).

Right; as long as you can build apps using the SDK, and run them on the HD image, 
building the core OS shouldn't be necessary. Part of the idea behind the SDK is to 
distribute new copies of the kernel and DLLs without putting out a new HD image, the 
intention being that you can copy the core files onto your own image using mtools or 
Winimage. Also, I've been updating the SDK more often than I've been uploading disk 
images (there haven't been any SDK updates for a while because I haven't put any 
code in for a while).

> 4) Tim (or anyone else who has a big say as to what happens to this
> project), would it be better for existing libraries and APIs and such
> to be ported to the Mobius (Allegro (that'd be a toughie), ncurses
> etc. perhaps) or would it be better for new libs and APIs to be
> designed from the ground up? I suggest the former, but maybe there's a
> good reason to *not* do that, I don't know.

I think a Posix library would be a good pre-requisite...

> 5) Hmm...if/when Mobius reaches the lofty heights of POSIX compliancy
> (is that a goal, or is it just too *NIXy and unnecessary?) and/or
> implements the entire ANSI C library (I'm not sure if you've already
> done this or not) it would be really easy to port applications, would
> it not? I mean, all that would be needed is a recompile, and there'd
> be a massive selection of software already available...then I'd be out
> of that job :)

...for porting other libraries. A lot of these Unix libraries depend on Posix functions and 
behaviour and not much else, so a good Posix layer would be an excellent starting 
point. I'm not a great fan of Unix, but if Posix is good enough for BeOS and Windows 
NT, then it's good enough for me. :)

> Whew, been some time since I made a long message like that thar one
> there. Heh, even though I'm giving OS dev a rest, the Mobius is still
> one of my primary projects and I can't wait for any more exciting
> developments. Anyway, I hope you're all well, and that life and coding
> is going well in general for you lot.

Great to hear!

Things I've been doing recently:
- Playing with some GUI prototypes. I started writing a client/server based GUI (with a 
window server in a separate process) but I was having trouble debugging it under 
native Mobius -- I didn't have a serial cable and it's hard to use printf() under graphics 
mode. So I wrote some small Win32 functions that emulated a Mobius environment 
and I've been debugging that under Windows. I haven't tried the code under Mobius 
yet, though, so who knows...

- Thinking about networking. Actually, thinking about thinking about networking. I'm still 
not sure how it will look yet -- probably something like BSD Sockets at the API end, 
and a two-tier transport/adaptor driver setup in the kernel. Not sure what it will look like 
in between, though.

We could have a set of functions like this, analogous to the socket() etc. set of 
functions:
	// create a socket bound to the TCP/IP protocol
	handle = NetCreate(NET_PROTO_TCPIP);
	// look up the host, e.g. using DNS
	address = NetLookupHost(handle, "hostname");
	// connect to the host
	NetConnect(handle, address, port);
	// write some bytes
	FsWrite(handle, "hello\n", 6);
	// close the connection to the host
	NetDisconnect(handle);
	// close the socket
	HndClose(handle);

On the server side:

	handle = NetCreate(NET_PROTO_TCPIP);
	while (NetListen(handle) && !need_to_exit)
	{
		client = NetAccept(handle);
		ThrCreateThread(client_thread, (void*) client);
	}
	NetClose(handle);

NetLookupHost would return a variable-length structure containing an address in a 
format convenient to... what? The protocol (e.g. an IP address)? The adaptor (e.g. a 
MAC address)? Probably a protocol address; I think that an adaptor should be chosen 
when you ask to connect. The problem here is: what do you do given multiple 
adaptors, each of which can run the same protocol (e.g. a network card and a 
modem)? Clearly each adaptor will be able to address a different set of hosts, so we 
need to be able to say, "this card can handle addresses that look like this".

-- 
Tim Robinson
Systems Engineer, Primary Image
tim...@pr...

==================================================
Primary Image / PI-Vision
UK tel 020 8339 9669 (fax 020 8339 9091)
USA tel 407 540 1252 (fax 407 540 1198)

The information contained in this email or any of its attachments 
is confidential and is intended for the use of the addressee only. 
Opinions expressed in this email may not be those of Primary 
Image or PI-Vision,  but the personal views of the originator. If you 
are not the addressee, any disclosure, reproduction, distribution 
or other dissemination or use of this email is strictly prohibited. 
If you have received this message in error, please contact : 
pos...@pr... and delete this message.
==================================================