Writing "ls" under windows

N

Noob

jacob said:
as I explained in another message, the dll exists,
I do not discuss that [...]

You mean "dispute". (Je ne le conteste pas)

Also you often write "what" when you should use "which".
e.g. "long double is equal to double (what is accepted by
the standard)"

And why do you insist on discussing Windows-specific code
here? Can't you find the proper group to spam after all
these years? (I suppose you just enjoy getting a rise out
of "the regs", like Kenny. I guess we all enjoy trolling
once in a while.)
 
K

Kenny McCormack

And why do you insist on discussing Windows-specific code
here? Can't you find the proper group to spam after all
these years? (I suppose you just enjoy getting a rise out
of "the regs", like Kenny. I guess we all enjoy trolling
once in a while.)[/QUOTE]

It's like shooting fish in a barrel.

--
"The smart way to keep people passive and obedient is to strictly limit the
spectrum of acceptable opinion, but allow very lively debate within that
spectrum...."

- Noam Chomsky, The Common Good -
 
J

jacob navia

Le 26/02/2014 11:26, Noob a écrit :
jacob said:
as I explained in another message, the dll exists,
I do not discuss that [...]

You mean "dispute". (Je ne le conteste pas)

Also you often write "what" when you should use "which".
e.g. "long double is equal to double (what is accepted by
the standard)"

And why do you insist on discussing Windows-specific code
here?

Strange that you do not complain when linux/gcc specific code is
discussed here. That is OK. Mingw is OK too since it is a gcc
derivative. No complaints there.

Complaints come up when somebody that is NOT GNU.

LING for short:

Lcc Is Not Gnu!

comes up.

THEN it is ok to mark it as Off topic, SPAM, etc.
Can't you find the proper group to spam after all
these years? (I suppose you just enjoy getting a rise out
of "the regs", like Kenny. I guess we all enjoy trolling
once in a while.)

It is my right to post C code here whenever I want. This is not a linux
group nor a gcc only group.

Is that clear?


P.S. Thanks for the grammar corrections.
 
J

jacob navia

Le 26/02/2014 11:39, Kenny McCormack a écrit :
And why do you insist on discussing Windows-specific code
here? Can't you find the proper group to spam after all
these years? (I suppose you just enjoy getting a rise out
of "the regs", like Kenny. I guess we all enjoy trolling
once in a while.)

It's like shooting fish in a barrel.
[/QUOTE]

This anonymous coward is not representative of anything. I am not
"trolling", and the answers from many group members was quite good.
 
N

Noob

jacob said:
Le 26/02/2014 11:26, Noob a écrit :
jacob said:
as I explained in another message, the dll exists,
I do not discuss that [...]

You mean "dispute". (Je ne le conteste pas)

Also you often write "what" when you should use "which".
e.g. "long double is equal to double (what is accepted by
the standard)"

And why do you insist on discussing Windows-specific code
here?

Strange that you do not complain when linux/gcc specific code is
discussed here. That is OK. Mingw is OK too since it is a gcc
derivative. No complaints there.

You are wrong. When someone wants to discuss POSIX-specific code,
I point them to comp.unix.programmer (I don't know where one would
discuss Windows-specific code on Usenet.)

As for discussing GCC-specific extensions (when was the last time
that happened, for my information?), well, the ratio of GCC users
to LCC users is probably about one million, so you can understand
why one would be more appropriate than the other... said:
Complaints come up when somebody that is NOT GNU.

I know you feel threatened by gcc (or rather mingw) because those
fscking commies are giving away the code that you charge for, but
that doesn't give you the right to spam/troll clc.
LING for short:

Lcc Is Not Gnu!

comes up.

THEN it is ok to mark it as Off topic, SPAM, etc.

I fail to get the point you are making.
It is my right to post C code here whenever I want.

I've been here long enough to know that you don't care when
people point out that you are misbehaving.
This is not a linux group nor a gcc only group.

This is a standard C group.
Is that clear?

Am I supposed to back down now?
P.S. Thanks for the grammar corrections.

I always try to provide constructive criticism along with
my flamebait.

Regards.
 
A

ais523

Malcolm said:
CRT seems to be something evil the Microsoft have invented to try to break
ANSI C.

Does anyone know what it actually does?

