 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How many new file formats are created nowadays that dare to use more
> than 3 characters in their file name extension?
>
> There are some brave people who are courageous enough to make them
> larger than 3 characters, but they are extremely rare.
The only one I can think of is Java - which uses *.java and *.class for
source and object files.
Visual Studio uses a few like *.vcxproj and similar.
Flam3 uses *.flam3 (then again, this software originates from Unix).
In short, this stupidity is slowly drifting away - but only slowly.
Next up: Why, in the year 2014, am I still running installers that have
16-bit dithered logos? WTF?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> > When was the last time that the length of the file name extension had
> > any kind of relevance on anything?
> Only a few days ago. Relevant in the sense that the artificial
> limitation to 3 characters keeps leading to file extension clashes,
> which suck :-P
I meant, obviously: When was the last time that a file name extension
of more than 3 characters caused any kind of problem...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> Next up: Why, in the year 2014, am I still running installers that have
> 16-bit dithered logos? WTF?
Obviously you need to be able to run it in safe mode...
Speaking of which, even though the 80386 processor was introduced
in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
mode. Yes, even the new 64-bit ones.
The very first thing that the OS does is to switch to either 32-bit
mode (if the CPU is that old) or to 64-bit mode. After that it will
usually never revert back to 16-bit mode ever again.
Support for 16-bitness increases the CPU complexity and thus its price,
and is overall just dead weight that has little to no purpose.
(Granted, there might still be *some* software out there that's 16-bit
and needs to be run even on a modern PC... although this will happen
*only* on Windows. I don't think Linux or BSD has ever run anything
in 16-bit mode for as long as they have existed.
And the thing is, if you have some obscure legacy driver or something
like that, and it's 16-bit, it's only impacting the computer's performance,
even if so slightly.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> not quite, but...
>>>
>>>> Ever since I tried to install the latest Blender, whenever I boot my
>>>> PC,
>>>> I get the system32 folder that opens. I suppose there's a registry
>>>> entry somewhere that got created improperly and instead of trying to
>>>> load "C:\Windows\System32\whatchamacallit.dll" or
>>>> "%SYSTEM_ROOT%\System32\foobar.exe" it simply loads
>>>> "C:\Windows\System32".
>>>>
>>>> How do I find out which one it is? Regedit's search function is not
>>>> smart enough to let me search for ( "system32" except when it's
>>>> "system32\" )
>>>>
>>>>
>>>
>>> In the registry, you can search the entries
>>> HKEY_CURRENT_USER/Software/MicrosoftWindows/CurrentVersion/Run
>>> or
>>> HKEY_LOCAL_MACHINE/Software/MicrosoftWindows/CurrentVersion/Run
>>> Where are stored all the softwares launched at the startup.
>>>
>>> Lionel.
>>
>> That's the first place i looked, and there are no mentions of system32
>> there...
>>
> Have you seen in the StartMenu folder? A link may be placed here.
>
Nope.
Also did msconfig, and the usual steps to resolve these issues.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> Next up: Why, in the year 2014, am I still running installers that have
>> 16-bit dithered logos? WTF?
>
> Obviously you need to be able to run it in safe mode...
>
> Speaking of which, even though the 80386 processor was introduced
> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> mode. Yes, even the new 64-bit ones.
>
> The very first thing that the OS does is to switch to either 32-bit
> mode (if the CPU is that old) or to 64-bit mode. After that it will
> usually never revert back to 16-bit mode ever again.
>
> Support for 16-bitness increases the CPU complexity and thus its price,
> and is overall just dead weight that has little to no purpose.
>
> (Granted, there might still be *some* software out there that's 16-bit
> and needs to be run even on a modern PC... although this will happen
> *only* on Windows. I don't think Linux or BSD has ever run anything
> in 16-bit mode for as long as they have existed.
I think on some releases of Linux or BSD, you could run XENIX
executables, which were 16bit, if memory serves me right.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2014 17:54, schrieb Warp:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> Next up: Why, in the year 2014, am I still running installers that have
>> 16-bit dithered logos? WTF?
>
> Obviously you need to be able to run it in safe mode...
>
> Speaking of which, even though the 80386 processor was introduced
> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> mode. Yes, even the new 64-bit ones.
Not all of them. Look up UEFI and coreboot.
> The very first thing that the OS does is to switch to either 32-bit
> mode (if the CPU is that old) or to 64-bit mode. After that it will
> usually never revert back to 16-bit mode ever again.
I thought the 64-bit mode was exactly the same as the 32-bit one, except
that some memory pages are flagged differently?
> Support for 16-bitness increases the CPU complexity and thus its price,
> and is overall just dead weight that has little to no purpose.
>
> (Granted, there might still be *some* software out there that's 16-bit
> and needs to be run even on a modern PC... although this will happen
> *only* on Windows.
Even then, it might be argued that a bytecode interpreter on a modern
machine could probably run 16-bit code just as fast as machines from
back then.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > Speaking of which, even though the 80386 processor was introduced
> > in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> > mode. Yes, even the new 64-bit ones.
> Not all of them. Look up UEFI and coreboot.
An x86 CPU will start in 16-bit mode when it's powered-up. I don't think
there's any way to bypass that via anything. The only thing that a
32/64-bit BIOS can do is to make the switch to 32/64-bit mode earlier
in the bootup process.
However, such a BIOS could theoretically allow for a x86 CPU to drop
16-bit support completely (if the OS can, thanks to such a BIOS, assume
the CPU is already running in 32/64-bit mode when it boots.)
> > The very first thing that the OS does is to switch to either 32-bit
> > mode (if the CPU is that old) or to 64-bit mode. After that it will
> > usually never revert back to 16-bit mode ever again.
> I thought the 64-bit mode was exactly the same as the 32-bit one, except
> that some memory pages are flagged differently?
Actually, if I have understood correctly, the 64-bit mode in an x86-64
architecture is quite different from its 32-bit mode. For instance, a
whole family of CPU opcodes are treated completely differently in
64-bit mode than in 32-bit mode (for example to account for the larger
number of available CPU registers.)
16-bit and 32-bit modes are much more tied together. For instance, you
can access 32-bit registers in 16-bit mode and vice-versa (and IIRC it
happens by using the exact same opcode prefix). However, the 64-bit mode
is so separate that you can't eg. use 64-bit CPU registers in 32-bit mode
at all.
There are some completely different CPU architectures where the
distinction between 32-bit and 64-bit modes is much more transparent.
The UltraSparc would be a perfect example. It's so transparent that it
doesn't even need separate modes for 32-bit and 64-bit code: They both
run just fine as-is, even if you mix them up. (The original Sparc
architecture was 32-bit, and the UltraSparc is 64-bit, but was designed
in such a manner that it can run old 32-bit code as-is, without having
to switch to any kind of compatibility mode, like the x86-64 has to.
32-bit code will use the same 64-bit registers as 64-bit code, but be
none the wiser.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/01/2014 1:40 AM, Francois Labreque wrote:
> not quite, but...
>
> Ever since I tried to install the latest Blender, whenever I boot my PC,
> I get the system32 folder that opens. I suppose there's a registry
> entry somewhere that got created improperly and instead of trying to
> load "C:\Windows\System32\whatchamacallit.dll" or
> "%SYSTEM_ROOT%\System32\foobar.exe" it simply loads "C:\Windows\System32".
>
> How do I find out which one it is? Regedit's search function is not
> smart enough to let me search for ( "system32" except when it's
> "system32\" )
>
>
I've seen this before, have a look here:
http://support.microsoft.com/kb/170086
Cheers Dre
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/01/2014 04:54 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> Next up: Why, in the year 2014, am I still running installers that have
>> 16-bit dithered logos? WTF?
>
> Obviously you need to be able to run it in safe mode...
I didn't think even Safe Mode runs in 16-bit colour any more. And even
if it does... so make the OS convert from 24-bit down to 16-bit on the
fly! Sheesh.
> Speaking of which, even though the 80386 processor was introduced
> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> mode. Yes, even the new 64-bit ones.
I got the impression that 64-bit CPUs cut back on some of the really
ancient 16-bit stuff. (I don't have an actual site for that though.)
> The very first thing that the OS does is to switch to either 32-bit
> mode (if the CPU is that old) or to 64-bit mode. After that it will
> usually never revert back to 16-bit mode ever again.
Ah yes - by toggling line 20 on the address bus. Obviously. (WTF?)
Well, that's only in so-called "IBM PC-compatibles". (How compatible are
any of these with the 30-year old dinosaur?) I think the Apple Mac does
it differently...
> Support for 16-bitness increases the CPU complexity and thus its price,
> and is overall just dead weight that has little to no purpose.
Oh, but that's not all.
Did you know that your graphics card starts up emulating an
IBM-manufactured video board from 27 years ago? And then you have to run
special driver software to turn off all the pointless emulation and put
the card into 24-bit, memory-mapped mode at a real-world screen
resolution. Go figure...
Overall, PCs are just *full* of this crap. (Some of you may remember I
once set out on a misguided quest to "write my own OS". I read up on
some of this stuff.) And yet, when somebody produces a technically
superior system that lacks lashings of backwards compatibility, nobody
actually buys it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Speaking of which, even though the 80386 processor was introduced
>> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
>> mode. Yes, even the new 64-bit ones.
>
> Not all of them. Look up UEFI and coreboot.
As Warp says, this is a function of the CPU, not the OS or the BIOS or
anything else. It's in Intel and AMD's reference manuals. (Although I
haven't looked into 64-bit; maybe it starts in a less-ancient emulation
mode?)
> I thought the 64-bit mode was exactly the same as the 32-bit one, except
> that some memory pages are flagged differently?
No. In "long mode" (i.e., 64-bit mode) there are several brand new CPU
registers available. It doesn't just make the existing ones wider. This
means that code which is very register-heavy should hypothetically run
faster, since you can hold more stuff in registers rather than on the
stack or the heap.
IIRC, POV-Ray runs about 6% faster in long mode, indicating that
actually the L1 cache makes the difference pretty damned moot anyway.
(Contrary to my expectations.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
