Possible new feature for next Photoshop

On 11/6/11 PDT 12:11 PM, Ray Fischer wrote:
Pete wrote:

You should realize that that backwards compatibility comes at a price.
Higher prices and lower performance.

Windows has both.

The subject is the Intel processor. Having trouble staying focussed?

Funny: Not according to the subject line.

On 06 Nov 2011 20:12:23 GMT, (Ray Fischer) wrote:

J. Clarke wrote:
says...
On 2011-10-23 03:04:19 +0100, Ray Fischer said:
Pete A wrote:
On 2011-10-14 21:17:04 +0100, Charles E. Hardwidge said:

[...]
Microsoft made a huge deal out of dropping 16 bit support in 64 bit OS, and
after reading through the (junior) development team's report explaining why
spotted where they'd made some mistakes. The reality is they just weren't
capable enough to figure out how to do it and the clock was ticking.

Money, money, money.

Exactly. Intel CPUs maintain 16-bit emulation mode available for any
_competent_ OS designer to support. The fact that most hardware vendors
no longer provide a floppy disk drive does not mean the CPU is
incapable of running 16-bit DOS programs. To me, this shows an
incredible feat of backwards compatibility engineering by Intel and the
incredible level of incompetence of some OS vendors.

You should realize that that backwards compatibility comes at a price.
Higher prices and lower performance.

Windows has both.

I'd like to know who is making faster cheaper processors today by
sacrificing backwards compatibility.

Notice that Intel isn't able to compete in the mobile market.

... which is dominated by ARM.

Regards,

Eric Stevens

On 2011-11-06 20:11:23 +0000, Ray Fischer said:

Pete A wrote:
On 2011-10-23 03:04:19 +0100, Ray Fischer said:

Pete A wrote:
On 2011-10-14 21:17:04 +0100, Charles E. Hardwidge said:

[...]
Microsoft made a huge deal out of dropping 16 bit support in 64 bit OS, and
after reading through the (junior) development team's report explaining why
spotted where they'd made some mistakes. The reality is they just weren't
capable enough to figure out how to do it and the clock was ticking.

Money, money, money.

Exactly. Intel CPUs maintain 16-bit emulation mode available for any
_competent_ OS designer to support. The fact that most hardware vendors
no longer provide a floppy disk drive does not mean the CPU is
incapable of running 16-bit DOS programs. To me, this shows an
incredible feat of backwards compatibility engineering by Intel and the
incredible level of incompetence of some OS vendors.

You should realize that that backwards compatibility comes at a price.
Higher prices and lower performance.

Windows has both.

The subject is the Intel processor. Having trouble staying focussed?

Oh, I see, the Intel processor is a possible new feature for next
Photoshop. Do you mean "Buy Photoshop and get a free Intel CPU" or
"Photoshop no longer crashes on Intel CPUs"?

On Fri, 11 Nov 2011 20:32:40 -0600, John Turco
wrote:

Eric Stevens wrote:

On Wed, 26 Oct 2011 18:05:26 -0500, John Turco
wrote:

edited for brevity

In November of 2010, I made an online purchase of the OEM version of
Corel "Paint Shop Pro Photo XI" -- and it cost me a whopping $9.00
USD! I have no no need nor desire for the pricey Photoshop, as PSP
is nearly as powerful (while being far easier to use), and has been
my main graphics program since 1998.

Paintshop Pro XI. Minimum requirements Windows 2000 or XP. No wonder
that in 2010 you paid $9 for an OEM version!

It's 2006 software, running on 2001 hardware. I'm always five years
behind the times, it seems.

Have you tried getting support?

Regards,

Eric Stevens

