Hello Everyone!
in [General Linux]
|
From: Wanna-Be Sys Admin on 1 Dec 2009 17:43 ray wrote: > On Sun, 29 Nov 2009 03:03:07 -0800, Jarrno wrote: > >> hello everybody! >> just to let you know i joined this group ! i just posted a comment >> just like this but i cant see it on the comment page.. >> so. which is better linux or vista? > > Neither is 'better' - they are different. Which is better, a Ford or a > Toyota? (look at the recent safety recalls before you answer) Toyota, hands down. That's a bad example. Ford also has a bad safety recall record, Toyota usually doesn't, and everything is better on a Toyota. And, Linux IS better than Windows for almost everything. -- Not really a wanna-be, but I don't know everything.
From: ray on 1 Dec 2009 18:02 On Tue, 01 Dec 2009 14:43:16 -0800, Wanna-Be Sys Admin wrote: > ray wrote: > >> On Sun, 29 Nov 2009 03:03:07 -0800, Jarrno wrote: >> >>> hello everybody! >>> just to let you know i joined this group ! i just posted a comment >>> just like this but i cant see it on the comment page.. so. which is >>> better linux or vista? >> >> Neither is 'better' - they are different. Which is better, a Ford or a >> Toyota? (look at the recent safety recalls before you answer) > > Toyota, hands down. That's a bad example. Ford also has a bad safety > recall record, Toyota usually doesn't, and everything is better on a > Toyota. And, Linux IS better than Windows for almost everything. Thought I might get a bite on that one. BTW - I don't agree with you - but here is another question - which is 'better' a sports car or a pick up? The answer is that it depends entirely on what you intend to do with it.
From: Aragorn on 2 Dec 2009 05:32 On Tuesday 01 December 2009 19:16 in comp.os.linux.misc, somebody identifying as Peter Köhlmann wrote... > Aragorn wrote: > >>> Wrong. Windows 7 x64 cannot even execute a single line of 16 bits >>> real mode code except in the boot loader. >> >> Yes, but the same is true for 64-bit Linux, > > No, it isn't Yes it is. >> because this is not a limitation of the operating system, but of the >> hardware. > > Wrong No, right. >> When an x86-64 processor is running in its native "long mode" (which >> is a protected mode) it no longer supports real mode or V86 mode. > > This is blatantly wrong No, it isn't. > How come that I can run old 16-bit windows apps in wine on a 64bit > linux machine? Because those old 16-bit Windows applications were written in such a way that they could be executed equally well from within protected mode as from within real mode. In Windows "Standard Mode" - a.k.a. "286 mode" - those applications were executed in a DPMI ("DOS Protected Mode Interface") context. They ran entirely in the userspace of the 286 (or later) processor's protected mode, with the exception of certain I/O operations and hardware access, which was executed by switching the processor back to real mode. (This was easier on the i386 and later processors, because i286 could not be switched back to real mode without a processor reset.) In addition to the above, Wine is not a Windows emulator but only a Windows-compatible API on top of UNIX, which means that every DOS-specific hardware call from within one of those Windows applications must be trapped and translated into a UNIX call, which is then executed by the underlying UNIX operating system. This is also why you cannot run pure DOS applications in Wine. It's just a Windows userspace compatibility API on top of UNIX, not a Windows emulator. >> It does support them when running in 32-bit legacy mode, i.e. with a >> 32-bit operating system kernel. > > It runs them just as well on a 64bit linux. The only way to execute 16-bit real mode code on 64-bit operating systems is by emulating a processor in software. 64-bit long mode does not have real mode compatibility via a "virtual 86" mode. However, if the kernel of the operating system itself is 32-bit, then an x86-64 processor will run in "legacy mode" and will then have "virtual 86" support. > The only thing which is needed for windows7 64bits is having WoW for > 16bits too. It does not, hence it can't run 16bit code. I don't do Windows - my experience with Windows is limited to six months of 3.x and two years of NT 4.0 in a distant past - and I don't know anything more about Windows 7 than what I've read about it on the web. I also have no idea what "WoW" is. Yet, you seem to be confused with regard to the nature of 16-bit code. There is 16-bit real mode code and there is 16-bit protected mode code. Most of the time, third-party 16-bit real mode code and the 16-bit real mode code from Microsoft itself but written specifically for DOS could not be made to run in protected mode for obvious reasons, i.e. the use of direct hardware access and direct memory addressing. However, some 16-bit Windows applications from the days of Windows 3.0 - which itself could be started in "real mode", "standard mode" and "enhanced 386 mode" - was written in such a way that it was compatible with protected mode execution. Windows "real mode" was dropped at the introduction of Windows 3.1, but the Windows API only (partially) switched to 32-bit wide instructions as of Windows 95. >> That said, I wasn't referring to real mode when I wrote the section >> you commented on, but rather to the origins of Windows, or perhaps I >> should say OS/2, which is what Windows has most in common with. (I >> was an OS/2 2.x user myself for five years in the early-to-mid '90s.) >> >>> There's a DOS compatibility layer on Windows NT 4 to 6, 32 bits, >>> but, similarly, Linux can execute DOS code in Virtual86 mode with >>> dosemu. > > And it can run 16bit DOS apps on a 64bit machine as well Yes, via processor emulation, unless - as I wrote higher up - the operating system kernel on that 64-bit machine is actually 32-bit. A 64-bit kernel runs in the processor's long mode, and in long mode, x86-64 no longer supports v86 mode, so it has to be emulated in software. >> Actually, /dosemu/ doesn't do V86 mode; instead it emulates a >> processor in software. > > No, it does not. You are thinking of QEmu My confusion with regard to this was cleared up already prior to my reply to this post of yours here. I was mixing up DOSbox and dosemu. But in a natively 64-bit operating system, even dosemu emulates a processor in software, simply because long mode doesn't have a compatibility submode for 16-bit real mode code anymore. >> There are however other DOS emulators such as DOSbox which do make >> use of V86, but this would only work in a 32-bit operating system. > > Again, wrong. It runs just fine on my 64bit machines. On all of them I never said that it wouldn't run fine. What I said was that 64-bit long mode of an x86-64 processor - i.e. a 64-bit operating system kernel running on an x86-64 processor - doesn't support the execution of real mode applications anymore by lack of a v86 submode, and thus such real mode code would indeed still run perfectly, but only via software processor emulation, *unless* you are indeed speaking of 16-bit *Windows* code in Wine, which is supported because it can be executed in protected mode. (64-bit long mode *is* protected mode and supports the execution of 64-bit code, 32-bit code and protected mode 16-bit code.) Here's an attempt at an overview table of what x86-64 supports...: (a) 64-bit native (64-bit kernel) has 2 execution modes (i.e. "long mode" and "compatibility mode") * long mode : 64-bit apps only * compatibility mode : 32-bit apps 16-bit protected mode apps (b) 32-bit legacy mode (32-bit kernel) has 2 execution modes (i.e. "protected mode", "virtual 86 mode") * protected mode : 32-bit apps 16-bit protected mode apps * virtual 68 mode : 16-bit real mode apps with limited support for "DOS extenders" (c) real mode (d) systems management mode Notes: (1) Actual real mode is never used once a 32-bit or 64-bit operating system is loaded because real mode poses a real threat to system stability. On the old Intel 80286 however, and in 16-bit protected mode operating systems like OS/2 1.x, there was no virtual 86 mode and thus switching back to real mode was the only way for such an operating system to execute DOS applications. Anything then going wrong in the DOS compatility environment would crash the system, and in addition, as long as the processor was in real mode, all execution of protected mode processes was suspended. This is why virtual 86 mode (V86) was introduced on the Intel 80386, which presents a real mode processor to the application while the processor is actually running with memory and process protection enabled. Virtual 86 mode also allows for the multitasking of (complete) V86 sessions - not for processes *within* a single V86 session - together with native protected mode processes. The best way to look at V86 is therefore as a protected mode wrapper for real mode code. (2) Systems management mode was introduced on a later variant of the Intel 80386 and is also called "unreal mode". It is achieved by switching the processor into protected mode first and setting up a complete protected mode environment, with pagetables and all, and then dropping the protection register value from 1 to 0 again, effectively engaging a real mode-like environment with pagetables still enabled. When the descriptor tables have also been enabled, one typically refers to this as "big (un)real mode". Systems management mode is used by power management and ECC and can only be invoked by the hardware, via a special interrupt. The operating system kernel and everything else in memory is temporarily halted when the CPU is in systems management mode, and so the only thing invoking and running in systems management mode would be high priority firmware processes, such as the ECC routines I've mentioned, or certain hardware power management instructions. -- *Aragorn* (registered GNU/Linux user #223157)
From: Aragorn on 2 Dec 2009 05:55 On Tuesday 01 December 2009 20:54 in comp.os.linux.misc, somebody identifying as Peter Köhlmann wrote... > André Gillibert wrote: > >> Peter Köhlmann <peter-koehlmann(a)t-online.de> wrote: >> >>> Aragorn wrote: >>> >>> > When an x86-64 processor is running in its native "long mode" >>> > (which is a protected mode) it no longer supports real mode or V86 >>> > mode. >>> >>> This is blatantly wrong >>> How come that I can run old 16-bit windows apps in wine on a 64bit >>> linux machine? >> >> Wine doesn't support 16 bit windows app on x86-64. >> <http://oss.gse.nl/wine/> >> > That is fine. Yet I run some 16bit windows apps on 64bit Suse linux > > Strange, isn't it? Please see my other reply to you, where I am explaining this in-depth. > You are talking about Wine64, which is itself running in 64bit mode. > I am talking about "normal" wine, which is a 32bit app, running just > fine on 64bit linux, and which *does* support 16bit windows apps > > Point: 64bit processors have no problems at all running 64bit, 32bit > and 16bit apps at the same time. > *win64* has problems, but those are problems of the OS, not of the > hardware. > For example: If you install VirtualBox on a 64bit windows machine and > run 32bit WinXP inside it, it will run 16bit apps too. > > And VirtualBox does *not* emulate the processor The 64-bit version of VirtualBox emulates a processor via software if the hardware does not have virtualization extensions. On hardware that does have virtualization extensions, the physical processor can be dedicated to whatever runs inside VirtualBox, with only the limitation again that if the operating system running inside of the VirtualBox environment is itself 64-bit, then it too won't support the execution of 16-bit real mode code - again, because 64-bit long mode doesn't support it. However, it *is* possible, provided that the hardware has virtualization extensions, to have a 64-bit host system which runs a 16-bit real mode environment - e.g. FreeDOS - inside a VirtualBox session. >>> > It does support them when running in 32-bit legacy mode, i.e. with >>> > a 32-bit operating system kernel. >>> >>> It runs them just as well on a 64bit linux. >>> The only thing which is needed for windows7 64bits is having WoW >>> for 16bits too. It does not, hence it can't run 16bit code. >> >> Nope, that's a limitation of the long mode on x86-64. > > Bullshit: Are you telling me that I just imagine those apps running on > my machine? No, just that you don't understand the difference between real mode and protected mode. The Intel 80286 processor had two modes - real mode and protected mode - but it still was only a 16-bit processor. Hence, you can have 16-bit real mode applications and 16-bit protected mode applications. Most 16-bit real mode applications do not support protected mode because of the liberties they allow themselves in direct hardware and memory access. However, at the time of Windows 3.0, and due to the fact that the Windows 3.0 code (and that of its extra mini-apps such as Notepad or Write) was written in a "clean" way - i.e. it would not directly try to access the hardware or manipulate memory addresses - it could be executed both in real mode and protected mode. And that said, there are also genuine 16-bit protected mode applications. Everything application ever written for OS/2 1.x and XENIX was written for 16-bit protected mode, and although Windows 95 introduced 32-bit support, many of the Windows 95 applications were still only 16-bit, and 16-bit protected mode code *can* be executed in the x86-64 processor's long mode. It's not the bit width that matters, it's whether the code attempts to access the hardware directly or not. In a real mode setting, application software would usually directly attempt to allocate memory segments or access hardware devices. Just about every major DOS application at the time - e.g. MS-Word, WordPerfect 5.1, TurboPascal, dBASE III and IV, Lotus 123 et al - had their own drivers for hardware peripherals - e.g. mouse, printer, graphical display drivers et al. This is how real mode works: the application becomes the operating system. Virtual 86 mode was introduced to allow such programs to run by providing for a "real mode"-like environment from within a protected mode wrapper. Certain direct hardware calls were simply ignored, while others (such as direct memory addressing) were allowed access to an isolated environment. The application would think it was running on the bare metal, but it was actually running in a sandbox. x86-64 running in 64-bit long mode no longer supports V86 and thus it doesn't have such a sandbox anymore for real mode applications. It can however still run protected mode 16-bit code, because this code abides by the rules and relays all of its hardware accesses to the underlying operating system. > < snip rather idiotic bull > Although that comment was not aimed at me - since it was André whom you were replying to - the ad hominem innuendo is noted, and only serves to confirm what I have told you earlier about your lack of courtesy. -- *Aragorn* (registered GNU/Linux user #223157)
From: Aragorn on 2 Dec 2009 06:07
On Tuesday 01 December 2009 22:46 in comp.os.linux.misc, somebody identifying as Peter Köhlmann wrote... > André Gillibert wrote: > >> Peter Köhlmann <peter-koehlmann(a)t-online.de> wrote: >> >>> >> It runs them just as well on a 64bit linux. >>> >> The only thing which is needed for windows7 64bits is having WoW >>> >> for 16bits too. It does not, hence it can't run 16bit code. >>> > >>> > Nope, that's a limitation of the long mode on x86-64. >>> >>> Bullshit: Are you telling me that I just imagine those apps running >>> on my machine? >> >> I tell you that it uses CPU virtualization extensions or emulation. >> XP mode needs AMD-V or Intel VT: >> <http://www.microsoft.com/windows/virtual-pc/support/faq.aspx> > > And I tell you that you are wrong. Nope, *you* are the one who is wrong. > I *know* what my machines are running, [... You only know part of it, as explained elsewhere in abundance already. > ...] and you can quite frankly get lost. Don't have many friends, do you? <eg> > What is wqrong with you? There is nothing simpler than installing wine > 32bit on a linux 64bit machine, and than start some old win16 > application None of such a setup would ever run VT mode for running > wine32 Win16 applications can run either in real mode or in protected mode. 16-bit protected mode is supported on x86-64 when in 64-bit native mode (via 32-bit compatibility mode, which supports 16-bit protected mode code). 16-bit *real* *mode* code is not. > Why do you argue against something you quite obviously have never > done? > > One of my 64bit machines can *not* handle VT. Yet it not only runs > wine32 just fine, it also runs 16bit windows apps inside wine Those 16-bit apps are running in protected mode. > The next thing you are doing will probably telling me that I am lying. > Because you naturally can't be wrong with your halfassed tiny > knowledge > > < snip more outrageous bullshit > > > *If you were right, then running 32bit apps would also be impossible > without VT mode. But it isn't. It's not the bit-ness that matters, it's whether the application attempts to directly access the hardware or not. Most 16-bit real mode applications attempt to do that, but many Win16 applications - and most notably all the Win16 components of Windows 3.x - were written in such a way that they can also be executed in a protected mode environment. <Wikipedia blockquote> (http://en.wikipedia.org/wiki/Protected_mode) According to the Intel 80286 Programmer's Reference Manual, [19] “...the 80286 remains upwardly compatible with most 8086 and 80186 application programs. Most 8086 applications programs can be re-compiled or re-assembled and executed on the 80286 in Protected Mode. ” For the most part, the binary compatibility with real-mode code, the ability to access up to 16 MB of physical memory, and 1 GB of virtual memory, were the most apparent changes to application programmers.[19] This was not without its limitations, if an application utilized or relied on any of the techniques below it wouldn't run:[20] * Segment arithmetic * Privileged instructions * Direct hardware access * Writing to a code segment * Executing data * Overlapping segments * Use of BIOS functions, due to the BIOS interrupts being reserved by Intel[21] In reality, almost all DOS application programs violated these rules [22] Due to these limitations, virtual 8086 mode was created and released with the 386. Despite such potential setbacks, Windows 3.x and its successors can take advantage of the binary compatibility with real mode to run many Windows 2.x applications, which run in real mode in Windows 2.x, in protected mode.[23] </Wikipedia blockquote> André and I will kindly be accepting your apologies. We will however not be holding our breaths until they get here. ;-) -- *Aragorn* (registered GNU/Linux user #223157) |