On Wed, 13 Jul 2022 08:43:02 -0000 (UTC), Chris <ithinkiam@gmail.com>
wrote:

>> I use very few Microsoft applications (as far as I'm concerned, there
>> are almost always better third-party choices),
>
>At work there's often no choice. You have to go with the lowest common
>denominator.

Yes, at work you have to use what you're given and told to use. I'm
retired and I use what *I* want at home.

>> but those that I've
>> used on Windows, I find to be completely reliable.
>
>Occasional use is not the same as using it as a tool for work. Windows +
>Office often interferes with work.

I use Excel (very slightly) and OneNote. Nothing else in Microsoft
Office.

On 13/07/2022 16:53, Paul wrote:
> On 7/13/2022 5:49 AM, David Brooks wrote:
>
>>
>> Thank you, Paul.
>>
>> That explains much ..... but it doesn't clarify how one can gain
>> access to the PRIVATE group messages on that server.
>>
>> Can you explain how to do that?
>>
>> (You may recall that Microsoft Newsgroups also had private as well as
>> public newsgroups!) http://www.aumha.org/support.htm
>
> I have no idea how to break into anything.
>
> I rely on your safe-cracking skills for this :-)
>
> Good luck.
>
>    Paul

Thanks! :-D

Path: myplugbox.com!.POSTED.67.70.138.100!not-for-mail
From: "Andrew Taylor" <misissauga@spamcop.net>
Newsgroups: user2user
Subject: Re: Message for Mr Dave Higham
Date: Thu, 28 Apr 2016 15:22:39 -0400
Organization: MyPlugBox
Lines: 2
Message-ID: <nftnu7$pbf$1@myplugbox.com>
References: <nfqu6t$5qi$1@myplugbox.com> <nfrbrj$3i2$1@myplugbox.com>
<nfrrk4$ivh$1@myplugbox.com>
Mime-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="Windows-1252";
reply-type=original
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Apr 2016 19:22:47 +0000 (UTC)
Injection-Info: myplugbox.com; posting-host="67.70.138.100";
logging-data="25967"; mail-complaints-to="usenet@myplugbox.com"
In-Reply-To: <nfrrk4$ivh$1@myplugbox.com>
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 16.4.3563.918
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3563.918
Xref: myplugbox.com user2user:725

The very same.

I actually met him and his wife in Devon 2 years ago. He is a nice man,
very
intelligent, but has far to much time on his hands and enjoys conspiracy
theories of his own making. If you met him, you would never think it was
'Boater Dave' if you knew him from his online persona.

Andrew Taylor
Mississauga - Ontario
Canada

=

I KNOW there are secret (private) groups there! WHAT is being hidden?

Maybe it's where the plans for the destruction of the Twin Towers were made.

On 7/12/2022 9:07 PM, Bill W wrote:
> On Jul 12, 2022, mike wrote
> (in article <tal4g7$4959$1@solani.org>):
>
>> On 13-07-2022 05:55 nospam<nospam@nospam.invalid> wrote:
>>
>>> nobody has ever said that.
>>
>> You said "it's hard to be faster than instant" which is ludicrous of you to
>> say without even you knowing Preview is slower than Irfanview.
>
> If one app takes 2ms, and the other takes 1ms, one is twice as fast, but both
> are “instant" to any sane user.
>

Irfanview actually records the time it takes, to load an image.
The information is available under Image:Information.

A 600KB JPG loads in 16 milliseconds.

*******

You can make test files procedurally.
This makes an image with 32768x32768 pixels.
There are four colors available, randomly applied
to the pixels. The # is for commented-out bits.
I chose pnm, as it's easy to make this way.
It was taking GIMP way way too long to do this,
and this actually saved time.

********************************* makepnm.awk ********************************
# function randint(n) {
# return int(n * rand())
# }

# gawk.exe -f makepnm.awk > test.pnm
# press control-z return, for EOF on input

