Hello world console program with lcc-win32

T

tm

Hi, I have a problem with lcc-win32:
The generated executables are not useable.

I use XP Service Pack 3
Lcc has version 3.8 Compilation date: Jan 29 2011
Lcc is installend in C:\lcc with the official installer.
The path variable contains C:\lcc\bin
The environment variable LCCDIR is set to C:\lcc

I just tried to compile hello world with lcc-win32.
Lcc generates an executable with lcc hello.c -o hello.exe
When I start hello.exe it writes nothing and hangs.
I need to kill ntvdm.exe to stop the hang. In some tests a
a message box appeared that tells me that Ntvdm found an
illegal instruction. The hello world is as follows:

---------- begin file hello.c ----------
#include <stdio.h>

int main (int argc, char *argv[])
{
printf("Hello, world\n");
return 0;
}
---------- end file hello.c ----------

Can it be, that I need to use WinMain?
This would certainly be a problem, since the application
I try to compile insists on having a 'main'.
Other C compilers for Windows allow 'main' also, so
hopefully this is not a problem for lcc-win32.

Please help me.
Thanks in advance for the effort.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
B

BartC

I just tried to compile hello world with lcc-win32.
Lcc generates an executable with lcc hello.c -o hello.exe
When I start hello.exe it writes nothing and hangs.
I need to kill ntvdm.exe to stop the hang. In some tests a
a message box appeared that tells me that Ntvdm found an
illegal instruction. The hello world is as follows:

I think that you are telling it to name the object file as hello.exe instead
of hello.obj. No wonder it causes a problem...

Don't know to to combine compile and link in lcc-win32. But the following
ought to work:

lcc hello.c
lcclnk hello.obj
hello
 
J

jacob navia

Le 07/07/11 14:49, tm a écrit :
Hi, I have a problem with lcc-win32:
The generated executables are not useable.
just tried to compile hello world with lcc-win32.
Lcc generates an executable with lcc hello.c -o hello.exe

You should do

lc hello.c

"lc" and NOT "lcc". lcc just translates that to object
code format and needs a link.

If you are unsure just use the IDE, it is much easier
 
K

Keith Thompson

tm said:
Hi, I have a problem with lcc-win32:
The generated executables are not useable.
[...]

For future reference, questions like yours are better posted to
comp.compilers.lcc, or submitted to the lcc-win32 support mechanism.
You're asking about the behavior of a particular implementation,
not about the C language.

(Please ignore the inevitable flurry of followups claiming that
I'm being rude by suggesting a better way to get help.)
 
T

tm

Le 07/07/11 14:49, tm a écrit :> Hi, I have a problem with lcc-win32:

just tried to compile hello world with lcc-win32.


You should do

lc hello.c

"lc" and NOT "lcc". lcc just translates that to object
code format and needs a link.

Thank you for the information, it allowed me to proceed.
Compiling and execute hello world with lcc succeds. :)

Now a different problem surfaced. Both ways

lc setpaths.c -o setpaths.exe

and

lcc -c setpaths.c
lcclnk setpaths.obj -o setpaths.exe

give me the error:

setpaths.obj .text: undefined reference to '__wgetcwd'

Which library is necessary for _wgetcwd?
Which lcclnk command links this library?
Which lc command links this library?
Do I need to set up some library search path?

AFAICS (at MSDN) _wgetcwd seems to be part of the windows version of
the standard C library. Other Windows C compilers do not require
special libraries for _wgetcwd.
If you are unsure just use the IDE, it is much easier

Of cause, an IDE is easier to use.
In my case I want to do two things where an IDE would not help.
1. I want to create a makefile that allows other users to compile
Seed7 with lcc.
2. The Seed7 compiler generates C and needs a C compiler and linker
as backend.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
J

jacob navia

Le 07/07/11 19:48, tm a écrit :
Thank you for the information, it allowed me to proceed.
Compiling and execute hello world with lcc succeds. :)

Now a different problem surfaced. Both ways

lc setpaths.c -o setpaths.exe

and

lcc -c setpaths.c
lcclnk setpaths.obj -o setpaths.exe

give me the error:

setpaths.obj .text: undefined reference to '__wgetcwd'

Which library is necessary for _wgetcwd?
Which lcclnk command links this library?
Which lc command links this library?
Do I need to set up some library search path?

AFAICS (at MSDN) _wgetcwd seems to be part of the windows version of
the standard C library. Other Windows C compilers do not require
special libraries for _wgetcwd.

