Why does Wikipedia keep begging for foreign fonts?

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
Bill in Co wrote:
J. P. Gilliver (John) wrote:

I think I missed your response on this one, John:
[]
I thought you liked the older versions, like me? :-) FF11?? What's
so
good about the newer FF11? (I still have version FF ver 3.5 installed).

I too was (am) uneasy about Firefox's upgrade rate (though it seems to
have stopped for a moment - I just checked, and 11.0 is still up to
date; AFAICR, it's been 11 for some time). Trouble is, I could never see
an obvious point at which to stop it upgrading, and now am reluctant to
go back, lest something (and yes, I don't know what!) I've grown used to
working.

You also might consider Pale Moon, which was coded for Windows, and
not a bunch of OS's as is FF. At any rate, Pale Moon seems quicker
to load for me.


Yes, I keep hearing of it, mostly from people who're happy with it (or,
it might be that it's always the same person, possibly you!). It's just
lethargy on my part, and reluctance to learn (however small the
differences) yet another browser.

Pale Moon IS essentially Firefox, but it is compiled *only* for windows.
You can read more about it before taking the mini-plunge (although I
hesitate to call it much of a plunge). Lots of comments on it are in
cnet.com and fileforum.com.

I've been using Pale Moon in place of Firefox for most all of my "non-IE"
web browsing. But I'm still mostly using IE.

(you can have them both (Pale Moon and Firefox) installed if you want. (and
I still do, but NOT version 11, of anything :-)

In message , Bill in Co
writes:
[]
Pale Moon IS essentially Firefox, but it is compiled *only* for windows.
[]
(a) But surely when they compile Firefox for Windows, it doesn't get
other code? (b) even if it does, does that do anything other than at
worst slow it down (and I haven't really noticed anything particularly
slow about it)?

(you can have them both (Pale Moon and Firefox) installed if you want. (and
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

.... current law enforcement approaches to stem the flow of drugs only manage
to seize about one per cent of the drug imports... - Professor David Nutt (31
July-6 August 2010)

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
[]
Pale Moon IS essentially Firefox, but it is compiled *only* for windows.
[]
(a) But surely when they compile Firefox for Windows, it doesn't get
other code? (b) even if it does, does that do anything other than at
worst slow it down (and I haven't really noticed anything particularly
slow about it)?

As I understood it, it was specifically designed and compiled for Windows,
so that no other or extra (perhaps some generic code) was added or used that
would be needed for some other OS's. But I don't know the details. Does
that make any sense (granted, it would help if I knew a bit more about it
:-)

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
[]
Pale Moon IS essentially Firefox, but it is compiled *only* for windows.
[]
(a) But surely when they compile Firefox for Windows, it doesn't get
other code? (b) even if it does, does that do anything other than at
worst slow it down (and I haven't really noticed anything particularly
slow about it)?

As I understood it, it was specifically designed and compiled for Windows,
so that no other or extra (perhaps some generic code) was added or used that
would be needed for some other OS's. But I don't know the details. Does
that make any sense (granted, it would help if I knew a bit more about it
:-)


I can see that _might_ make it a bit more efficient: as to whether it
makes it behave any differently, other than perhaps faster (though as
I've said I'm not aware of the browser itself being slow anyway), that
would depend on whether the "generic" code does anything that isn't
actually required.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

.... current law enforcement approaches to stem the flow of drugs only manage
to seize about one per cent of the drug imports... - Professor David Nutt (31
July-6 August 2010)

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
[]
Pale Moon IS essentially Firefox, but it is compiled *only* for
windows.
[]
(a) But surely when they compile Firefox for Windows, it doesn't get
other code? (b) even if it does, does that do anything other than at
worst slow it down (and I haven't really noticed anything particularly
slow about it)?

As I understood it, it was specifically designed and compiled for
Windows,
so that no other or extra (perhaps some generic code) was added or used
that
would be needed for some other OS's. But I don't know the details.
Does
that make any sense (granted, it would help if I knew a bit more about it
:-)


I can see that _might_ make it a bit more efficient: as to whether it
makes it behave any differently, other than perhaps faster (though as
I've said I'm not aware of the browser itself being slow anyway), that
would depend on whether the "generic" code does anything that isn't
actually required.

Well, Pale Moon loads ("boots up") considerably quicker than Firefox, at
least over here. In that sense, it acts like a lighter version of FF.
If the generic code is less streamlined than code written specifically for
windows, I can see how that could make the difference.

An analogy, albeit a perhaps weak one, would be to compare programs written
directly in Assembler, VS those resulting from the compiled, higher level
languages, like C (or even much worse, Basic, Cobol, Pascal, etc). There
is no question in terms of efficiency - and speed. (That said, I can't
imagine someone coding all of Microsoft Word in Assembler, but if they did,
it would load up and run at lightning speed, LOL). And you could probably
even run it comfortably on a 50 or 100 MHz CPU. :-)

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
[]
I can see that _might_ make it a bit more efficient: as to whether it
makes it behave any differently, other than perhaps faster (though as
I've said I'm not aware of the browser itself being slow anyway), that
would depend on whether the "generic" code does anything that isn't
actually required.

Well, Pale Moon loads ("boots up") considerably quicker than Firefox, at
least over here. In that sense, it acts like a lighter version of FF.

Yes, loading time might be somewhere where the difference would be
noticeable. I usually load Firefox while I'm doing something else, but
the odd time I forget, the time to load _is_ very noticeable.

If the generic code is less streamlined than code written specifically for
windows, I can see how that could make the difference.

An analogy, albeit a perhaps weak one, would be to compare programs written
directly in Assembler, VS those resulting from the compiled, higher level
languages, like C (or even much worse, Basic, Cobol, Pascal, etc). There
is no question in terms of efficiency - and speed. (That said, I can't
imagine someone coding all of Microsoft Word in Assembler, but if they did,
it would load up and run at lightning speed, LOL). And you could probably
even run it comfortably on a 50 or 100 MHz CPU. :-)

Indeed (-:! Increases in processor power have definitely encouraged
drops in compiler efficiency (and the willingness to code for
efficiency). Wasn't DOS 3.3 the last one mostly coded in assembler?

--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

"Look, if it'll help you to do what I tell you, baby, imagine that I've got a
blaster ray in my hand." "Uh - you _have_ got a blaster ray in your hand." "So
you shouldn't have to tax your imagination too hard." (Link episode)

J. P. Gilliver (John) wrote:
In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
[]
I can see that _might_ make it a bit more efficient: as to whether it
makes it behave any differently, other than perhaps faster (though as
I've said I'm not aware of the browser itself being slow anyway), that
would depend on whether the "generic" code does anything that isn't
actually required.

Well, Pale Moon loads ("boots up") considerably quicker than Firefox, at
least over here. In that sense, it acts like a lighter version of FF.

Yes, loading time might be somewhere where the difference would be
noticeable. I usually load Firefox while I'm doing something else, but
the odd time I forget, the time to load _is_ very noticeable.

If the generic code is less streamlined than code written specifically
for
windows, I can see how that could make the difference.

An analogy, albeit a perhaps weak one, would be to compare programs
written
directly in Assembler, VS those resulting from the compiled, higher level
languages, like C (or even much worse, Basic, Cobol, Pascal, etc).
There
is no question in terms of efficiency - and speed. (That said, I can't
imagine someone coding all of Microsoft Word in Assembler, but if they
did,
it would load up and run at lightning speed, LOL). And you could
probably
even run it comfortably on a 50 or 100 MHz CPU. :-)

Indeed (-:! Increases in processor power have definitely encouraged
drops in compiler efficiency (and the willingness to code for
efficiency). Wasn't DOS 3.3 the last one mostly coded in assembler?

I don't know, but perhaps someone here does.
But even later than when DOS 3.3 came out, I think several windows
applications were also coded in Assembler, too. But somewhere along the
line, I'm pretty sure that went out the window (except, perhaps, for some
critical speed subroutines). Coding in assembler is just too tedious. :-)
(that said, I really admire those who could do it well, and get it right)

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
[]
efficiency). Wasn't DOS 3.3 the last one mostly coded in assembler?