No (it's OEM, recall), and why should I? Only real problem is
my archaic PC (homemade Pentium PIII), which I've lomg been
planning to supplant. Whenever I do so, PSP XI will run just
fine.

Well, I'm further up the food cahin than you and can tell you that
Paint Shop Pro X4 is miles ahead. So too is an Intel i7 processor.

Regards,

Eric Stevens

Ryan McGinnis wrote:
On Tue, 1 Nov 2011, Wolfgang Weisselberg wrote:

I asked if you'd ever worked at a large software company.

I've never worked for Microsoft, no. But they also make hardware,
so they wouldn't count as a software company, I guess.

Should I take
this as a no? I asked because you seemed to feel extremely familiar with
Adobe's testing and debugging procedures. I doubt this is the case.

Have *you* ever worked in a position where you were privy to
the testing procedures of software that was mission critical?

Let's take your answer as a resounding "NO! I, Ryan, have never
been in a position where I could observe testing procedures for
mission critical software".

I'm going to just assume that you've never worked at a large software
comapny, since you refuse to answer the question.

I worked at a 5000 people company dealing in software (I created
software there) and I worked at a huge multinational in a division
that rents servers including monitoring services in a 'you worry
about nothing' model.

I have no idea *how* e.g. Microsoft "tests" their products, but
I can plainly see the results, when at times crashes happen even
in a well rehearsed stage demonstration by Bill.

This is relevant info, given the somewhat cynical claims that you've made
about how little
testing or development is done on Adobe's software packages.

If you went back and actually read what I said instead of
knee yerking ... ah well, won't happen anyway.

You are, of
course, entitled to your own opinions, but it's useful to know that
your opinions aren't really based in personal experience,
especially considering that
you provided no external support for your assertions.

So what exactly is your personal experience? Let's guess: you
once beta-tested, ah, let me correct that, used a beta-version
of a random software product. Maybe you even reported a bug.

-Wolfgang

On Sun, 20 Nov 2011 20:01:53 -0600, John Turco
wrote:

Eric Stevens wrote:

On Fri, 11 Nov 2011 20:32:40 -0600, John Turco
wrote:

Eric Stevens wrote:

On Wed, 26 Oct 2011 18:05:26 -0500, John Turco
wrote:

edited for brevity

In November of 2010, I made an online purchase of the OEM version of
Corel "Paint Shop Pro Photo XI" -- and it cost me a whopping $9.00
USD! I have no no need nor desire for the pricey Photoshop, as PSP
is nearly as powerful (while being far easier to use), and has been
my main graphics program since 1998.

Paintshop Pro XI. Minimum requirements Windows 2000 or XP. No wonder
that in 2010 you paid $9 for an OEM version!

It's 2006 software, running on 2001 hardware. I'm always five years
behind the times, it seems.

Have you tried getting support?

Regards,

Eric Stevens

No (it's OEM, recall), and why should I? Only real problem is
my archaic PC (homemade Pentium PIII), which I've lomg been
planning to supplant. Whenever I do so, PSP XI will run just
fine.

Well, I'm further up the food cahin than you and can tell you that
Paint Shop Pro X4 is miles ahead. So too is an Intel i7 processor.

Regards,

Eric Stevens


7 is my favorite Paint Shop Pro version, because it's so quick and
intelligently designed. It was a Jasc product, before Corel bought
the program.

Corel's PSP XI boasts certain, more advanced features than PSP 7
does...which is why I continue tolerating the former's lethargy
(partly due to its database function) and maddening quirks. It's
"bloatware" of the worst order!

I suspect your computer is at fault - too slow.

Regards,

Eric Stevens

Pete A wrote:
On 2011-11-01 18:49:41 +0000, Wolfgang Weisselberg said:

Pete A wrote:
[...]
Now you have digressed from secure OSs.

Which was never the topic. The topic was your dream of a
world where only Microsoft Windows will run.

Rubbish: read my posts and you'll see that since I retired after making
loads of money from MS systems, I no longer have to use them. Bliss :-)
My Usenet client alone should've made that obvious to you, duh!

Since you insist on naming unimportant systems, MS Windows and
Mac and OS/half and so on, since they also use a centralized,
no-user-servicable-parts business model.

[more ******** removed]

By the way, Pascal strings are NOT packed arrays of char - you would
know this if you had ever used the language.

Would you kindly tell me what strings are per ISO 7185?

Your inability to understand the essence of my posts is priceless.

The essence of your post is that Linux isn't important and
that developers and power users should just become vendors.

And that the definition of Pascal is irrelevant to Pascal.

The first element of a traditional Pascal string is the length
indicator - hardly a "packed array of char" is it?

Strings must be of fixed length:

var string: packed array [1..50] of char;

is all nice and dandy , and yes, you can make a data type that
also has a length indicator

type string = record
len: integer;
str: packed array [1..100] of char;
end;

, but that's as much part of Pascal as a data type representing
a chess board and all possible moves thereon.


BTW, C doesn't have a string data type. But it does
handle variable length data much easier than:

type
blkptr = ^block;
block = record
next: blkptr;
data: packed array [1..10] of char
end;

var p: blkptr;

{ allocate string in terms of blocks }

procedure alcblk(var p: blkptr; { returns string allocated }
l: integer); { length of string }
var t: blkptr;
begin
p := nil; { clear result list }
while l 0 do begin { allocate blocks }
new(t); { get new block }
t^.next := p; { link into list }
p := t;
l := l-10 { count that block }
end
end;


{ get character from string }

function getblk(p: blkptr; { string to fetch character from }
i: integer); { index to get character from }
: char; { returns character from index }
begin
while i 10 do
begin p := p^.next; i := i-10 end; { index proper block }
getblk := p^.data[i] { return resulting character }
end;

{ place string character }
procedure putblk(p: blkptr; { string to put character to }
i: integer; { index to put character to }
c: char); { character to place }
begin
while i 10 do
begin p := p^.next; i := i-10 end; { index proper block }
p^.data[i] := c { place character }
end;

(and yes, I copied that from
http://www.moorecad.com/standardpascal/pascalfaq.html)

Had you advanced to
the stage of writing "Hello World." in Pascal you would've known that.

And if you reached that stage, you'd understand the difference
between a fixed length buffer and the length of a string.

The enhanced Pascal strings to encompass Unicode;

doesn't matter.
Aren't Pascal strings.

compatibility with C
function calling;

doesn't matter.
C strings don't have a length indicator, BTW, so Pascal strings
cannot have one either, by your logic.

copy-on-write semantics for efficiency in memory
management;

doesn't matter.
COW doesn't depend on any data type, much less it's specific
implementation. Heck, I do partition snapshots using COW.

passing by reference instead of a copy or pointer

doesn't matter.
You did know that a pointer *is* a reference (though not
every reference need be a pointer)?

means
that the storage container cannot possibly be a "packed array of char"
or WideChar as they are in C.

Thanks for the belly laugh.

Negative offsets into the storage
(inacessible to the programmer) are used to manage these enhanced
reference-counted strings via a memory management system that paved the
way to some of the languages we have now. There is nothing in the C
runtime libraries that can hold a candle to at least two breeds of
modern Pascal.

So no standard Pascal, but some hacked up version.

BTW, did you know that you can extend the C libraries ---
and that people have done that?


Type libraries are a classic example of the limitation of C and C++ in
supporting only static construction of objects. COM and COM+ exemplify
this limitation with their idiotic error-prone complexity, incessant
need for updates and resulting system incompatibilities. I.e.
application updates usually require corresponding (though incompatible)
system updates. It results in both "DLL Hell" and type library hell.
Object Pascal was dynamic from its inception and rarely suffers from
these horrendous problems.

Q1: Is it possible to write a Pascal compiler in C?
Q2: If so, why should it be impossible to import worthy ideas of
Pascal into C?
Q3: Is your world indeed limited to C and C++ and Pascal?

If you knew the bare-bones of fundamental computer programming right
through to complex systems engineering you would not have made the
catalogue of errors in your posts.

Ah, yes, I should have known that COW only works with Pascal
strings. But you, actually "knowing" Pascal, do know better,
of course.


Furthermore, any Pascal
that allows the copy in your example is not using an extension, it is
using a broken compiler :-)

Read
http://www.lysator.liu.se/c/bwk-on-pascal.html

Then kindly start rewriting all the system tools in Pascal,
just for fun.

Again, start from Computer Programming 101: you obviously dived into
computing without understanding the basic essentials.

Ah, yes, the difference between buffer length and data
length. Or that COW thingie.

No, don't give me
your CV because you've already shown it for what it is. I have never
employed an argumentative git.

What powerful potent drug mix did you take to think I would *want*
to be employed by you?
- You've got a chip on his shoulder the size of the Statue
of Liberty.
- You won't argue your position from the definition of
Pascal, when the topic is about the very same thing.
- Your vision is limited to the tiny world you know. (You've
never considered e.g. Ada for OSses, for example.)
- You're an argumentative git.
- Why should I *want* to use something as limited as Pascal?


Had you learnt from the ground up, then decades later read "Advanced
C++. Programming Styles and Idioms.", you would not be making yourself
look like an ass now.

If I wanted to become narrow minded, I'd had learned 'from
the ground up' (i.e. data entry instead of computer science)
in the 50's, never updated that knowledge and read "Advanced C++.
Programming Styles and Idioms." as my first book in ages half
a year ago.

Fortunately, I went a quite different way.


Asking me to explain strings in terms of ISO 7185 is as stupid as me
asking you to explain your computer in terms of BS 1363.

Well, the latter is very easy: "If I really wanted to plug in my
computer in GB, I'd need one of those". The former just happens
to define Pascal.

-Wolfgang

[]
As a hypothetical example, in the thumbnail folders view (left
pane), PSP XI would show this laughable sequence:

Folder 1
Folder 10
Folder 11
Folder 12
Folder 13
Folder 14
Folder 15
Folder 16
Folder 2
Folder 3
Folder 4
Folder 5
Folder 6
Folder 7
Folder 8
Folder 9
[]
--
Cordially,
John Turco

You may be able to fix that - see whether this helps:

http://support.microsoft.com/kb/319827

Cheers,
David

On Thu, 22 Dec 2011 02:35:11 -0600, John Turco
wrote:

Eric Stevens wrote:

On Sun, 20 Nov 2011 20:01:53 -0600, John Turco
wrote:

heavily edited for brevity

7 is my favorite Paint Shop Pro version, because it's so quick and
intelligently designed. It was a Jasc product, before Corel bought
the program.

Corel's PSP XI boasts certain, more advanced features than PSP 7
does...which is why I continue tolerating the former's lethargy
(partly due to its database function) and maddening quirks. It's
" bloatware" of the worst order!

I suspect your computer is at fault - too slow.

Regards,

Eric Stevens


It is a relative snail, undeniably. Nevertheless, that scarcely
excuses Corel's imbecilic programming flaws.

As a hypothetical example, in the thumbnail folders view (left
pane), PSP XI would show this laughable sequence:

Folder 1
Folder 10
Folder 11
Folder 12
Folder 13
Folder 14
Folder 15
Folder 16
Folder 2
Folder 3
Folder 4
Folder 5
Folder 6
Folder 7
Folder 8
Folder 9

Now, here's PSP 7's proper interpretation:

Folder 1
Folder 2
Folder 3
Folder 4
Folder 5
Folder 6
Folder 7
Folder 8
Folder 9
Folder 10
Folder 11
Folder 12
Folder 13
Folder 14
Folder 15
Folder 16

[The above is only a minor nuisance, compared to PSP XI's
more serious defects.]

I currently have version 14.1.0.5 which does not seem to do that at
all.

Regards,

Eric Stevens

On 22/12/2011 09:33, Eric Stevens wrote:
On Thu, 22 Dec 2011 02:35:11 -0600, John
wrote:

Eric Stevens wrote:

On Sun, 20 Nov 2011 20:01:53 -0600, John
wrote:

heavily edited for brevity

7 is my favorite Paint Shop Pro version, because it's so quick and
intelligently designed. It was a Jasc product, before Corel bought
the program.

I don't have PSPro 7 does it still use the IJG codec?

If you are kind enough to send me a small test image compressed with it
at nominal 50 compression level I can tell (black cat in a coal cellar
will do I am only interested in the headers).

Does it allow altering the chroma subsampling in that version?

Regards,
Martin Brown