END {
# RS = "/r/n"
printf("P3\n")
printf("\# CREATOR: GIMP PNM Filter Version 1.1\n")
printf("32768 32768\n")
printf("255\n")

for (i=0; i<32768; i++) {
for (j=0; j<32768; j++) {
switch ( int(4 * rand() ) ) {
case 0:
printf("255\n255\n255\n")
break
case 1:
printf("255\n0\n0\n")
break
case 2:
printf("0\n255\n0\n")
break
case 3:
printf("0\n0\n255\n")
}
}
}
} ********************************* makepnm.awk ********************************

Using that image as source material, I made some derivative files.
A pretty crappy selection, but I got bored.

Filename IrfanView Load Time

sample.pnm 12,884,831,950 bytes <=== ASCII PNM, not binary
25265 milliseconds load (about 500MB/sec)

ImageMagick format BMP 3,221,225,620 bytes
593 milliseconds (about 5400MB/sec)

IrfanView format BMP 3,221,225,526 bytes
610 milliseconds

Pseudo-compress PNG 587,556,712 bytes
9562 milliseconds (shoots self in foot!)

Less-compress PNG 3,226,469,201 bytes
8312 milliseconds (still no good)

ImageMagick format GIF 310,448,333 bytes (four colors of 16 color table)
3328 milliseconds (compression is just not a good thing)

Images were stored on a 7000MB/sec RAM drive.

[Picture]

https://i.postimg.cc/ncRF8Jh2/hdtune-ramdrive.gif

The native BMP seems, so far, to be about the best
I can do, as for some of these conversions, I'd need
to spend a lot more time fixing them.

Paul

On 7/13/2022 6:28 AM, Chris wrote:

>
> False. It's dependent on Windows APIs hence why there are no ports for
> linux or macOS.

If you want portability, you can just write in Qt.

The problem with Qt, is the weight of executables.

If you write just using some windows graphics calls,
that can make your code smaller.

Irfan appears to host his own stuff, so would be
paying at least $0.03 per gigabyte of downloads.
If he used sourceforge, then he could go nuts with
the stuff.

In testing a few things here, nothing seems to use
the graphics card for acceleration. It still seems
to be all CPU code. The MP here, presumably refers
to OpenMP library -- you can chop up an image into
eight pieces and open on eight cores.

XnView-win-small.zip 4,823,632 bytes Classic version

XnViewMP-win-x64.zip 116,871,802 bytes Qt version

That's not all the fault of Qt, as some other baggage
got thrown in. I saved out a BMP as a test of the MP one,
and it was malformed. The small one (being 32 bit code),
could not open the file (only 1.8GB address space for the code,
with the normal split), so there was no chance to test
output quality.

BMP seems to be about as compatible as AVI, as a format :-/
But I wanted to try it on various viewers, to see what
the viewing speed range was like.

The best thing about standards, is you can have so many of them.

Paul

In article <tandrc$2fhj2$1@dont-email.me>, Paul <nospam@needed.invalid>
wrote:

> On 7/13/2022 6:28 AM, Chris wrote:
> > False. It's dependent on Windows APIs hence why there are no ports for
> > linux or macOS.
>
> If you want portability, you can just write in Qt.
> The problem with Qt, is the weight of executables.

no, the problem with qt (and other cross-platform frameworks) is the
results are not good, limited to the lowest common denominator of all
platforms, with a non-native feel.

On 9/7/2022 7:17 am, Thomas wrote:
> What is your #1 choice for freeware editing of images, audio & video?
>
> Here are mine with a single reason for each as to why.
> The only restriction is it must be Windows freeware.

Finding a "#1 choice" is totally a waste of time. The most important
thing is to use the right tool for the job, it's never about ranking!

I don't know why the world is so obsessed with ranking and grading,
especially in the fields of finance and banking. It's all about a
pyramid? :)

Paul <nospam@needed.invalid> wrote:
> On 7/13/2022 6:28 AM, Chris wrote:
>
>>
>> False. It's dependent on Windows APIs hence why there are no ports for
>> linux or macOS.
>
> If you want portability, you can just write in Qt.

Or one of the many other portable libraries.

> The problem with Qt, is the weight of executables.

Which is also the point I made in my post, but you snipped.

On 13/07/2022 20:28, David Brooks wrote:
[....]

> I KNOW there are secret (private) groups there! WHAT is being hidden?
>
> Maybe it's where the plans for the destruction of the Twin Towers were
> made.