I don't know, but perhaps someone here does.
But even later than when DOS 3.3 came out, I think several windows
applications were also coded in Assembler, too. But somewhere along the
line, I'm pretty sure that went out the window (except, perhaps, for some
critical speed subroutines). Coding in assembler is just too tedious. :-)
(that said, I really admire those who could do it well, and get it right)


I'm still blown away by a little .com file I have that simulates an open
fire - flames - on the screen. It's all of 453 bytes. I don't remember
where I got it.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

`The wireless telegraph is not difficult to understand. The ordinary telegraph
is like a very long cat. You pull the tail in New York, and it meows in Los
Angeles. The wireless is the same, only without the cat.' Attributed to Albert
Einstein 1879-1955 (Computing, 1999-12-16).

On Sat, 14 Apr 2012 12:02:57 +0100, J. P. Gilliver (John)
wrote:

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
[]
efficiency). Wasn't DOS 3.3 the last one mostly coded in assembler?

I don't know, but perhaps someone here does.
But even later than when DOS 3.3 came out, I think several windows
applications were also coded in Assembler, too. But somewhere along the
line, I'm pretty sure that went out the window (except, perhaps, for
some
critical speed subroutines). Coding in assembler is just too
tedious. :-)
(that said, I really admire those who could do it well, and get it
right)


I'm still blown away by a little .com file I have that simulates an open
fire - flames - on the screen. It's all of 453 bytes. I don't remember
where I got it.

here?
http://thestarman.pcministry.com/asm/fire/Fire.html
--
[dash dash space newline 4line sig]

Albi CNU

"Harry Vaderchi" wrote in newsp.wcrs7jxz1r0rdn@dell3100:

On Sat, 14 Apr 2012 12:02:57 +0100, J. P. Gilliver (John)
wrote:

In message , Bill in Co
writes:
J. P. Gilliver (John) wrote:
[]
efficiency). Wasn't DOS 3.3 the last one mostly coded in assembler?

I don't know, but perhaps someone here does.
But even later than when DOS 3.3 came out, I think several windows
applications were also coded in Assembler, too. But somewhere along the
line, I'm pretty sure that went out the window (except, perhaps, for
some
critical speed subroutines). Coding in assembler is just too
tedious. :-)
(that said, I really admire those who could do it well, and get it
right)


I'm still blown away by a little .com file I have that simulates an open
fire - flames - on the screen. It's all of 453 bytes. I don't remember
where I got it.

here?
http://thestarman.pcministry.com/asm/fire/Fire.html

There's a nicer one, it starts low, and grows a bit, it looks fairly
realistic too. It might be what John Gilliver has. I remember it, there's
also a watery one, and various keygens have some amazing coding, long
mandala-like audio that never seems to loop, complete withj graphics, all
coming out of a few tens of KB at most.

Even C can be effective and small though. I'm workign on porting a DX7 editor
I made in wxLua. When compiled by TCC, and UPX'ed, it weighs just 22 KB. It's
nearly complete, puts up a tabcontrol with four pages full of DIY
spincontrols, (wxLua provides them natively, the API doesn't, you have to
combine two controls to make them). The editor can detect voice and bank
files, allows auditioning of a voice in a bank, or another bank, prior to
saving, and has edit and recall buffers, and a compare more with muting, and
a config system, a 424x240 pixel bitmap plus several small bitmaps for a
toolbar, and an internal data copying system. it will also have MIDI
capability built in, but I haven't added that yet because although I figured
out how, first, the orginal I'm porting from didn't and I want to get the
port right first, and it's already a lot more capable than that was (a 28K
wxLua script) It's the kind of tool that mostly comes in a program a few
hundred K in size, if not more. I got it small because the C language and use
of the Win32 API to bypass all the bloated MFC or .NET or other controls and
class libraries lets me add only the code I need most. I chose to write my
own common functions, including string and file functions, which also helps.
It's been a long steep climb but from hating C, I have come to love it,
there's an elegance to pointer arithmetic and dereferencing that makes people
normally used to array handling feel like they are suddenly able to walk
through walls and go anywhere so long as they don't get lost trying.

I don't know if I'll take to ASM but I have had a look at it, using DOS's
Debug.exe, same as used for that Fire page Harry linked to (I saved that too,
for looking at some time if I get the urge). One thing I did see last month
was that ASM and Win32 API calls can be directly combined in ways that can
make very small and powerful tools. I think Martin Pesch's MP3DirectCut and
1by1 tools might be built that way. I suspect that if I learn more about
compiling I might get C to make files almost as small as ASM, because one
thing I aim for is to write C code so it works as close as I know how, to the
way the CPU does it. The compiler can help but it works better if it doesn't
have to try to rewrite everything we send to it too much. I'm not taking it
to extremes, no matter how obsessive I get though, because ASM is extremely
dependent on specific hardware, especially the CPU itself, and C isn't, or
ideally, should not be.