programmer needs ideas

[Gary R. Schmidt]

Em Sun, 16 Jul 2006 00:21:15 +0100, Ian Edmont escreveu:





Because some languages have specific applications, e.g.:

- COBOL runs mostly on mainframes;

No - lots of minis and micros run COBOL apps.

- Lisp is used in Computer Science research;

Yes - and to help use up the oversupply of parentheses characters in the
universe.

- Fortran is used on scientifical research (physics, chemistry,
mathematics); Yes.

- Perl is used a lot on UNIX shell scripts.

No - PERL *is* a scripting language. Lots of web stuff is done in PERL,
notably PHP runs on top of it.

- I think that Pascal is used as the first programming language for
Computer Science students.

Yes, PASCAL is/was often taught as a first language.

Cheers,
Gary B-)

 

[REM]

Isn't that practically undoable?? After all, who could say what the
purpose of an exe is? One could presumably implement self-extracting
exes in any number of ways - making the job of determining what exes are
compressed files difficult? Unless I'm missing some trick, of course.

It looks to be possibly possible.

http://filext.com/detaillist.php?extdetail=EXE

The first two bytes of a program exe:

Hex: 4D 5A
ASCII: MZ

Looking in a text editor you'll see MZ as the first two characters.

It gets complicated after that, as there is no identifier for a sfx.

The first two bytes of a Pkzip file:

Hex: 50 4B
ASCII: PK

Zip genius files use the above (MZ and PK). There are so many
compression programs that I'm not sure if everyone uses the above
identifiers, or not. If so, a program that reads the first two bytes
of every .exe on disk. making the appropiate list will work.

 

[socrtwo]

the title says it all, if you have anything then please feel free to
post, or preferably email me at <metheperson1980(at)gmail.com>

Don't forget the Freeware Wishlist at freewarehome.org:

http://www.pricelesswarehome.org/acf/FreewareWishList.php

Also, freeware or a free add-in for PowerPoint which would allow the
opening of PDF documtents as say jpg images and the inclusion of text
boxes over these images which can be edited at any time. The advantage
of this is for filling out static PDF forms like rebate forms. This
has been done but not good enough yet my estimation.

If you do it, use the functionality of Ghost script.

 

[Al Klein]

why dont we have ONE programming language?

Because different languages do different things.

Try describing Special Relativity or Quantum Mechanics in English.
Mathematics is much easier to describe them in. (It's not even
possible to accurately describe either one in English only.) It's not
the same but, for example, creating dynamic web pages using COBOL is
like performing open heart surgery on yourself through your mouth,
while using PERL to do it is like trying to slide on glare ice - it's
trivial, using almost no effort.

Or, since a computer language is a tool, try repairing a car engine
using only surgical tools. Or operating on a person using only what
you'd find in a mechanic's tool box. You use the tool that was
designed for the particular job.

CROSS PLATFORM .. like English is the worlds language.

Well ... not really - there are millions of people who don't know more
than a few words of English, and I'm not even including those who
speak Pidgin as non-English-speakers.

But computers have a common (to the CPU) language - machine language.
ALL x86 computers "speak" x86. ALL 6x000 computers speak 6x000. The
operating system makes no difference - the CPU runs machine language.
Or microcode, if you want to drop down a level more.

 

[Al Klein]

some languages have specific applications, e.g.:

- COBOL runs mostly on mainframes;

Is usually used, most efficiently, to process money and data. On any
size computer.

- Lisp is used in Computer Science research;

Is usually used, most efficiently, to handle lists.

- Fortran is used on scientifical research (physics, chemistry,
mathematics);

Is usually used, most efficiently, to process formulas.

- Perl is used a lot on UNIX shell scripts.

Is usually used, most efficiently, to parse and generate text.

- I think that Pascal is used as the first programming language for
Computer Science students.

For many of them, but many pretty large commercial programs have been
written in Pascal.

COBOL started on mainframes. Lisp is used a lot in CS work. Fortran
used to be used in research. Shell scripts are written in the shell
language being used. Perl programs are called by shell scripts to do
what Perl programs do best. (Other programs are called by shell
scripts also. AWK, CAT, FIND, etc., aren't written in Perl, for
example.)

 

[Al Klein]

John Fitzsimons wrote:

Isn't that practically undoable?? After all, who could say what the
purpose of an exe is? One could presumably implement self-extracting
exes in any number of ways - making the job of determining what exes are
compressed files difficult? Unless I'm missing some trick, of course.

It's possible, but extremely slow, to parse each .exe to determine if
it's a *KNOWN* self-extracting compressed format. That's about as far
as you can go.

There's not enough computing power to determine whether a particular
..exe file, that doesn't have the signature of a known self-extractor,
is actually an installation package. Probably won't be this century
either. It would have to be run virtually and its actions
intelligently watched, to see if it was installing a package or merely
doing things that looked like an installation but wasn't.

 

[Al Klein]

Continuing on the Forth idea, there's actually an effort to create an
alternative OS called RetroForth:
http://www.retroforth.org/
It "works" - in the sense that you can read and write to disk, and you
can program in it. RetroForth has strong links with Reva Forth.

