Paint.Net

  • Thread starter Thread starter Saxman
  • Start date Start date
Saxman said:
For those of you into graphics, the final version is here.

http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Editors/Paint-NET.shtml
Click to expand...

The home page for the program is here:

http://www.eecs.wsu.edu/paint.net/

It's always better to give the real home page for a program if it's
available.

--
Regards from John Corliss
I don't reply to trolls like Andy Mabbett or Doc, for instance. No
adware, cdware, commercial software, crippleware, demoware, nagware,
PROmotionware, shareware, spyware, time-limited software, trialware,
viruses or warez for me, please.
 
On that special day, Bexko Nandu, ([email protected]) said...
Don't use M$'s .NET!
We should boycott that crap!
Click to expand...

Sorry, but this is the new framework (script?) language for Windows,
and there will be no way around it, eg for ATI driver users. You'll
have to get used to it, like ActiveX or DirectX. Can you imagine, how
one might boycott DirectX? This would mean, your computer wouldn't be
able to run I don't know how many programs. It will be the same with
..NET


Gabriele Neukam

(e-mail address removed)
 
Gabriele Neukam wrote:
[SNIP]
Sorry, but this is the new framework (script?) language for Windows,
and there will be no way around it, eg for ATI driver users. You'll
have to get used to it, like ActiveX or DirectX. Can you imagine, how
one might boycott DirectX? This would mean, your computer wouldn't be
able to run I don't know how many programs. It will be the same with
.NET
Click to expand...
Just to expand and correct a little - .NET is just M$ variant of Java.
It is _not_ a scripting language, it is a run-time interpreter, just
like Java, but without the "architecture neutral" features of Java.

It is theoretically possible to take the bytecode of a .NET program and
translate it into the equivalent Java bytecode, and vice-versa. (Well,
it may not be possible in the real world, but those who spend their
lives staring deep inside programs say there is a distinct similarity
between the two.)

Bur, Gabriele is correct, those (including me) who use Windows will have
to eventually accept .NET, and install its bloated malevolence on their
machines.

If it helps, just think of it as an incredibly large version of a VB DLL.

Cheers,
Gary B-)
 
Gary R. Schmidt written:
It is _not_ a scripting language, it is a run-time interpreter, just
like Java, but without the "architecture neutral" features of Java.
Click to expand...

Would this mean that somebody could write a Linux or Mac OS X version of
the "interpreter" and thus run .NET applications on non-Windows
platforms?
 
Renan said:
Gary R. Schmidt written:
Click to expand...

Actually .net is JITed, not interpreted, which means that after the first
run, you get a TRUE machine code program, and optimized for the processor
architecture you are running it. (one of the several advantages it has over
Java).
 
Renan said:
Gary R. Schmidt written:



Would this mean that somebody could write a Linux or Mac OS X version of
the "interpreter" and thus run .NET applications on non-Windows
platforms?
Click to expand...
In a word - Yes.

Cheers,
Gary B-)
 
Bur, Gabriele is correct, those (including me) who use Windows will have
to eventually accept .NET
Click to expand...

Why? There are plenty of great freeware programs that don't use .NET. So
far, the .NET-dependent programs seem like a minority. I'm not ready to
throw in the towel just yet. I say, POWER TO THE ANTI-BLOAT SEGMENT OF OUR
POPULATION!
 
Why? There are plenty of great freeware programs that don't use .NET. So
far, the .NET-dependent programs seem like a minority. I'm not ready to
throw in the towel just yet. I say, POWER TO THE ANTI-BLOAT SEGMENT OF
OUR
POPULATION!
Click to expand...

Well, define bloat please. I don't see the bloat in .net at all. It is a
beautifully designed API that has the elegancy of Delphi's VCL library (.NET
and Delphi share the same father) and that contains powerful libraries for
almost *everything* a programmer needs. I use it for asp.net applications
and it's a very good thing (TM). The only think I don't like about t is
garbage collection, but I believe managed code is a very good solution to
many problems and bugs in every program. The future (unfortunatly for me,
that do not like it) belongs to managed code.
 
Luis said:
Actually .net is JITed, not interpreted, which means that after the first
run, you get a TRUE machine code program, and optimized for the processor
architecture you are running it. (one of the several advantages it has over
Java).
Click to expand...
Java does the JIT thing, and has for a few years.

Cheers,
Gary B-)
 
jacaranda said:
@paranoia.mcleod-schmidt.id.au:




Why? There are plenty of great freeware programs that don't use .NET. So
far, the .NET-dependent programs seem like a minority. I'm not ready to
throw in the towel just yet. I say, POWER TO THE ANTI-BLOAT SEGMENT OF OUR
POPULATION!
Click to expand...
Because MS will move things to the .NET APIs, and only add functionality
via the .NET APIs, so that people who code for Windows will start using
them, because they have to.

Unless, of course, they chose to move to something else, the list of
free Operating Systems does not just consist of Linux, there is Solaris,
the various BSDs, and so forth. If you drop the x86 peecee from the
picture, there is even more choice.

Cheers,
Gary B-)
 
Gary R. Schmidt said:
Java does the JIT thing, and has for a few years.
Click to expand...