[Implementation details of C compilers are on-topic here, aren't they?]

A common implementation strategy when writing C implementations is for
many of the standard library functions (things like strlen, etc.) to
be written in C (typically using non-strictly-conforming C in order to
implement functions that cannot be implemented in strictly
conforming freestanding C), and then linked to user programs using
whatever facilities the compiler already provides for separate
compilation.

On Linux, this is commonly done via providing most of the standard
library (both functions in the C standard, and some other functions such
as those in POSIX) in a file named libc.so or libc.a, which is in an
acceptable format to the implementation's linker. (The difference is
that libc.a is combined into the output executable directly, whereas
libc.so is a separate file that needs to be present at runtime, and is
combined into the executable by the dynamic linker, meaning its contents
do not need to be copied into every executable the compiler outputs.)

msvcrt.dll is basically exactly the same thing as libc.so, as used by
the C compiler component of Microsoft Visual C++; it contains compiled
representations of library functions that are referenced by executables
output by the compiler. As a result, it's needed to run the output from
MSVC++, and so needs to be shipped with the resulting executables.
 
J

James Kuyper

jacob navia wrote: ....

You are wrong. When someone wants to discuss POSIX-specific code,
I point them to comp.unix.programmer (I don't know where one would
discuss Windows-specific code on Usenet.)

As for discussing GCC-specific extensions (when was the last time
that happened, for my information?), ...

gcc gets frequently mentioned here, but mainly as the name of the
compiler someone happens to be using or could use to compile their code.
gcc extensions get mentioned fairly often, but usually only for the
purpose of identifying them as extensions, distinct from standard C. I
went searching for messages containing "gcc", to find out which ones
were part of actual discussions (two or more posters exchanging
messages) about gcc-specific code. I couldn't find any in the past year
or so, at which point I gave up. The closest I came was in a thread
titled "sscanf up to 127 characters into a buffer", in which one poster
suggested that something might be a gcc extension, and many people
responded by pointing out that it was in fact a standard C feature,
introduced in C99.
... well, the ratio of GCC users
to LCC users is probably about one million, so you can understand
why one would be more appropriate than the other... <cough>

In order to be more appropriate, it would first have to be appropriate.
gcc has its own forums, which would be better places to discuss such
things, if there were in fact anyone wasting their time by discussing
gcc-specific code here.
 
G

Geoff

CRT seems to be something evil the Microsoft have invented to try to break
ANSI C.

Does anyone know what it actually does?

It's Microsoft's implementation of the Standard C Library plus the
Microsoft extensions, performing the same kind of functionality as
libc.so in Linux. Under Microsoft C, one has the option of dynamically
linking to the library or statically linking. In those applications
that are dynamically linked, the msvcrt.dll is the referenced DLL.

Current versions of Microsoft Visual Studio provide the same
functionality in compiler-version-specific DLLs, making msvcrt.dll
obsolescent. Microsoft Visual Studio 2010 links with msvcr100.dll,
Microsoft Visual Studio 2013 uses msvcr120.dll, and I'm sure we can
expect more of the same in future releases so it would appear we are
back in DLL hell.

The C++ runtime is provided in msvcpXXX.dll, etc, where XXX is the
version number of the studio that built the project per the above
description.

As far as Jacob's assertion that msvcrt.dll "doesn't exist" this is in
direct conflict with observed facts on the systems I have at hand
here. The DLL does exist on 3 systems in my lab and on the two 64-bit
systems I checked, it exists as both 64 and 32 bit libraries.

Microsoft has this to say about it:
"The msvcrt.dll is now a 'known DLL,' meaning that it is a system
component owned and built by Windows. It is intended for future use
only by system-level components."

I think Jacob means "msvcrt.dll can be ignored for new development"
but he certainly says it very badly.
 
K

Kenny McCormack

Geoff said:
I think Jacob means "msvcrt.dll can be ignored for new development"
but he certainly says it very badly.

I'm sure he'll be very upset to find that you don't approve of his use of
the English language. I'm sure he is deeply wounded.

Anyway, there is ample precedent, in the realm of computerdom, for the
practice of asserting that something doesn't exist when it clearly does
exist, where what the speaker really means is: You shouldn't (or can't) use
it. I'm sure we can all come up with examples from our own personal lives.
I'm also sure that this is the sense in which Jacob meant it.

Furthermore, there is enormous precedent in this very newsgroup of the regs
telling hapless newbies that certain things (that clearly exist) do not
exist (e.g., gcc, POSIX, write(), GetTempPath(), Microsoft, etc, etc).
There is also precedent for telling those same newbies tales of things that
don't exist - such as the DS9000, nasal daemons, and a suffusion of yellow.

But that's just life as usual in CLC...

--
Both the leader of the Mormon Church and the leader of the Catholic
church claim infallibility. Is it any surprise that these two orgs
revile each other? Anybody with any sense knows that 80-yr old codgers
are hardly infallible. Some codgers this age do well to find the crapper
in time and remember to zip-up.
 
