Last update : Wednesday, March 30, 2005 04:30:27 PM

RSP RSP_C FAQ

Why it is being generated ?

To solve a few limitations of the development tools available today

What is the goal of this application ?

To generate development tools to make it easy to use the C language , and fix also some problems of the C language like memory protection and handle leaks

Will it create an intermediate file like some known compilers ?

No intermediate bulls... , the files after compilation are real win32 ( or Linux ) native executables that requires only msvcrt.dll to run

Then it requires the msvcrt.dll ?

For the moment it requires msvcrt.dll , but we will try to generate code to make it possible to generate static executables that will not depend on this Microsoft dll , but for the moment the mingw generate only files that requires msvcrt.dll ( as far as I know , but there are some packages on the mingw distribution site that appear to address this problem but we have not learned about it yet )

Describe a memory protection problem

Memory not being freed

When the RSP_C environment become more professional it will be able to detect and report memory leaks , lost handles or any other memory related problem

This will occur at runtime

At compile time it will compile as any other normal compiler will do , the difference is that it will add hooks to the apis that can cause memory problems like malloc , free , CreateThread , fopen , fclose , CreateFile  and many others

These apis will open handles and allocate memory that if not closed or freed will be detected at runtime and reported to the user

Then it will be able to avoid known memory problems at runtime , not at compile time

It is part of the environment , there is no way to disable it , and the overhead of using these hooks and checks will not affect the performance of the C code , and the algorithm can mature in such a way that after a few thousand executions , if no error occurs then it can elect it to auto disable these features and make the code run as a normal C application

To explain it in a few words it will provide runtime checks to the runtime execution , and will complain immediatelly as soon a problem occur via messagebox or another way that we are planning to generate

It can have also a global debugger application that will be initiated outside the application to report the application , line of source , and apis that have generated the problem without affecting the execution of the application

Something like the Dr. Watson , but that will not enforce the closing of the application

Will it introduce changes in the C language ?

No , the changes will occur at runtime , in this case a buggy code will just stop working as soon a bug is detected , like memory not being freed

If it cannot detect the problem when the application is executing then it will be reported when the application finish

When any protected apis is called , a function is registered to execute at the finalization of the executable that will check for memory problems

And any C code is a valid RSP_C code  but if the code has bugs detected by the environment it will not run ( or will report it in an external application ) , this mean that not all C code is a valid RSP_C code at runtime , but at compile time any C code is valid

And this mean also that any RSP_C code is automatically C compliant

We are just trying to fix some known C limitations

The version 1.0.0 has this support ?

No , it is just a prototype , there is no memory protection yet

What about the differences in the C language in different compilers ?

Well , it is being generated based on the C language supported with mingw , then in this case it means that a RSP_C code may or not work on other C compilers , it will always depend on the extensions being used by the developer

I read about protecting executable code , how will this be implemented ?

Adding checksum verification to the executable code , at runtime the first thing that the executable will do is a self check of the executable code and data

Yes , it will slow down the initialization of the executable , but it need to be supported , this is something that we think that really need to be added

It will avoid someone executing tampered files

But that version 1.0.0 is just a JIT , it don't generate the executable in the path , then how to use it as a compiler ?

Version 1.0.0 can only execute C code on the fly , it don't generate the executable in the path but in a cache folder

To access the executable search for the file in the installation directory of the RSP_C , it has a series of hexadecimal folders , this is where the file is located , you can see a list of all the cached files typing rsp_c /cachedfiles

And you can clean the cache typing

rsp_c /flush

Future versions will have the option to generate the executable in the path of the source as a normal compiler

There is no reason to make it now because the memory protectuin ws not ( yet ) generated, but as soon the protected environment work it will be added

What about the single file problem , how to compile code that requires many other C files ?

Version 1.0.0 is a single file compilation tool , but future versions will be able to handle multiple files compilation , notice that these files will not be passed on a makefile or in the command line , but it will be available internaly in the source code , it will be passed as directives that a parser will read and create the image of the makefile and compile from it

