 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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\" )
--
/*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 21.01.2014 15:40, schrieb Francois Labreque:
> 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\" )
One - albeit somewhat time-consuming - solution might be to dump
("export") the whole registry to a file, and then use your favorite text
editor with regular expression find & replace do the job. Once you've
located the culprit, you can go back to regedit for fixing it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-21 09:40, Francois Labreque a écrit :
> 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\" )
>
>
Addendum:
Searching through the registry reveals a smorgasborg of
"C:\Windows\System32" and "%SYSTEM_ROOT%\System32"... It looks like
consistency is not Microsoft's forte!
I now get a better appreciation for Stefan Kanthak's series of posts
entitled "Security, the Microsoft way" on the Securityfocus mailing list.
--
/*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 21.01.2014 15:47, schrieb Francois Labreque:
> Searching through the registry reveals a smorgasborg of
> "C:\Windows\System32" and "%SYSTEM_ROOT%\System32"... It looks like
> consistency is not Microsoft's forte!
Consistency and backward compatibility (or even just decades of
incremental development) have never really gone along well :-P
You'd be surprised how often you still find good old 8.3 filenames in
the freakin' registry.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/01/2014 15:40, Francois Labreque a écrit :
> 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.
--
Do not judge my words, judge my actions.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> You'd be surprised how often you still find good old 8.3 filenames in
> the freakin' registry.
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.
When was the last time that the length of the file name extension had
any kind of relevance on anything?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-21 10:53, FractRacer a écrit :
> Le 21/01/2014 15:40, Francois Labreque a écrit :
>> 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...
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/01/2014 23:10, Francois Labreque a écrit :
> Le 2014-01-21 10:53, FractRacer a écrit :
>> Le 21/01/2014 15:40, Francois Labreque a écrit :
>>> 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.
--
Do not judge my words, judge my actions.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/01/2014 23:35, FractRacer a écrit :
> Le 21/01/2014 23:10, Francois Labreque a écrit :
>> Le 2014-01-21 10:53, FractRacer a écrit :
>>> Le 21/01/2014 15:40, Francois Labreque a écrit :
>>>> 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.
>
It's late and my brain slow down!!!
Have you search for /explorer.exe/? It open the folder.
--
Do not judge my words, judge my actions.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la
protection avast! Antivirus est active.
http://www.avast.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.01.2014 17:58, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> You'd be surprised how often you still find good old 8.3 filenames in
>> the freakin' registry.
>
> 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.
Indeed.
Virtually the only pieces of software using file name extensions >3
characters seem to belong to the domain of development tools.
That, and the new MS Office file name extensions.
(The open source community seems to have been more daring in this
respect; probably because its strongest roots are in the Unix community,
where technically there has never been such a thing as file extensions
anyway.)
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-21 17:35, FractRacer a écrit :
> Le 21/01/2014 23:10, Francois Labreque a écrit :
>> Le 2014-01-21 10:53, FractRacer a écrit :
>>> Le 21/01/2014 15:40, Francois Labreque a écrit :
>>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-22 11:54, Warp a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.)
Let us hope this happens someday.
> 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 Motorola 68000 was a 16-bit CPU, but it had opcodes for 32-bit
operations. It's just that they take twice as long. Then if you upgrade
to an M68020 (?), it's 32-bit, and all your software goes 2x as fast.
(Because ALMOST EVERYTHING uses mostly 32-bit arithmetic.)
Going to 64-bit took longer, because nobody really needs 64-bit integer
arithmetic (and we already have 80-bit floating-point arithmetic), so
the only real advantage is increased address space. [Which only matters
once GB-sized RAM started to be manufactured.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> 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.)
That might well be. After all, you could emulate them via unknown-opcode
traps.
>> 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?)
No, no - that A20 line thing is just for a small detail of the 16-bit mode.
> 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...
I'd be surprised if Macs came without A20 line gate. After all, it's the
type of logic that's needed for IBM PC-compatibility but has been moved
from discrete gates on the mainboard into the chipset decades ago already.
> 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...
... because of that very lack of backwards compatibility.
Actually, MS-DOS - and probably the IBM PCs as well - wouldn't have had
any chance of success in the first place, had it not been for MS-DOS's
backwards compatibility with CP/M at the application programming level.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> (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.)
That does sound like an intriguing challenge, provided you don't set out
to design the best OS that has ever been.
If you get to the point where you can compile, link and run a "Hello
World" C program on that platform, that's certainly good enough for
starters.
And if PC hardware seems too messy and non-standardized (which most
certainly is the case), something like the Raspberry Pi might be an
interesting target.
Then again, why design a whole OS if I'd only want to run a very limited
set of programs on it anyway... it can't be too complicated to build a
POV-Ray version that runs directly atop the BIOS, can it? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 23 Jan 2014 01:14:01 +0100, clipka wrote:
>> 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.)
>
> That might well be. After all, you could emulate them via unknown-opcode
> traps.
I don't know if it's the case or not, but I had a recent discussion with
someone about supporting NetWare 2.x (don't ask) on modern hardware, and
the question of whether the A20 line was still supported on modern
processors came up, because at least 2.15 and earlier require that.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/22/2014 5:14 PM, clipka wrote:
>> 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...
>
> I'd be surprised if Macs came without A20 line gate. After all, it's the
> type of logic that's needed for IBM PC-compatibility but has been moved
> from discrete gates on the mainboard into the chipset decades ago already.
>
I thought that, some time back, the only "functional" difference between
Mac and PC had finally come down to an extra chip on the board, which
basically prevented the OS from booting, if it wasn't on a machine that
had it, and.. I am guessing the GUI functionality isn't in firmware/ROM
anymore, right? But, there was a whole huge thing with trying to get PC
stuff to boot on a Mac, and a Mac to boot on standard PC hardware, and
it all came down, not to architectural differences, so much as just,
"There is this extra chip on the board."
Or, maybe I was just imagining that?
--
Commander Vimes: "You take a bunch of people who don't seem any
different from you and me, but when you add them all together you get
this sort of huge raving maniac with national borders and an anthem."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (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.)
>
> That does sound like an intriguing challenge, provided you don't set out
> to design the best OS that has ever been.
Rather, I set out to design an OS that doesn't work like Unix, and
doesn't work like Windows. (Seemingly all extent OS designs are based on
one or the other - but I remember a time before that...)
> If you get to the point where you can compile, link and run a "Hello
> World" C program on that platform, that's certainly good enough for
> starters.
Again, my goal was to design an OS where nothing is ever written in C,
but rather written in safe higher-level languages with don't have buffer
overrun exploits all over the place.
> And if PC hardware seems too messy and non-standardized (which most
> certainly is the case), something like the Raspberry Pi might be an
> interesting target.
The Raspberry Pi didn't exist ten years ago, but now that I think about
it, that *would* be an interesting target...
> Then again, why design a whole OS if I'd only want to run a very limited
> set of programs on it anyway... it can't be too complicated to build a
> POV-Ray version that runs directly atop the BIOS, can it? :-P
The key problem with writing your own OS is that it's almost impossible
to debug it! Not if you run it on real hardware, anyway. Last I checked,
most VM software isn't really designed for this kind of thing either...
It's probably much, much easier to design something like the Java VM,
and then write your own proto-OS that runs inside that. And if you ever
get anywhere with that, *then* try targeting bare metal...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.01.2014 09:51, schrieb Orchid Win7 v1:
> The key problem with writing your own OS is that it's almost impossible
> to debug it! Not if you run it on real hardware, anyway. Last I checked,
> most VM software isn't really designed for this kind of thing either...
It also can't be more difficult than debugging an embedded system, and
I've been there, done that. Sending stuff to a serial port dedicated for
debugging was the standard procedure, even for "applications". For the
code portions running before the serial port was initialized, it was a
PWM output line connected to an LED or a scope.
Using the JTAG port to make the MCU single-step through the code and to
inspect the barebone register or memory values was another important tool.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> 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...
In theory a modern PC ought to be completely backwards-compatible with
the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
in a modern PC. (All the required hardware is still there, most of it
artificially dragging the old technology for backwards compatibility,
the BIOS still supports all the system calls used by DOS, etc.)
However, I would be *really* surprised if you actually got MS-DOS
running natively on a modern PC.
There are many hurdles that you'll encounter. Firstly, you'll need a
hard drive that's small and old enough that MS-DOS will actually be able
to use it. Also, you'll need a PS/2 keyboard because MS-DOS has no idea
what USB is. There are also probably many problems you will encounter
due to the fact that your CPU is so damn fast.
(Also, be aware that MS-DOS has no concept of keeping the CPU in idle
mode. It will run it at 100% capacity all the time, so be prepared for
some noise. Luckily it will only keep one core at 100%. The others won't
even start.)
You *might* be able to make it at least boot up, with luck and a lot
of work, and perhaps even run some programs, but eg. the majority of
old DOS games probably won't work very well. Even if a game by some
miracle runs (rather than just crashing because the computer is a
thousand times faster than even the fastest that the programmers
expected), you won't get any sounds, and you won't be able to use a mouse
(unless you have a PS/2 one).
The thing is, nobody runs MS-DOS natively anymore, and haven't done so
for well over a decade. If you really need to run an old DOS program
you'll use DOSBox anyway. Not only will the program work, it's a million
times less hassle.
So why is the PC architecture dragging all the useless stuff for MS-DOS
compatibility, when nobody's running MS-DOS anyway?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The key problem with writing your own OS is that it's almost impossible
>> to debug it! Not if you run it on real hardware, anyway. Last I checked,
>> most VM software isn't really designed for this kind of thing either...
>
> It also can't be more difficult than debugging an embedded system, and
> I've been there, done that. Sending stuff to a serial port dedicated for
> debugging was the standard procedure, even for "applications". For the
> code portions running before the serial port was initialized, it was a
> PWM output line connected to an LED or a scope.
>
> Using the JTAG port to make the MCU single-step through the code and to
> inspect the barebone register or memory values was another important tool.
Yeah, embedded systems have a serial port so you can find out what's
happening. But if the software on a desktop PC stops working... it's a
brick. There's no way to interact with it. The best you can do is reboot it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/01/2014 03:20 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> 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...
>
> In theory a modern PC ought to be completely backwards-compatible with
> the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
> in a modern PC. (All the required hardware is still there, most of it
> artificially dragging the old technology for backwards compatibility,
> the BIOS still supports all the system calls used by DOS, etc.)
> However, I would be *really* surprised if you actually got MS-DOS
> running natively on a modern PC.
Oh I don't know... It'll probably work.
> There are many hurdles that you'll encounter. Firstly, you'll need a
> hard drive that's small and old enough that MS-DOS will actually be able
> to use it.
I suspect so long as it isn't native 4K sectors, it'll just be reported
as 2GB.
> Also, you'll need a PS/2 keyboard because MS-DOS has no idea
> what USB is.
Many PCs have a BIOS option for PS/2 emulation. That is, to make a USB
keyboard appear to be a PS/2 one.
> There are also probably many problems you will encounter
> due to the fact that your CPU is so damn fast.
Hell yes!
> The thing is, nobody runs MS-DOS natively anymore, and haven't done so
> for well over a decade.
I'm pretty sure the in-store management system that John Lewis use is
still DOS-based. (Whether it's running natively or in some emulation
layer is another matter...)
> If you really need to run an old DOS program
> you'll use DOSBox anyway. Not only will the program work, it's a million
> times less hassle.
>
> So why is the PC architecture dragging all the useless stuff for MS-DOS
> compatibility, when nobody's running MS-DOS anyway?
No idea. Presumably because it would mean changing stuff?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.01.2014 22:28, schrieb Orchid Win7 v1:
> On 23/01/2014 03:20 PM, Warp wrote:
>> There are many hurdles that you'll encounter. Firstly, you'll need a
>> hard drive that's small and old enough that MS-DOS will actually be able
>> to use it.
>
> I suspect so long as it isn't native 4K sectors, it'll just be reported
> as 2GB.
Bwahaha! Dream on :-P
I might be wrong, but I'd suspect you'll get anything from 2GB down to
-2GB, depending on whatever value the result overflows to.
>> There are also probably many problems you will encounter
>> due to the fact that your CPU is so damn fast.
>
> Hell yes!
Indeed. IIRC even in the times of the 386DX-50, programs written in
Turbo Pascal would already occasionally to crash with a division by zero
right at the start, because in order to calibrate the delay() loop the
runtime library would run the loop N times, figure out that it took 0
seconds, and conclude that for 1 second it would need to run the loop
N/0 times... Whoops!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> There are many hurdles that you'll encounter. Firstly, you'll need a
>>> hard drive that's small and old enough that MS-DOS will actually be able
>>> to use it.
>>
>> I suspect so long as it isn't native 4K sectors, it'll just be reported
>> as 2GB.
>
> Bwahaha! Dream on :-P
>
> I might be wrong, but I'd suspect you'll get anything from 2GB down to
> -2GB, depending on whatever value the result overflows to.
And I think *you* will find that drives larger than 2GB report
themselves using a different BIOS API.
>>> There are also probably many problems you will encounter
>>> due to the fact that your CPU is so damn fast.
>>
>> Hell yes!
>
> Indeed. IIRC even in the times of the 386DX-50, programs written in
> Turbo Pascal would already occasionally to crash with a division by zero
> right at the start, because in order to calibrate the delay() loop the
> runtime library would run the loop N times, figure out that it took 0
> seconds, and conclude that for 1 second it would need to run the loop
> N/0 times... Whoops!
OK, well I've never seen *that*... I have seen plenty of PCs with a
"turbo" button though.
It was there for a reason.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The thing is, nobody runs MS-DOS natively anymore, and haven't done so
>> for well over a decade.
>
> I'm pretty sure the in-store management system that John Lewis use is
> still DOS-based. (Whether it's running natively or in some emulation
> layer is another matter...)
http://en.wikipedia.org/wiki/MSDOS
"As of 2011, MS-DOS is still used in some enterprises to run legacy
applications, such as this US Navy food service management system."
It is unclear whether this is with or without emulation, however. And
they could just be running this stuff on really ancient hardware. (When
I left my previous company, we still had a box in storage with Windows
98 installed on it. Mercifully, I *never* needed to power it up!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-23 16:28, Orchid Win7 v1 a écrit :
>
> Oh I don't know... It'll probably work.
>
>> There are many hurdles that you'll encounter. Firstly, you'll need a
>> hard drive that's small and old enough that MS-DOS will actually be able
>> to use it.
>
> I suspect so long as it isn't native 4K sectors, it'll just be reported
> as 2GB.
No. The boot drive had to have a primary partition that is less than
2GB, and fits entirely below cylinder 1023 or else DOS won't understand
it. You also need a special driver that loads before IO.SYS in order to
fake the number of heads and cylinders because it doesn't understand LBA
mode. This has been the case as far back as drives that had more than
1GB of space (Anyone remember OnTrack Disk Manager?), since it usually
meant more than 1024 cylinders, as you couldn't fit more than 2 platters
in a regular drive bay.
>> So why is the PC architecture dragging all the useless stuff for MS-DOS
>> compatibility, when nobody's running MS-DOS anyway?
>
> No idea. Presumably because it would mean changing stuff?
You can rest assured that somewhere, there's a nuclear reactor or a
stock-exchange trading application, or an airline flight scheduler or
something of the sort that still relies on a DOS based controller, ans
as long as this exists, no hardware maker is going to risk stopping
support for it for fear of losing business.
Heck, I just saw today that IBM still officially releases JREs of its
own flavor of Java for OS/2 Warp. There mu$t be a good rea$on for it.
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2014-01-22 16:18, Dre a écrit :
> 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
This KB article sent me on the proper path...
I paid a closer look at the syntax of the entries in
HLCU\Software\Microsoft\Windows\CurrentVersion\Run, and bingo.
It was an invalid entry created by the Epson Printer software installer.
(Apologies to the Blender Foundation for wrongly acusing them!)
I also found a gazillion entries where rundll32.exe is not using the
full path, which could lead to very easy trojan horse injections.
ex:
Good:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell\print\command]
@="\"C:\\WINDOWS\\system32\\rundll32.exe\"
\"C:\\WINDOWS\\system32\\mshtml.dll\",PrintHTML \"%1\""
Bad:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\jpegfile\shell\open\command]
@="rundll32.exe C:\\WINDOWS\\system32\\shimgvw.dll,ImageView_Fullscreen %1"
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The Raspberry Pi didn't exist ten years ago, but now that I think about
> it, that *would* be an interesting target...
Here's a start:
http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