wgetcwd is not a standard ANSI C function. I haven't gotten around
to writing it.

You can synthetize it
by getting the path with getcwd, then using mbstowcs to transform
it into a wide character string.

You can also synthetize it with the windows API using unicode.
 
J

jacob navia

Le 07/07/11 19:59, jacob navia a écrit :
You can also synthetize it with the windows API using unicode.

Use the windows API with

GetCurrentDirectoryW

that is in kernel32.dll
 
T

tm

Le 07/07/11 19:48, tm a écrit :











wgetcwd is not a standard ANSI C function. I haven't gotten around
to writing it.

OKAY.
What other wide functions are missing?

I use the wide functions for Unicode support under Windows.
The Windows port of Seed7 with MinGW (and other compilers) uses:
_wchdir, _wgetcwd, _wmkdir(path), _wrmdir, _wopendir, _wreaddir,
_wclosedir, _wstati64, _wchmod, _wutime, _wremove, _wrename,
_wsystem, _wpopen, _wfopen, _wgetenv and _wputenv.

MinGW, Cygwin, MSVC, Borland, TinyC and DJGPP support them
(sometimes with and sometimes without underline, but this can
be handled with preprocessor macros).
You can synthetize it
by getting the path with getcwd, then using mbstowcs to transform
it into a wide character string.

IMHO windows functions like getcwd handle strings depending on the
current codepage. So the Unicode support seems limited (but I am
not an expert of Windows codepages and multibyte strings).
You can also synthetize it with the windows API using unicode.

Yes, but I was hoping that this work was already done. :)

BTW. Is there support for files with 64 bit offsets?

Thanks in advance, for your effort.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
T

tm

Le 07/07/11 19:59, jacob navia a écrit :




Use the windows API with

GetCurrentDirectoryW

that is in kernel32.dll

Thank you for this information.
As you can see in the other post, I need other wide character
functions also.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
J

jacob navia

Le 07/07/11 20:28, tm a écrit :
OKAY.
What other wide functions are missing?

I use the wide functions for Unicode support under Windows.
The Windows port of Seed7 with MinGW (and other compilers) uses:
_wchdir,

SetCurrentDirectoryW

_wgetcwd,

GetCurrentDirectoryW

_wmkdir(path),

CreateDirectory

_wrmdir,

RemoveDirectory

_wopendir,
_wreaddir,
_wclosedir,

I don't know what those should do.

_wstati64,

Can be done with the windows API

_wchmod, _wutime,

_wremove, _wrename,
_wsystem, _wpopen, _wfopen, _wgetenv and _wputenv.

None of those...
MinGW, Cygwin, MSVC, Borland, TinyC and DJGPP support them

No, they link with the run time library of MSVC. I don't link with that
since it is not C99.


You can do this easily with:

Handle h = LoadLibrary("msvcrt.dll");

Then fill all the function pointers to each of those functions in
a loop with:

GetProcAddress(h,"wstati64");

etc

jacob
 
B

BartC

jacob navia said:
Le 07/07/11 20:28, tm a écrit :

No, they link with the run time library of MSVC. I don't link with that
since it is not C99.


You can do this easily with:

Handle h = LoadLibrary("msvcrt.dll");

Then fill all the function pointers to each of those functions in
a loop with:

GetProcAddress(h,"wstati64");

Looks like a lot of work.

You have a file MSVCRT.LIB in your distribution, which appears to contain
the function wgetcwd(). What is the purpose of that, if not for statically
linking with?

(In fact, the following seems to work, when linked with msvcrt.lib; I had to
guess the signature of _wgetcwd():

#include <stdio.h>
#include <stdlib.h>
#include <wctype.h>

wchar_t* _wgetcwd(wchar_t *,int);

int main(void)
{
wchar_t a[500];
int i;

_wgetcwd(a,500);

printf("%S\n",a);

}

)
 
T

tm

Looks like a lot of work.

You have a file MSVCRT.LIB in your distribution, which appears to contain
the function wgetcwd(). What is the purpose of that, if not for statically
linking with?