Notice that it will have the same support that makefile provide to you , then it will only compile files that have changed since the last compilation

It will be based on a modified comment added to the source , something like this:

/*

<directives>
optimization=true
debugmode=false
requires=otherfile.c
requires=otherfile.h
output=file.exe
...
<enddirectives>

*/

But since it will contruct a makefile on the fly then it isnot more easy to pass a makefile to it ?

Makefiles can have lots of options and it includes recursion , it will be a nightmare to try to detect everything that the makefile does , to avoid this overhead is that we are using these <directives> , but you can create a makefile from the source with the <directives> section , indeed it will be parte of the compiler , then you can export a makefile to compile the sources with gcc

What will comprise this RSP_C environment when it is ready ?

It will have the compiler , a killer IDE , a JIT , capability to generate components in COM based model or normal dlls ,  capability to create GUI with ease , including drag and drop of components on a form that is the method people is accustomed to create using tools available today ( VB , MSVC, .Net framework , Delphi ) , full memory protection at runtime including memory leaks and lost handles , a large library ready to be used and extended , bug detection at runtime

What the bug detection means ?

At runtime it is easy to detect if the code is buggy

As an example consider this code:

char *temp;

temp = malloc(1000);

temp = malloc(1200);

There is a bug here , the pointer temp is allocating memory that is not being freed , at runtime it is easy to detect this kind of mistake , this is one of several other checks that will occur at runtime to detect possible bugs

Then it means that I will not be able to compile and execute some code if it detect a bug on it ?

Yes , this is part of the enviroment , if you want to force the execution then use only gcc to compile your code because with RSP_C a buggy code will not execute

This will not cause problems to use RSP_C based executables in critical software ?

Yes it will , but as I have already said you have two options after a memory problem or a bug detection occurs , or a message box will appear and the application will be closed or an external application will will be initiated showing the problem , in the case of the critical software just use the second option , this way if the code has a problem it will not terminate the application

Why these runtime checks ?

The number of C code with several bugs today is too large , we are just trying to solve this problem

C is a powerfull language but it is easy to shoot your self in the foot , now with RSP_C a shoot in the foot will never occur , it is virtually impossible to execute buggy code ( when RSP_C become ready of course )

And it will speed up the development a lot , since the developer will quickly know the quality of their code

What about the license to this software ?

Well mingw is GPL , but RSP_C application is not , and never will be , RSP_C requires mingw installed to work , whether mingw will be distributed with RSP_C or not is not an issue today , but one thing is certain we will at least ask for donations to the RSP_C development , if the donation method work as expected then the application will become freeware , if not it will become shareware

Anyway you will always be entitled to compile your executables with RSP_C whether you are a supporter or not , and also with the option to convert the code to a standard C code with a ready to be used makefile

I have tried to use gcc after the installation of RSP_C but gcc is not found , why ?

We don't make changes in the environment in order to execute the rsp_c.exe , the mingw is installed but only visible to RSP_C , it occurs because we modify on the fly the environment during the call to gcc , then gcc can see the mingw\bin folder , without it gcc will not work , but as I said it only occurs when gcc is called from the RSP_C and not by a normal console call

To make mingw usable in your system register the path \mingw\bin in the environment variable "PATH" , you can do it in the control panel , the mingw folder is a subfolder of the path where RSP_C was installed , as soon the \mingw\bin is available on the path you can call gcc from the console

Notice that it has only a subset of mingw and not the complete package , it has only the minimum required to make RSP_C work

For a complete utilization of mingw , download and install the whole package from the mingw site

Again remember that RSP_C don't introduce modifications in the environment or modify any other settings in the system

If you uninstall RSP_C your system will become exactly as it was before the installation

Notice also that to make it possible to execute rsp_c.exe from any place in the system the installation will insert a file rsp_c.exe in the windows directory, if you don't want it just remove this file , in this case you need to pass the whole path of rsp_c.exe when calling the RSP_C JIT

This faq will have more information added soon