MikeOS C Library with Smaller C

[ZeroKelvin Keyboard]

Hello all,

I have put together a basic C library for MikeOS that include allows you to use
the MikeOS API and a few functions from the standard C library in to compile
C programs for MikeOS.

It uses the Smaller C compiler (https://github.com/alexfru/SmallerC), the
NASM Assembler and a Makefile build C programs for MikeOS.

The Makefile only works on Linux at the moment. You can build programs
by simple passing the makefile the name of the program. i.e.

make prog.bin

I have included the following example program to demonstrate the library.
It uses only standard C functions and should run the same with my library
on MikeOS as it does with GCC on Linux.

#include "stdio.h"
#include "stdlib.h"
#include "string.h"

char first_name[50];
char last_name[50];
char full_name[100];
char *twelve = "12";

int main(int argc, char **argv)
{
    printf("What is your first name?\n");
    gets(first_name);
    printf("Hello %s\n", first_name);
    printf("Your name is %d characters long!\n", strlen(first_name));
   
    printf("What is your last name?\n");
    gets(last_name);
    strcpy(full_name, first_name);
    strcat(full_name, " ");
    strcat(full_name, last_name);
    printf("Hello again, %s\n", full_name);
   
    printf("Here's 12: %d\n", atoi(twelve));
    printf("Here's a random number: %d\n", rand());
   
    return 0;
}

You can also use the "mikeos.h" header to do call any MikeOS
function, check out the include files for the function prototypes.

Unfortunately, I forget to check if anyone had done this already.
It seems Sasano Takayoshi made one a while back but used a
different compiler and did not implement any standard C functions.
It probably would have been better to build on that library rather
than creating a new one.

There are a few OS limits:
 - The argc & argv variables do not include the program name.
   It is not possible to pass this as MikeOS only passed the
   parameters. So argv[0] is the first parameter at the moment.
 - No fgets() yet, only gets() as os_input_string does not allow
   for a preset

In the future I will look into file and floating point functions.

Be sure to test it if you can!

Thanks,
ZeroKelvinKeyboard

[Michael Saunders]

This looks great! Will test it over the weekend.

Mike

--
You received this message because you are subscribed to the Google Groups "MikeOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mikeos+un...@googlegroups.com.
To post to this group, send email to mik...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mikeos/b95d23f8-f1c6-4c15-b179-fefb08e54968%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ZeroKelvin Keyboard]

On Saturday, 28 May 2016 06:57:36 UTC+9:30, Mike Gonta wrote:

I used Windows explorer to copy the echo.bin and prog.bin to an actual 1.44MB FAT32 floppy disk

with mikeos-4.6b1_FAT32. I reset the PC which booted from the floppy and ran both programs
from the MikeOS file selector.
There is a small issue with prog.bin. After pressing return after entering the "last name" the program
abruptly exits.

I have tested the program on the stock build of MikeOS 4.6b1 and it
works okay for me.

Could you try rebuilding the program and see it the problem persists?
This was an earlier bug that should have been fixed by now.

Perhaps there is a bug in your new 'os_load_file' routine when loading
the program? The program itself should not use the disk API.

It you are unable to build the programs on your machine, try using the attached
versions that I have just built.

Thanks,
ZeroKelvinKeyboard

[ZeroKelvin Keyboard]

On Saturday, 28 May 2016 18:35:09 UTC+9:30, Mike Gonta wrote:

On Saturday, May 28, 2016 at 1:06:45 AM UTC-4, ZeroKelvin Keyboard wrote:

On Saturday, 28 May 2016 06:57:36 UTC+9:30, Mike Gonta wrote:

I used Windows explorer to copy the echo.bin and prog.bin to an actual 1.44MB FAT32 floppy disk

with mikeos-4.6b1_FAT32. I reset the PC which booted from the floppy and ran both programs
from the MikeOS file selector.
There is a small issue with prog.bin. After pressing return after entering the "last name" the program
abruptly exits.

I have tested the program on the stock build of MikeOS 4.6b1 and it
works okay for me.

I believe you, however I think you might be using something different from what
you distributed.

This is strange. I tested the programs by:
 - Downloading my the MikeOS 4.6b1 build that I previously sent.
 - Running the build script.
 - Copying the binaries onto the new disk image.
 - Running the binaries in the QEMU emulator.
I have no idea what is going wrong. I will upload the working build folder including
disk images.

What do you mean when you say "abruptly"? The program is meant to finish after
you enter your last name. Is it terminating immediately without printing out
anything?