Yes, but there is a difference. The .net compilers produce
intermediate code like Java, but after the first run-time, it produce
**optimized** native binary code. What is different is that .NET
offers the potential to precompile a .NET application to native code,
whereas no well-known Java environment provides that same option.

Also another difference if that .NET is an open platform and language
independent. Everyone can do a language that is .net compatible and
interact with other components in any other .Net language. /Common
Language runtime /
 
Luis said:
Yes, but there is a difference. The .net compilers produce
intermediate code like Java, but after the first run-time, it produce
**optimized** native binary code. What is different is that .NET
offers the potential to precompile a .NET application to native code,
whereas no well-known Java environment provides that same option.
Click to expand...
I should be charging you consulting rates - have a look at the GNU
Compiler for Java - please don't claim that _that_ is not well known.
Also another difference if that .NET is an open platform and language
independent. Everyone can do a language that is .net compatible and
interact with other components in any other .Net language. /Common
Language runtime /
Click to expand...
Some of us have been interfacing different languages for decades - I
know that some newbies think it's a recent development, but really, it
isn't. I've worked on projects where we were using Pascal, Fortran, C,
and Assembler, all on the same hardware and interfacing to each other
via API[1], and no doubt others have similar stories.

And, of course, you _can_ interface other languages into Java, it's just
a case of RTFM.

Please note that I do not think Java is the best thing since sliced
bread, it's just another language, I just get offended by the spread
disinformation, whether deliberate, or through simple ignorance. Of
course, if the ignorance is _wilful_, that is an entirely different thing.

Cheers,
Gary B-)

1. Okay, it was under VMS, so those who know their Operating Systems
will realise that it was fairly simple.
 
Gary R. Schmidt said:
Some of us have been interfacing different languages for decades - I know
that some newbies think it's a recent development, but really, it isn't.
I've worked on projects where we were using Pascal, Fortran, C, and
Assembler, all on the same hardware and interfacing to each other via
API[1], and no doubt others have similar stories.
Click to expand...


Of course interfacing different languages has been possible for ages, I
write my Dlls in C++ and they talk to my Delphi programs without problems
via APIs LoadLibrary - GetProcedureAddress and all that jazz, but this is
different to the way .net works. In dotnet there is a Common Language
Runtime (CLR). The Common Language Runtime is the substrate that abstracts
the underlying operating system from your code, so you don't need to think
anymore about language dependient type (an string in classic passcal (not
Delphi) was not compatible with null terminated strings or VB strings, for
example). You don't need to think anomorre about calling conventions,
stdcalls, fastcalls etc. That means that if I compile a assembly with VB for
..NET, I can use it DIRECTLY in my C# program. So there is a difference,.
 
Luis said:
Some of us have been interfacing different languages for decades - I know
that some newbies think it's a recent development, but really, it isn't.
I've worked on projects where we were using Pascal, Fortran, C, and
Assembler, all on the same hardware and interfacing to each other via
API[1], and no doubt others have similar stories.
Click to expand...



Of course interfacing different languages has been possible for ages, I
write my Dlls in C++ and they talk to my Delphi programs without problems
via APIs LoadLibrary - GetProcedureAddress and all that jazz, but this is
different to the way .net works. In dotnet there is a Common Language
Runtime (CLR). The Common Language Runtime is the substrate that abstracts
the underlying operating system from your code, so you don't need to think
anymore about language dependient type (an string in classic passcal (not
Delphi) was not compatible with null terminated strings or VB strings, for
example). You don't need to think anomorre about calling conventions,
stdcalls, fastcalls etc. That means that if I compile a assembly with VB for
.NET, I can use it DIRECTLY in my C# program. So there is a difference,.
Click to expand...
Not really.

On VMS, I would just set the compilation flags to say that, for example,
all strings are passed as "counted byte strings by reference", all
floating-point numbers as Type-G, all integers as 32-bit, etcetera,
etcetera, etcetera.

All those switches are the same for each language compiler (but don't
ask me to recall them), so, really, I'd just set the COMMON_FLAGS in a
Makefile to have them all and set CFLAGS/PFLAGS/MFLAGS/FFLAGS/etcetera
to include $COMMON_FLAGS and it all works.

The programmer does not need to know that their module is being passed
Type-G floats rather than Type-F, or whatever the default is for the
language that are writing in, it's all handled behind the scenes.

Cheers,
Gary B-)
 
Well, define bloat please.
Click to expand...

Most of the programs I use are close to 1 MB in size. I don't remember the
exact size of .NET, but I remember it was WAY to big for me to want to
download!
 
Because MS will move things to the .NET APIs, and only add
functionality via the .NET APIs, so that people who code for Windows
will start using them, because they have to.
Click to expand...

Well, I'll just choose to live in denial. ;)

Most of the programs I like are from authors who respect the need for small
programs that are at least halfway "green".
 
Luis said:
<snipped >

Well, you are actually agreeing with me then :-)
Click to expand...
Was I?

I have no idea, and neither does anyone else, as you have snipped all
context. I'll look up my message and see what it says...

No, I'm not.

Cheers,
Gary B-)
 
Back
Top