J

jacob navia

Le 26/02/2014 08:48, Geoff a écrit :
I don't know what Jacob means but the msvcrt.dll exists in
C:\Windows\System32 directory on Windows 7/64 and it's 64-bit. The
32-bit version is in C:\Windows\SysWOW64.

Excuse me but reading the file header of the program it is marked as
"i386" i.e. a 32 bit program using the pedump dumping utility of
lcc-win. There has never been any 64 bit version of that file!
 
G

Geoff

Le 26/02/2014 08:48, Geoff a écrit :

Excuse me but reading the file header of the program it is marked as
"i386" i.e. a 32 bit program using the pedump dumping utility of
lcc-win. There has never been any 64 bit version of that file!

On your system perhaps. I cannot explain that.

Here is a link to the binary as found on my system:
https://www.dropbox.com/s/rtwl6wu7t9haqrz/msvcrt.dll

Examine it yourself and tell me what you conclude.
 
J

jacob navia

Le 27/02/2014 03:19, Geoff a écrit :
On your system perhaps. I cannot explain that.

Here is a link to the binary as found on my system:
https://www.dropbox.com/s/rtwl6wu7t9haqrz/msvcrt.dll

Examine it yourself and tell me what you conclude.

You are right. This is a 64 bit version of msvcrt.dll that was linked in
2011, 2 years later as the 32 bit version in my system that was compiled
in 2009.

It has also new functions absent in the old version of msvcrt.dll (the
microsoft extensions that have now been accepted into the C standard).

So, in principle I could have used that. Happily I didn't :)

I prefer the situation now: lcc-win has its own C99 version of the C
standard library.

I stand corrected then. Mystery remains, why I do NOT have that version
in my system. but a 32 bit 2009 version. Anyway thanks, I learned
something today.

jacob
 
G

Geoff

Le 27/02/2014 03:19, Geoff a écrit :

You are right. This is a 64 bit version of msvcrt.dll that was linked in
2011, 2 years later as the 32 bit version in my system that was compiled
in 2009.

It has also new functions absent in the old version of msvcrt.dll (the
microsoft extensions that have now been accepted into the C standard).

So, in principle I could have used that. Happily I didn't :)

I prefer the situation now: lcc-win has its own C99 version of the C
standard library.

I stand corrected then. Mystery remains, why I do NOT have that version
in my system. but a 32 bit 2009 version. Anyway thanks, I learned
something today.

jacob

You're welcome and thank you for backing down on your insistence that
the 64-bit dll didn't exist.

I don't blame you for writing your own C99 version since Microsoft is
so hell bent on not supporting C99. I respect you for your work and
your lcc product.

As for where the DLL came from, I don't know. I'd expect Windows to
include it since it has both 64 and 32 bit components and they'd be
using the "known DLL" per their policy.
 
K

Kaz Kylheku

I stand corrected then. Mystery remains, why I do NOT have that version
in my system. but a 32 bit 2009 version. Anyway thanks, I learned
something today.

In general, why anyone has any particular version of any DLL on any Windows box
is a mystery.
 
K

Kenny McCormack

[QUOTE="Richard said:
"Au royaume des aveugles, les borgnes sont rois."
[/QUOTE]

"In the kingdom of the blind, the one-eyed man is king".
If he was discussing his Honda Civic you might have a point. As it is he
wasn't and did sort it in the thread related to C.

Get a life.

Indeed. You know people are on their last possible leg when they start
lamenting and disparaging successes. (That is, saying, well you were just
lucky this time; you're still a schmuck)
 
K

Ken Brody

Le 26/02/2014 08:48, Geoff a écrit :

Excuse me but reading the file header of the program it is marked as "i386"
i.e. a 32 bit program using the pedump dumping utility of lcc-win. There has
never been any 64 bit version of that file!

What version of Windows are you on?

On my 64-bit Windows 8 box:

========

Typing "set proc" gives me:

PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3c03

And "set platform" gives me:

Platform=X64

========

Dump of file \windows\system32\msvcrt.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
8664 machine (x64)
8 number of sections
5215F944 time date stamp Thu Aug 22 07:43:00 2013
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
Application can handle large (>2GB) addresses
DLL
[...]

========

Dump of file \windows\SysWOW64\msvcrt.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
14C machine (x86)
5 number of sections
52158FF5 time date stamp Thu Aug 22 00:13:41 2013
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
[...]

========
 

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

Forum statistics

Threads
474,075
Messages
2,570,549
Members
47,197
Latest member
NDTShavonn

Latest Threads

Top