Paul,

FYI :-D

http://al.howardknight.net/?ID=165779501100

Further advice welcomed.

--
"Will you please advise, for the benefit of all reading here, *HOW* one
may obtain a User Name and Password to access the 'hidden' groups on the
'news.myplugbox.com' newsserver."

On 7/14/2022 6:41 AM, David Brooks wrote:
> On 13/07/2022 20:28, David Brooks wrote:
> [....]
>
>> I KNOW there are secret (private) groups there! WHAT is being hidden?
>>
>> Maybe it's where the plans for the destruction of the Twin Towers were made.
>
> Paul,
>
> FYI :-D
>
> http://al.howardknight.net/?ID=165779501100
>
> Further advice welcomed.

That does sound like a good way to do it

Unauthenticated groups 1,2

Authenticated groups 1,2,3,4,5

That makes more sense than group 3 having one password,
group 4 having another password and so on.

That means, *if* you are given an account, you see 1,2,3,4,5.

Well-run USENET servers, have a web page with the
details of the operation. Such as an email address
to apply for an account.

If the server is a word-of-mouth server, you're
going to need "a friend" to get you in. Someone
has to be your sponsor and vouch for you.

Paul

On 14/07/2022 12:25, Paul wrote:
> On 7/14/2022 6:41 AM, David Brooks wrote:
>> On 13/07/2022 20:28, David Brooks wrote:
>> [....]
>>
>>> I KNOW there are secret (private) groups there! WHAT is being hidden?
>>>
>>> Maybe it's where the plans for the destruction of the Twin Towers
>>> were made.
>>
>> Paul,
>>
>> FYI :-D
>>
>> http://al.howardknight.net/?ID=165779501100
>>
>> Further advice welcomed.
>
> That does sound like a good way to do it
>
> Unauthenticated   groups 1,2
>
> Authenticated     groups 1,2,3,4,5
>
> That makes more sense than group 3 having one password,
> group 4 having another password and so on.
>
> That means, *if* you are given an account, you see 1,2,3,4,5.
>
> Well-run USENET servers, have a web page with the
> details of the operation. Such as an email address
> to apply for an account.
>
> If the server is a word-of-mouth server, you're
> going to need "a friend" to get you in. Someone
> has to be your sponsor and vouch for you.

Thank you so much for commenting, Paul.

If you were to try to access ANY of the groups on 'news.myplugbox.com'
using Thunderbird, would you see this barrier put up before you?

https://imgur.com/gallery/XIegOjU

Please advise. Thank you.

"Paul" <nospam@needed.invalid> wrote

| Using that image as source material, I made some derivative files.
| A pretty crappy selection, but I got bored.
| | Filename IrfanView Load Time
| | sample.pnm 12,884,831,950 bytes <=== ASCII PNM, not
binary
| 25265 milliseconds load (about 500MB/sec)
| | ImageMagick format BMP 3,221,225,620 bytes
| 593 milliseconds (about 5400MB/sec)
| | IrfanView format BMP 3,221,225,526 bytes
| 610 milliseconds
| | Pseudo-compress PNG 587,556,712 bytes
| 9562 milliseconds (shoots self in foot!)
| | Less-compress PNG 3,226,469,201 bytes
| 8312 milliseconds (still no good)
| | ImageMagick format GIF 310,448,333 bytes (four colors of 16 color table)
| 3328 milliseconds (compression is just not a good
thing)
| | Images were stored on a 7000MB/sec RAM drive.
| | [Picture]
| | https://i.postimg.cc/ncRF8Jh2/hdtune-ramdrive.gif
| | The native BMP seems, so far, to be about the best
| I can do, as for some of these conversions, I'd need
| to spend a lot more time fixing them.
| A BMP should be fastest, of course, because the other
formats are storage systems that must be unpacked to
BMP before loading.

Your numbers seem awfully slow, though. Displaying
an image should be virtually instant in all cases. So it
doesn't really matter. (Even nospam is talking sense in
this case. :)

