[Rd] Interfacing C-code (gets and printf) under WINDOWS (Visual C++)

Hin-Tak Leung hin-tak.leung at cimr.cam.ac.uk
Fri Feb 3 12:08:10 CET 2006

In addition to everything Prof Ripley wrote, I'd just like to add that
win32 R does run under wine (in fact I am currently doing a test
loading a 150MB Rdata file into win32 R under 32-bit wine under
64-bit opteron to see how slow it might be - it takes about 2 minutes 
natively), and I believe that the usual way of building win32 R
is either mingw or cross-compile from linux. So besides mingw, one might
consider setting up a cross-compiling environment.

(and mingw also seems to install and run fine under wine, and it is my 
intention to see if I can compile and build some C code for win32 R
with mingw/wine which I wrote and have got working under linux).


Prof Brian Ripley wrote:
> Please do study the `Writing R Extensions' manual.
> The `information' you have that
>>starting R-2.0.1, the include file R-interface.h could help me.
> is misinformation: it is for writing alternative front ends under 
> Unix-alikes and not included in the Windows binary distribution. 
> R_WriteConsole and R_ReadConsole are not part of the R API (and not 
> defined in that file).
> The distinction is not between Linux and Windows, but between a 
> command-line and a console (GUI) environment.  Rterm.exe on Windows works 
> as you expect.  OTOH, there are several GUI consoles on Unix-alikes, most 
> notably the MacOS X GUI.
> For output, the manual clearly describes the problem and the solution 
> (Rprintf/REprintf).  This is used by hundreds of packages.
> For input, you can read from the stdin() connection.  However, it is 
> confusing to the users to mix up input to your functions with input to R, 
> and in a GUI context it is normal for a function to use a dialog box for 
> input.  For example, the R/Windows equivalent of gets is 
> winDialogString().
> With very few exceptions (scan(), readline(), menu(), ...) the 
> user expects to use console input only for R commands.  If your 
> interaction is like those R commands, you can execute them from your C 
> code (via eval).
> If your code needs frequent interactions with the user an alternative 
> approach is to use its own GUI.  Quite a few packages do that, using the 
> tcltk package to build a GUI in Tcl/Tk, with the analysis functions 
> programmed as callbacks.
> [I should add that Visual C++ is not supported, and that you will need to 
> make your own import library - this is described in file README.packages. 
> For a Linux programmer it would be much easier to use the supported 
> MinGW environment.]
> On Fri, 3 Feb 2006, Renard Didier wrote:
>>I try to develop a R interface to a set of C routines, in order to
>>produce a R-package on Geostatistics.
>>My C-code uses interaction with the user as I use printf and gets
>>I develop the code in a LINUX environment and do not face any problem
>>having the questions and answers routed on my current Terminal.
>>When I tried to port the package on Windows, the problems began. No
>>message was routed to the Console and I could not enter any answer. Let
>>me first admit that I am not a specialist of the WINDOWS environment.
>>I started looking for an answer on the WEB and intercepted some pieces
>>of answers ... but I did not succeed in getting a workable solution.
>>This is the reason why I put this open question here today.
>>I did not find lots of information about the gets solution. Finally, I
>>have chosen to use R_WriteConsole and R_ReadConsole which seemed to be
>>promising solutions. I discovered an information saying that starting
>>R-2.0.1, the include file R-interface.h could help me. This is the
>>reason why I downloaded the latest version available on the R site
>>(R-2.2.1). Unfortunately, I did not find such a file in the include
>>directory. Moreover, in Visual C++ that I am using for building my DLL,
>>I need to find the LIBRARY containing the objects of these two routines.
>>Did I do something wrong. Do I need to download other contributions
>>first. Do I use incorrect routines ?
>>Thank you for your help.
>>Didier RENARD

More information about the R-devel mailing list