(In fact, the following seems to work, when linked with msvcrt.lib; I hadto
guess the signature of _wgetcwd():

I found the prototype of _wgetcwd() in C:\lcc\include\direct.h

How did you tell lcclnk or lc to link MSVCRT.LIB?


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
B

BartC

I found the prototype of _wgetcwd() in C:\lcc\include\direct.h

How did you tell lcclnk or lc to link MSVCRT.LIB?

The direct way, when the source is c.c, might be:

lcclnk -o c.exe c.obj \lcc\lib\msvcrt.lib

(with many object files, put the names in a file, one per line, and use
@filename in the command line)
 
J

jacob navia

Le 07/07/11 22:32, BartC a écrit :
The direct way, when the source is c.c, might be:

lcclnk -o c.exe c.obj \lcc\lib\msvcrt.lib

(with many object files, put the names in a file, one per line, and use
@filename in the command line)

Yes.

I should do the wide char file functions. As I should do so many
things but I can't. I can do only some things at a time. Nobody
has asked for those functions till now. They aren't really difficult
to write but they do mean some amount of work, I would say 2 days.

If you wrote them Thomas, please share the code with lcc-win.

If you use msvcrt.lib they *could* work out of the box, give
it a try. And please note that lcc-win doesn't distribute
msvcrt.dll
 
T

tm

Le 07/07/11 20:28, tm a écrit :



SetCurrentDirectoryW

_wgetcwd,

GetCurrentDirectoryW

_wmkdir(path),

CreateDirectory

_wrmdir,

RemoveDirectory

_wopendir,
_wreaddir,
_wclosedir,

I don't know what those should do.

_wstati64,

Can be done with the windows API

_wchmod, _wutime,

_wremove, _wrename,


None of those...

So I need to rewrite this functions to compile my program
with lcc-win32?
No, they link with the run time library of MSVC.

AFAIK Borland has its own implementation.
And wouldn't it violate the spirit of free software if Cygwin would
be based on the run time library of MSVC?
I don't link with that
since it is not C99.

OKAY.
Supporting standards is important. Programs become portable because
of standards.

BTW: How do you support Unicode?
Modern Linux/Bsd/Unix systems use the UTF-8 locale. All ANSI C and
Posix interfaces operate with UTF-8. This way a program can use the
standard C and Posix functions and automatically has full Unicode
support.

A runtime library for windows could provide optimal portability
by supporting ANSI C (and Posix) interfaces with UTF-8 as well.
Sadly no windows library works this way (HINT). The other way,
bringing the Windows interface to the Unix world, is done with
Wine and Mono.

Since the classic ANSI C and Posix like interfaces in Windows use
codepages they IMHO cannot be used for portable Programs with real
Unicode support.

The next easy way are the ANSI C-like and Posix-like wide character
functions (mentioned in the other mail). This functions are defined
in the same headers as the non-wide counterparts, so some macro
definitions and some conversion functions can be used to create a
portable program with real Unicode support.

For Seed7 I decided to use this way. Internally Seed7 uses UTF-32.
When talking to the OS UTF-32 is converted to UTF-8 or UTF-16
(depending on the operating system).

The hardest way for Unicode support is: Use OS specific functions
for everything. I consider this as last resort.

Portability begins, when you can move soucecode from OS to OS
without changing a single line (and it just compiles and runs).
You can do this easily with:

Handle h = LoadLibrary("msvcrt.dll");

Then fill all the function pointers to each of those functions in
a loop with:

GetProcAddress(h,"wstati64");

Thank you for pointing this out.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
T

tm

Le 07/07/11 22:32, BartC a crit :





Yes.

I should do the wide char file functions. As I should do so many
things but I can't. I can do only some things at a time. Nobody
has asked for those functions till now. They aren't really difficult
to write but they do mean some amount of work, I would say 2 days.

Please tell me, when they are ready. :)
I reached some success with linking msvcrt.lib . BTW, your header
files contain definitions of several wide char functions. I found
some issues with your header files:

_wpopen is defined in wchar.h but not in stdio.h
_wstati64 is defined in wchar.h but not in sys/stat.h
_fstati64 is missing although _stati64 and _wstati64 are present.

Since the wide char functions are not ANSI, I used MSDN as reference.
If you wrote them Thomas, please share the code with lcc-win.

Implementations of wgetenv, wsetenv, wopendir, wreaddir, wclosedir
and alternate_utime can be found in the Seed7 package. I wrote them
in the past to support MinGW, MSVC and Borland C. But this functions
are tailored for the Seed7 runtime library, so they probably might
only be useable as inspiration.
If you use msvcrt.lib they *could* work out of the box, give
it a try. And please note that lcc-win doesn't distribute
msvcrt.dll

Out of the box is a little bit overstated, see the header file
issues above. Of couse, a solution without msvcrt.dll, would be
preferable.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top