I once set up a test program because I needed to
resize images for an Explorer Bar thumbnail. So any
image needed to display almost instantly when the file
was selected.
I just fired it up to try it out. This is not just loading
and displaying, but loading, doing a resize to a width of 300px,
then displaying. (GDI+ is doing a bicubic resize. The other
two methods don't provide a quality option.)

I used a 12MB JPG, compression quality setting 93. Lots
of detail. It's a photo looking up at autumn leaves in large trees.
The test program is written in VB6. It uses VB6 method,
GDI+ API, and the WIA COM library.

GDI+: 250 ms VB: 1000 ms WIA: 312 ms

So even doing all that it's pretty fast. Load speed wouldn't be
worth measuring. Human perception makes 250 ms pretty much
instant. Loading and painting is maybe 2 ms? Maybe 50? I don't
know. But those are well within the range of instant. Interestingly,
the quality varies quite a bit. VB (probaby wrapping GDI methods)
produces the sharpest image, but slightly too contrasty. GDI+
is pretty good, but a bit blurry. WIA is slightly blurry and also
slightly dark. None do justice to the original.

At one point I needed even faster resizing and found that the
fastest I could come up with was to have turbojpeg resize it to
one of the standard pecentages it will do, then resize it in code
the rest of the way. Which I though was interesting. Even
communicating to an external library had negligible speed effect
compared to the resizing task.

So, moral of the story: Irfan View is obviously by far the best
image viewer, scientifically speaking. But just about anything
can load/paint an image instantly. I fully believe that even Mac
software can do that. :)

In article <tap51g$2njg7$1@dont-email.me>, Mayayana
<mayayana@invalid.nospam> wrote:

> A BMP should be fastest, of course, because the other
> formats are storage systems that must be unpacked to
> BMP before loading.

that depends whether it's cpu or i/o bound.

generally it's faster to read less data and decompress it versus
reading more data. for jpeg, it's roughly a 10-fold difference in size.

"Paul" <nospam@needed.invalid> wrote

| >
| > False. It's dependent on Windows APIs hence why there are no ports for
| > linux or macOS.
| | If you want portability, you can just write in Qt.
| | The problem with Qt, is the weight of executables.
|

Indeed. I'm getting very tired of seeing programs that claim
to be cross platform but are really just Python wrappers
around other crap. Cross-platform, for me, means that they
actually wrote the code to each OS API. A "port" means you
actually bring the program over to another OS, targetting that
OS's API, not that you just code a Python wrapper around
OSS libraries and call it universal software. If I write javascript
in a webpage to call Google maps I could say that's "cross
platform". So what?

I wouldn't be surprised
if Irfan Skildjan is actually writing raw code for all of his
operations. Depends shows he's loading GDI32 but not GDI+.
Which means he has to be doing his own parsing of file bytes
"by hand" for formats and probably only using Windows API
for some basic byte handling operations. The number of formats
he deals with is amazing. IV can even display my RAW images!
Graphic editing operations are almost certainly done by hand, too.
Things like cropping and resizing of a raster image are just math
and the methods that have been developed are shared.

It's interesting that Chris thinks Windows API is a dependency.
In the world of Windows programming, a dependency usually
means something not pre-installed in the OS. My own VB6 software
has no dependencies because I only use libraries built into Windows.
So it just runs. No muss, no fuss, no bloat.

We could say it has a dependency on the VB6 runtime, Windows,
the CPU, the RAM, and so on, but that gets silly. The critical
point is that it runs on the platform without extra add-ins required.
And the VB6 runtime is just a very small wrapper library for basic
API operations.

It's an interesting irony. Apparently the Unix world of Linux and
Mac is so accustomed to using wrapper-infested "ports" that they
think Python, ImageMagick, QT, etc are native API and that Windows
API is a dependency. :)

Mayayana wrote:

> It's interesting that Chris thinks Windows API is a dependency.

It's not really that he thinks that. It's that he couldn't comp up with any
other excuse for why the speed of irfanview for viewing and stepping
through photos isn't available to him on his mac.

> It's an interesting irony. Apparently the Unix world of Linux and
> Mac is so accustomed to using wrapper-infested "ports" that they
> think Python, ImageMagick, QT, etc are native API and that Windows
> API is a dependency. :)

No. He was just grasping for anything he could think of which justified in
his mind the mac not having the image step through speeds of irfanview.