I have attached a screenshot of what the program should look like. Please send
me your own if the behaviour of the program differs.

Thanks,
ZeroKelvinKeyboard

 

[ZeroKelvin Keyboard]

Here is the screenshot.

[ZeroKelvin Keyboard]

On Saturday, 28 May 2016 21:16:13 UTC+9:30, Mike Gonta wrote:

What do you mean when you say "abruptly"? The program is meant to finish after
you enter your last name. Is it terminating immediately without printing out
anything?

When you hit the enter key after imputing the last name it immediately exits to the
file selector screen.

 This is strange. I tested the programs by re-downloading my the build that I
send and copying the assembled programs. I assembled the disk images and copied
the binary files directly onto the floppy disk image. If you used the
MikeOS 4.6b1 version I uploaded, you are using the same version as me.

I have no idea what is going wrong.

What do you mean when you say "abruptly"? The program is meant to finish after
you enter your last name. Is it terminating immediately without printing out
anything?

I have attached a screenshot of what the program should look like.

Now I understand the problem. My programs terminates after displaying it's
output. The TUI, however, does not pause to allow you to look at the final
output of a program.

I could make the program pause before terminating, but I do not have a standard
function to do this. If wanted to use one of my MikeOS C wrappers, I could use
one of the following lines.
 - os_wait_for_key();
 - os_pause(10);
 - while(key != KEY_ENTER); key = os_check_for_key();

However, I want to implement this program using the standard C library and
that makes it a lot more difficult.

Perhaps, we should change the TUI code to pause after a program is executed?
This would solve the annoyance losing the output of non-TUI programs.

Let me know what you think,
ZeroKelvinKeyboard

[ZeroKelvin Keyboard]

Sure, but I am still want to implement a key press delay in the TUI for
other programs that I have on disk.

I should really add 'fgets' rather than just 'gets'  but I will need to
implement my own input prompt to actually limit the number
of characters. Technically C should be using buffered I/O but
I do not want to waste memory if I can avoid it.
At the moment it uses 'os_string_input', which returns up to
255 characters plus a  null terminator.

Maybe I should add a new function to MikeOS? Some kind of
'os_string_input limited' function, for lack of a better name.
The 'os_string_input' function does cause a lot of problems,
like allowing text to go past the end of dialog boxes,
causing buffer overflows in BASIC strings and wasting heaps
of kernel space with large buffers.

[alexf...@gmail.com]

On Friday, May 27, 2016 at 8:53:18 AM UTC-7, ZeroKelvin Keyboard wrote:

Unfortunately, I forget to check if anyone had done this already.

FWIW, there's https://github.com/I8087/mlib (C wrappers around MikeOS APIs for Smaller C).

Alex

[ZeroKelvin Keyboard]

Nice work on the C compile by the way Alex, I could not have made my MikeOS
C library without it.

Not sure about the implementation of '__start', 'run_basic' and few other
functions. I might raise an issue to see if the author is aware of the
problems in these.

There are a few problems with incorrect API documentation and MikeOS being
"almost compatible" with the flat memory model (SS != DS).


 

[alexf...@gmail.com]

It looks like the handbook must be updated because it says nothing

about the extra parameter to the BASIC interpreter and deceptively tells

the programmer not to worry about segment registers. It must

document the size of the available stack and that the stack area does

not intersect anyhow (I'm guessing) with the code/data segment and

that SS != DS.

Alex

[ZeroKelvin Keyboard]

I have already informed Mike Saunders about any incorrectly documented
parameters in the MikeOS handbook. The updated version should be released
with MikeOS 4.6.

In terms of segment registers, there should not be any problems unless a
program tries to access an array on the stack. Even then, all that needs to
happen is a few segment override prefixes.

For the most part, memory access from the stack should work fine. The program
and stack area do not intersect. Parameters are collected off the stack in
Smaller C and the MikeOS C libraries use the BP register as a pointer, for
which the stack segment (SS) is implied.

I had to use a bit of a hack to allow for implementation of functions such as
'printf', which uses an array on the stack. I allocate my own stack in program
space that is used for the duration of the program.

Without this, the code generated by the Smaller C compiler does not work in
MikeOS. It tries to use a register such as BX as a pointer for which the data
segment (DS) is implied and garbage is returned.

 

 

[ZeroKelvin Keyboard]

I have posted my MikeOS C Library on GitHub, which should make it a little
easier to browse/download over the ZIP files I have been using.

See here: https://github.com/ZeroKelvinKeyboard/MikeOS-CLib

[I8087]

 Thanks for bringing this to my attention. I really appreciate the help!