So you push"on-screen display", push "read", push the filename, then
click "execute"?

 

[Mark Carter]

So you push"on-screen display", push "read", push the filename, then
click "execute"?

It's text-only. The native version (although it can be run hosted)
doesn't have a file-system so there are no filenames. You read and write
the blocks of the hard-drive directly. Very low-level.


Here's a thought for the OP that I'd like to see implemented: a tiny
personal SMTP server. My work server doesn't allow relaying from outside
the office, and Yahoo puts damn adverts on the bottom of messages. A
personal SMTP server would be a neato thing to have. A while ago I
started such a thing using Python.

Good project for learning about sockets and protocols. The good news is
that many languages you might want to try include socket support. Even
CLISP for win32 has it.

 

[Renan(tm)]

Al Klein telegrafou o seguinte:

Fortran used
to be used in research.

And still is. I know a programmer/scientist which works with FORTRAN
programming to do data analysis for the petroleum industry.

[]s

 

[John Fitzsimons]

It's possible, but extremely slow,

The process taking some time wouldn't bother me. I knew it wasn't a
"trivial" job.

to parse each .exe to determine if
it's a *KNOWN* self-extracting compressed format. That's about as far
as you can go.

There's not enough computing power to determine whether a particular
.exe file, that doesn't have the signature of a known self-extractor,
is actually an installation package. Probably won't be this century
either. It would have to be run virtually and its actions
intelligently watched, to see if it was installing a package or merely
doing things that looked like an installation but wasn't.

Well, an exe that is a compressed file would almost certainly result
in multiple files and/or a change in it's size after extraction. I
would think that running things virtually could determine either
of those situations.

For example run something.exe and IF it starts creating extra files
then stop the process and confirm that it is a compressed file. Or
run it and as soon as it is seen that a different sized file is being
created stop the process and confirm that it is a compressed file.

Keep in mind that the original poster didn't ask for "easy"
ideas.

Regards, John.

 

[John Fitzsimons]

It looks to be possibly possible.

The first two bytes of a program exe:

Hex: 4D 5A
ASCII: MZ

Looking in a text editor you'll see MZ as the first two characters.

It gets complicated after that, as there is no identifier for a sfx.

The first two bytes of a Pkzip file:

Hex: 50 4B
ASCII: PK

Zip genius files use the above (MZ and PK). There are so many
compression programs that I'm not sure if everyone uses the above
identifiers, or not. If so, a program that reads the first two bytes
of every .exe on disk. making the appropiate list will work.

Yes, according to your link above...

"All of these files start with ASCII MZ but often those produced by
different compilers have further identification. "

It seems to be that one would search an .exe NOT for a particular
"further identification" but ANY "further identification". The absence
of this would suggest that the .exe isn't a compressed file.

Regards, John.

 

[REM]

John Fitzsimons <[email protected]> wrote:

Yes, according to your link above...

"All of these files start with ASCII MZ but often those produced by
different compilers have further identification. "

It seems to be that one would search an .exe NOT for a particular
"further identification" but ANY "further identification". The absence
of this would suggest that the .exe isn't a compressed file.

It looks like a bust. I've checked several sfx archive files that I
have on disk, along with a bunch of program executables, and there is
no pattern that can be used to identify one or the other.

Oh well, without a standard, it's just not going to work.

Another method is using a batch file and unzipping with only the (-t)
test switch. An error occurs if it is a program file, or if the
compressed file is corrupted. A normal program return occurs if the
file is a good, sfx .exe.

 

[Al Klein]

Well, an exe that is a compressed file

Only known compression signatures could be checked. There's no
universal way to determine whether a particular file is compressed.

would almost certainly result
in multiple files and/or a change in it's size after extraction.

Check a compressed exe after extraction, John. The compressed file is
still the same compressed file with the same size, even the same MD5
hash.

I would think that running things virtually could determine either
of those situations.

Since the first situation doesn't exist, yes the second one could be
checked. But an executable can also create files when running, so
just the fact that the exe created files isn't proof that it's only a
compressed installer.

For example run something.exe and IF it starts creating extra files
then stop the process and confirm that it is a compressed file.

Again - no way to determine that, except for known compression
signatures.

Keep in mind that the original poster didn't ask for "easy"
ideas.

He implied that he wanted things that were at least feasible.

 

[REM]

John Fitzsimons <[email protected]> wrote:

On 14 Jul 2006 16:55:37 -0700, (e-mail address removed) wrote:

Here is an idea. Do something that nobody else has been able to do
(despite claims to the contrary in this newsgroup). Make a program
that can list all the .exe files one has on a computer. EXCLUDING
the .exe files that are simply compressed files.

This is NOT simply a list of (registry) "installed programs". An
application can run without making entries in the registry.

Hope you can succeed where others have failed.

Different approach... look for existing program:

http://drn.digitalriver.com/category.php[id]14[SiteID]driverguide

shaid260.zip - Download Now!

Released: Feb 05, 2000 OS: MS-DOS License: Freeware Price:

SH Archive Identifier v2.60 is a small utility program to identify
archive and self-extractive files. It recognizes 115 archive and 47
self-extractive files. Used from the command line, or via batch file.
It relates in a verbal form which kind of archive it deals with and
returns a certain error level to DOS. Can be used like Test file, or
without parameters. Includes a sample PCBTEST.BAT to demonstrate how
it works. There is also a small but working ACVT.BTM to convert
archives between each other. Recognized archives: 3270, 777, acb, ace,
ain, amgc, ar7, arc, arg, akt, akt32, arhangel, ari, arj, arjz, arq,
arx, asd, bix, bli, boa, bsa, bsarc, bts, bzip, cab, and many more.
SFXs: ace, akt, ain, arc, arhangel, arj, ars, arx, asd, blink, bsa,
cab, car, charc, compack, dwc, esp, hpa, hyper, ice, imp, jrc, larc,
leo, lgha, lha, lharc, lhark, lza, nashrink, pak, pkpak, pksfx,
pksfxjr, quark, rar, rax, rk, sbx, sqwez, sqzsfx, sqzsfxjr, tgzsfx,
uc2, zoo. Changes: Additional new formats, bug fixes, extended
recognitions, error levels. Old users that have their own batch files
must use helper-kit coming along with this archive. SFX numbering has
changes from the last version (starts from 140 instead of 100).
shaid260.zip has replaced shaid250.zip. Freeware. Uploaded by the
author. Eero T. Heinonen, SH Software (e-mail address removed)

 

[Al Klein]

Al Klein wrote:

It's text-only. The native version (although it can be run hosted)
doesn't have a file-system so there are no filenames. You read and write
the blocks of the hard-drive directly. Very low-level.

Someone reinvented STOIC.

 

[Al Klein]

Yes, according to your link above...

"All of these files start with ASCII MZ but often those produced by
different compilers have further identification. "

It seems to be that one would search an .exe NOT for a particular
"further identification" but ANY "further identification". The absence
of this would suggest that the .exe isn't a compressed file.

The "further identification" could be data, identification, executable
code ... there's no difference between 0x41 as "A", an identifier or a
byte of executable code. There's no way to find "further
identification" by just looking at the bytes in the program - it has
to be traced, from the entry point, byte by byte. This means
relocation for some programs, before it can be traced. The analysis
program would have to be a virtual environment.

The only guaranteed way to know whether an .exe file is an executable
program, the executable portion of a self-extracting file of data or a
self-extracting installation, is to know what you downloaded, and no
program is going to know that unless it's told - at which point the
need for the program is moot.

 

[Al Klein]

Different approach... look for existing program:

http://drn.digitalriver.com/category.php[id]14[SiteID]driverguide

Still won't meet John's criteria. There's no way to tell,
programmatically, whether a self-extracting file is a compressed .exe,
a self extracting file of data or an installation program. the first
one, according to John's criteria, is an installed program, the other
two aren't.

 

[REM]

Still won't meet John's criteria. There's no way to tell,
programmatically, whether a self-extracting file is a compressed .exe,
a self extracting file of data or an installation program. the first
one, according to John's criteria, is an installed program, the other
two aren't.

I had to reread the original:

-----------------------------------------------------------------------------

Here is an idea. Do something that nobody else has been able to do
(despite claims to the contrary in this newsgroup). Make a program
that can list all the .exe files one has on a computer. EXCLUDING
the .exe files that are simply compressed files.

This is NOT simply a list of (registry) "installed programs". An
application can run without making entries in the registry.

-----------------------------------------------------------------------------

I'm reading this as, "list all program .exe files on a drive."
Do not include sfx of anykind?

Is this correct John?

If so, I think this program will work with a little batch help. It has
identified everything I've thrown at it so far, but I don't have any,
"compressed program files."

This should not matter, as exclusion from the list is via having being
identified as a sfx, using the test switch and error level return.

 

[REM]

Al Klein <[email protected]> wrote:

The only guaranteed way to know whether an .exe file is an executable
program, the executable portion of a self-extracting file of data or a
self-extracting installation, is to know what you downloaded, and no
program is going to know that unless it's told - at which point the
need for the program is moot.

I don't think so. Take the program listed in the other post for a
spin!

 

[Mark Carter]

Real Men don't need filesystems, they run a magnet over the hard drive
to store their information. Of course, True Heros don't need hard drives
at all.

Someone reinvented STOIC.

I'm not familiar with that, so I looked it up on Google. Here's what
http://stoical.sourceforge.net/summary.php
had to say:
"Moore, though clinically insane, has continued to extend his language
over the years. At the time of this writing FORTH is known to him as
colorForth; One imagines that these colors are much like those present
in his twisted visions and terror filled dreams."

I'm currently looking into an extension/embedding language. Two that
have have cropped up so far are ATLAST and TinyScheme. ATLAST is based
on Forth - so it has all the primitiveness of Forth, but is quite easy
to extend. TinyScheme has all the abstractability of Scheme, but is the
devil's own work to extend (at least by me).

So, there we have it.