On 14-07-2022 09:41 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote:

> Finding a "#1 choice" is totally a waste of time. The most important
> thing is to use the right tool for the job, it's never about ranking!

I think you are wrong. And I think the answer to this question will show
that you are wrong if you answer that question as honestly as you can.

Would you say irfanview is often the number one photo viewing tool for
people who know how to use Windows and who set it up for themselves?

Your problem is with number 2!

> I don't know why the world is so obsessed with ranking and grading,
> especially in the fields of finance and banking. It's all about a
> pyramid? :)

Installing the wrong free ware will waste a lot of time.
Especially if you have to test them all yourself first.
Searching on the internet will be hit or miss because of the shills.

That's why when it comes to free ware it's important to get advice that
isn't a shill because most shills will lead you astray. It's good to get
advice from users on these internet groups because they're not selling you
software.

On 14-07-2022 18:47 Mayayana <mayayana@invalid.nospam> wrote:

> Your numbers seem awfully slow, though. Displaying
> an image should be virtually instant in all cases. So it
> doesn't really matter.

You are not taking into account the /loading time/ to start the program.

That's usually long for any Adobe or Microsoft or other big-name program.

How long would it take to START any HP image viewing software, for example?

> (Even nospam is talking sense in this case. :)

He's also not taking into account how long it takes to load /multiple/
applications, which is how he suggests the mac owner step through large
folders of images.

On 7/14/2022 8:56 AM, David Brooks wrote:

> Thank you so much for commenting, Paul.
>
> If you were to try to access ANY of the groups on 'news.myplugbox.com'
> using Thunderbird, would you see this barrier put up before you?
>
> https://imgur.com/gallery/XIegOjU
>
> Please advise. Thank you.

If you tick "Always Request Authentication" in the Thunderbird
server settings page, it will prompt like that. And you need
to do that, to become Authenticated.

You cannot see 1,2,3,4,5 unless you enter valid account details.

If you untick the box, then you see 1,2 and there will be no prompt.

USENET protocol uses a "submit" method, rather than a "request" method
for authentication. Nobody at myplugbox asked for that detail,
but if you submit a userid and password, magic things may happen.
That's how the USENET protocol works.

Paul

In article <tapmnq$6onc$1@solani.org>, mike <this@address.is.invalid>
wrote:

>
> > Your numbers seem awfully slow, though. Displaying
> > an image should be virtually instant in all cases. So it
> > doesn't really matter.
>
> You are not taking into account the /loading time/ to start the program.

that's completely insignificant, or just leave it running.

> That's usually long for any Adobe or Microsoft or other big-name program.

it takes a second or two to launch either of those (not worth measuring
with a stopwatch), which is not what anyone would call 'usually long'.

> > (Even nospam is talking sense in this case. :)
>
> He's also not taking into account how long it takes to load /multiple/
> applications, which is how he suggests the mac owner step through large
> folders of images.

stop lying. i never said anything about using multiple applications,
nor is that even needed.

stepping through any size folders of images doesn't need *any* app on a
mac.

On 14-07-2022 13:32 nospam <nospam@nospam.invalid> wrote:

>> You are not taking into account the /loading time/ to start the program.
>
> that's completely insignificant, or just leave it running.

Wrong.
Most image viewing programs are as slow as a lazy old dog when it comes to
opening up for the first time on demand to view an image. Not Irfanview.
Leaving Preview running is what you have to do on your Mac.
Because the Mac multiple program process you suggested is very slow.

You have no idea how incredibly fast Irfanview is on both startup and
stepping through photos. Your Mac Preview is a fat old dog by comparison.

>> That's usually long for any Adobe or Microsoft or other big-name program.
>
> it takes a second or two to launch either of those (not worth measuring
> with a stopwatch), which is not what anyone would call 'usually long'.

You don't know what you're talking about.
You've never experienced the incredible speed of Irfanview.
On startup.
On stepping through any number of images in any number of folders.
On exit.

Your multiple step process on the Mac using Preview is an old fat dog.

>>> (Even nospam is talking sense in this case. :)
>>
>> He's also not taking into account how long it takes to load /multiple/
>> applications, which is how he suggests the mac owner step through large
>> folders of images.
>
> stop lying. i never said anything about using multiple applications,
> nor is that even needed.

On Windows you are going about your business, and then, for whatever
reason, you happen across the need to step into a folder filled to
overflowing with JPEG images from a camera for example.

You doubleclick on any image in that folder and then you spacebar forward
and backspace backward and delete to delete to your hearts content.

Startup on demand (which is how you use it) is incredibly fast.
Tapping 'Spacebar' to load the next image is incredibly fast.
Tapping 'Backspace' to load the previous image is incredibly fast.
Tapping 'Del' to delete the current image is incredibly fast.
Tapping 'Esc' to exit is incredibly fast.

The multiple application process you suggested for a Mac is an old fat dog
compared to the incredibly fast way that Irfanview does this on Windows.
>
> stepping through any size folders of images doesn't need *any* app on a
> mac.

You are ignoring the incredibly fast startup and exit of Irfanview compared
to the old lazy fat dog of Preview where you must keep it running in the
background.

It's the same with most images editing programs which are such old lazy
dogs on startup that you have to keep them running just to make them
usable.

Not Irfanview.

On 7/14/2022 9:17 AM, Mayayana wrote:
> "Paul" <nospam@needed.invalid> wrote
>
> > Using that image as source material, I made some derivative files.
> > A pretty crappy selection, but I got bored.
> >
> > Filename IrfanView Load Time
> >
> > ImageMagick format BMP 3,221,225,620 bytes
> > 593 milliseconds (about 5400MB/sec)
>
> A BMP should be fastest, of course, because the other
> formats are storage systems that must be unpacked to
> BMP before loading.
>
> Your numbers seem awfully slow, though.

I made a purposeful "slow" test case. It contains
one billion pixels.

This is intended to slow down the rendering, so
even a human can "time" the response.

I presented the time for a "regular" JPG as 16 milliseconds.
It would be pretty hard for a user to determine that
their LCD screen advanced to the next frame, before the
picture appeared.

By using a large file, my best time is half a second.
Someone else can then roughly compare their time
and determine whether it is instantaneous or not.
Or whether the time is finite.

I don't particularly care whether one machine is
10% faster at this than some other machine. But
if one machine is orders of magnitude worse, when
doing a taxing test case, that speaks to the software implementation.

If you had done the experiment, you would know
that the information Irfan provides is "cheating".
It does not attempt to sniff the screen and see
if the pixel has appeared yet or not. The Windows Display Manager
could delay the presentation of the image. And that
does appear to be the case. Cases where the "decoding"
took three seconds, the image does not appear on the
screen at the three second mark.

If you zoom in with Irfanview, the image is not as
sharp as if you zoom in with GIMP. Some platforms
present an initial (slightly blurry) image, followed
a second or two later by a sharper image. GIMP isn't
doing that.

Procedurally generated images, makes it easier for
two people remote from one another, to use the same file.
If my file is 3GB, I don't exactly want to put that
as an email attachment.

Paul

In article <tapqgj$6qjd$1@solani.org>, mike <this@address.is.invalid>
wrote:

>
> >> You are not taking into account the /loading time/ to start the program.
> >
> > that's completely insignificant, or just leave it running.
>
> Wrong.

not wrong.

> Most image viewing programs are as slow as a lazy old dog when it comes to
> opening up for the first time on demand to view an image. Not Irfanview.

false. nearly all of them are extremely fast to launch and use.

> Leaving Preview running is what you have to do on your Mac.

nope. it launches instantly, too short to measure, and that's on an
older mac. on a newer mac, it would be even faster.

it's also not needed to step through images, which is the task you
describe.

it's clear you're trolling and trying to move the goalposts each time
you get shot down.

> Because the Mac multiple program process you suggested is very slow.

stop lying. i never suggested a 'multiple program process'.

> You have no idea how incredibly fast Irfanview is on both startup and
> stepping through photos. Your Mac Preview is a fat old dog by comparison.

not only is that demonstrably false, but it's clear that you have no
clue about anything related to macs. you are trolling and intentionally
spewing disinformation.

it's also obvious who you really are.

On 7/14/2022 9:44 AM, Mayayana wrote:

> It's an interesting irony. Apparently the Unix world of Linux and
> Mac is so accustomed to using wrapper-infested "ports" that they
> think Python, ImageMagick, QT, etc are native API and that Windows
> API is a dependency. :)

The purpose of using Qt, is "write once, run anywhere".

It's the same promise as Java, only without having to become
a Java programmer for the rest of it.

It's possible there is one of these based on KDE, and that's
how we can have a kdenlive video editor on Windows. That might
not have been offered, if there wasn't a measure of portability.

FOSS software tends to use OpenGL, because it's available on
all platforms. It could be that the Java stuff was doing that,
but maybe not at first (because my Unix box may not have had
all the stuff needed and I could run the first Java graphics
demo OK). By using OpenGL, they don't have to write three
versions of code, one with DirectX, one with OpenGL, one with
QuartzOrWhatever.

Firefox, in about:support, shows entries for OpenGL and EGL.
And in a VM, you will notice that some of the about:support
is blank there. And it still runs. In some cases, it makes
a decision at load time, what to do and what to use. VBox5
would present different info than VBox6.

In modern times, it's almost impossible to predict exactly
what will be available, and whether something you want to run,
is going to be happy.

LibreOffice uses OpenGL. And the first time I tested Win LO, it
crashed. Why ? The platform OpenGL, lacked a working "memory
remaining" for OpenGL, and it would just... run off the end.
Roughly around the time that Task Manager got a "GPU tab"
showing performance details of the GPU, that is when a working
OpenGL "memory remaining" finally showed up. The video card
companies had whined "we cannot rewrite this routine fast
enough to keep up with Microsoft changes". That was their
excuse for the call being missing or returning bogus info.

Paul

On 15-07-2022 01:12 nospam <nospam@nospam.invalid> wrote:

> it's also not needed to step through images, which is the task you
> describe.

What? Are you nuts? There's something wrong with anyone who says that.
What kind of person would say stepping through images is "not needed?"

In article <tapthj$6s1o$1@solani.org>, mike <this@address.is.invalid>
wrote:

>
> > it's also not needed to step through images, which is the task you
> > describe.
>
> What? Are you nuts? There's something wrong with anyone who says that.
> What kind of person would say stepping through images is "not needed?"

read it all again, this time for comprehension.

Mayayana <mayayana@invalid.nospam> wrote:
> "Paul" <nospam@needed.invalid> wrote
>
> | >
> | > False. It's dependent on Windows APIs hence why there are no ports for
> | > linux or macOS.
> |
> | If you want portability, you can just write in Qt.
> |
> | The problem with Qt, is the weight of executables.
> |
>
> Indeed. I'm getting very tired of seeing programs that claim
> to be cross platform but are really just Python wrappers
> around other crap. Cross-platform, for me, means that they
> actually wrote the code to each OS API. A "port" means you
> actually bring the program over to another OS, targetting that
> OS's API, not that you just code a Python wrapper around
> OSS libraries and call it universal software. If I write javascript
> in a webpage to call Google maps I could say that's "cross
> platform". So what?

Simply different implementations to achieve similar results. They require
different amounts of effort.

Actually many apps are now written in javascript for portability. Such as
Microsoft's VS Code is written in Typescript (an extension if javascript).

> It's interesting that Chris thinks Windows API is a dependency.

It's obvious isn't it? It requires the windows API hence why it requires
WINE in order to run on linux or macos.

If it didn't then it wouldn't be a dependency.

> In the world of Windows programming, a dependency usually
> means something not pre-installed in the OS. My own VB6 software
> has no dependencies because I only use libraries built into Windows.
> So it just runs. No muss, no fuss, no bloat.
>
> We could say it has a dependency on the VB6 runtime, Windows,
> the CPU, the RAM, and so on, but that gets silly. The critical
> point is that it runs on the platform without extra add-ins required.
> And the VB6 runtime is just a very small wrapper library for basic
> API operations.
>
> It's an interesting irony. Apparently the Unix world of Linux and
> Mac is so accustomed to using wrapper-infested "ports" that they
> think Python, ImageMagick, QT, etc are native API and that Windows
> API is a dependency. :)

More evidence that you don't know what you're talking about.