Are we going to 64 bit Assembly?

[Antariy]

Rockoon

Thats irrelevant. That 32-bit OS uses the SAME mode to run 32-bit code that the 64-bit OS uses. All processors, aside from a few crappy ones, are 64-bit these days.

As I say: I don't have 64bit CPU and OS, so - this stuff to very needed to me. My CPU don't old by years, but it don't have DEP, HT etc. And, of course, it not 64bit :)

You dont seem to understand. There is no thunking in 64-bit windows. 64-bit code cannot call 32-bit code, or vise-versa.

Explain to me, how work 64bit system, when it MAY allocate nearly 4GB memory to 32bit app? This is tested and is true. System dlls located in top of address space (logical)?

The WOW64 subsystem orchestrates the dynamic loading of alternative API DLL's. A 64-bit program loads only 64-bit DLL's. A 32-bit program loads only 32-bit DLL's. Those 32-bit DLL's do not (and can not) call the 64-bit DLL's.

This is well known. No need to have 64bit OS to this :)

No, it musn't be. You are confusing physical memory addresses with logical memory addresses. All modern userland programs only know of logical addresses. This entire paradigm is called Virtual Memory. Just because you have a buffer at offset 010000h does not mean that its *physically* at 010000h. It could be physically at 020000h, or 012340000h. Logically, it could be mapped at *both* 010000h for one process and 020000h for another.

I don't mean PHYSICAL space, I mean logical. Don't decide, what you talk with silly man. I must speak by full form, as coroner? :)
I love simple language, and I badly speak on English.

This mechanism is used on both 32-bit and 64-bit OS's. Inter-process communications hasnt changed.

This is not piece of news to me, but thanks for info.

How so? If it was just a rush to market, they wouldn't have obsoleted instructions in Long mode.

I mean not this (old instructions). I mean, for example, very "nice" availability of explicit (link-time) pointers pushing (push offset SomeThing).
And some other.

AMD64 won because it offered a compatibility mode with x86. Intels offering did not offer a compatibility mode, so it lost. Intel forget that compatibility is king, that it was compatibility that allowed it to topple the Motorola giant.

You are right. But, when I say that Intel to be forced with x64 - I mean x64, not IA64.


Alex
P.S. I delete post because I don't love speak not very good things. I speak it about vendors, because have bad mood :)

[BogdanOntanu]

32 bits code running on a 64bits OS is slower than 32 bits code running on a 32 bits OS on the very same CPU (ie a CPU that is capable to do x64 long mode)

There are a few reasons for this:
1) the drivers are 64 bits only. Hence some level of translation and additional handling is required when a 32 bits application reaches the point where a request it send or an answer is received from an driver.

2) Again the kernel is x64 only and during an hardware IRQ (mouse, network, video, hard-drive, USB)  the CPU has to perform a more costly transition from 32bits mode to 64 bits mode and back when compared to a 64 bits application.

3) even if the 32 bits application executes "as if" it runs on a 32 bits CPU in 32 bits protected mode it does not. The CPU is in fact setup into long mode early in the OS startup and it does stay this way. In consequence on each task switch the hardware has to re-configure it self "on the fly" in order to accommodate the 32 bits application. This means new rules for selectors, new rules for instruction decoding, etc.

All this and some more makes the 32 bits application run slower on an x64 OS than it does when the CPU is in 32 bits mode.

However such applications can benefit from having more memory available to them because the kernel is 64 bits and usually outside of the 32bits memory address space.

Then an 64 bits CPU is usually bigger and slower than an 32 bits CPU. Contrary to popular belief decoding extra registers does take additional time and the same is valid for doing 64 bits adding and multiply and division. A bigger circuit area does generate more heat and has bigger delays.

However it is expected that the additional address range (>4G) together with having more registers and the fact that most PC's will be sold with an 64 bits OS pre-installed  will slowly erode the 32 bits speed and power dissipation/delay advantage and in time 64 bits OS and CPU will become the norm.

In fact having a 64 bits CPU is already the "norm" fro new PC's but one has to understand that big firms with 100+ PC's take time to upgrade all CPUs and OSes and this does cost a lot of money ... hence do not hold your breath.

[hutch--]

The factor that stick in my head is user fatigue with endlessly changing new systems. My next door neighbor used to work at the Opera house back in the days of text mode interface ticketing software and said once understood it was very fast to use and proven reliable over time. Then comes the 32 bit GOOEY with messageboxes (Do ya really wanna save this data ?), many mouse only operations and a whole pile of missing capacities that was much slower to use, had a lot less control and was nowhere near as reliable.

I have seen this recently with Win7 64, after years of using Win2000 then XP SP3 I had to learn where everything was again just to configure and run the new computer. I still mainly work on the XP box as it does everything without the irritations and changes in Win7. Now it seems to be both reliable and fast enough but when I want to do something trivial in PBRUSH in Win7 it has this stupid interface with a tab control with icons on it instead of the normal menu.

With XP I have a massive amount of fully tested and fully compatible software that allows me to do almost anything I need but with Win7 I have to test each piece to make sure it is compatible with the new kernel in Win7. Then it will not run the ancient WINFILE so I have to suffer the shitty explorer version which is missing the "back one dir" button so you have to fish it out from the left side directory list over and over again.

Multiply this facor for non technical users and number of applications that were compatible with Win9x, Win2000 and XP and you know why a lot of people don't want to change just because a vendor needs to keep chaning the interface to look like they have done something different.

Something like a word processor has barely changed in functionality since the 16 bit Windows days yet the interface keeps changing as does the macro language, user controls and user capacity and at a commerce level this adds up to new extra costs that many companies simply cannot affort and don't want.

[Antariy]

BogdanOntanu

Then an 64 bits CPU is usually bigger and slower than an 32 bits CPU. Contrary to popular belief decoding extra registers does take additional time and the same is valid for doing 64 bits adding and multiply and division. A bigger circuit area does generate more heat and has bigger delays.

This is version of hardware-man, and have some big reasons to be true. Nice and good thinkings!


Alex

[Antariy]

Hutch

With XP I have a massive amount of fully tested and fully compatible software that allows me to do almost anything I need but with Win7 I have to test each piece to make sure it is compatible with the new kernel in Win7. Then it will not run the ancient WINFILE so I have to suffer the shitty explorer version which is missing the "back one dir" button so you have to fish it out from the left side directory list over and over again.

Why Winfile not work under Seven? It don't supported as 16bit app, or it crashes?
Try to use [Alt]+[LeftArrow] to step one dir back, and [Alt]+[RightArrow] to step one dir forward. Maybe, this work on Seven. I work with Seven very small (~5mins :), so, I cannot give some advices...


Alex

[hutch--]

Alex,

It appears WINFILE depends on something that was only in the NT family of OS versions, I have tried copying DLLs to the directory and run it in XP compatible mode but I cannot get it to run. My Win7 64 bit runs fine and everything that is supposed to work works correctly but it appears WINFILE is simply not compatible with the Win7 kernel.

[Antariy]

Alex,

It appears WINFILE depends on something that was only in the NT family of OS versions, I have tried copying DLLs to the directory and run it in XP compatible mode but I cannot get it to run. My Win7 64 bit runs fine and everything that is supposed to work works correctly but it appears WINFILE is simply not compatible with the Win7 kernel.

Hutch, I have WINFILE from Win98. When I try to run it under WinXP - it crashes.
I attach my version. I patch it, and now it works. Also I copy needed DLLs to archive, may be, this is all needed dlls. If it not run, try to rename "_commdlg.dll" to "commdlg.dll".
When WINFILE starts, it try to direct access to disks - press Ignore, and it be works (under NT WINFILE from 98 cannot access to disks directly).
And, this version have Russian interface, sorry. I sent it to you for seeing - maybe it works. So, then you may try to copy dlls from archive to yours version of WINFILE, or try to send your version of WINFILE to me - maybe, if patching only needed, I can make it to work.


Alex

[GregL]

Then it will not run the ancient WINFILE so I have to suffer the shitty explorer version which is missing the "back one dir" button so you have to fish it out from the left side directory list over and over again.

There are the forward and backward arrows at the upper left corner of Windows Explorer in Windows 7. They move you forward and backward in the directories you have been to.  Are you talking about the "up one dir" button?

[jj2007]

When WINFILE starts, it try to direct access to disks - press Ignore, and it be works (under NT WINFILE from 98 cannot access to disks directly).

It also works when you click "Close". But in both cases the Russian menus look rather, ehm, Greek :wink

Personally I am hooked on 2xExplorer, the old (and free) version of xPlorer2, which offers a Winfile-type interface but many more tricks.

[Antariy]

When WINFILE starts, it try to direct access to disks - press Ignore, and it be works (under NT WINFILE from 98 cannot access to disks directly).

It also works when you click "Close". But in both cases the Russian menus look rather, ehm, Greek :wink

Personally I am hooked on 2xExplorer, the old (and free) version of xPlorer2, which offers a Winfile-type interface but many more tricks.

Jochen, I don't use WINFILE, I simple try to help to Hutch.

Russian looks as Greek, because your system codepage (GetACP) is Central European or Western, So - Russian text showed not as russian, because this is 16bit app, and it use ASCII, not Unicode. Change system language to Russian, and see normal menus :)

[hutch--]

Alex,

The WINFILE version is from WinNT4 with the latest being SP6a. It works OK in Win2000 and XP  but Win7 has a different kernel so after trying many attempts after copying XP DLLs over to Win7 the system DLLs have different dependencies so I had to give up.

I am used to the NT4 version of Winfile as it is a lot faster than later file managers. Part of its appeal is I run 12 to 16 partitions on most of my machines and Winfile handles that a lot better than the tree control on later versions of file managers.

[Antariy]

Hutch

Alex,

The WINFILE version is from WinNT4 with the latest being SP6a. It works OK in Win2000 and XP  but Win7 has a different kernel so after trying many attempts after copying XP DLLs over to Win7 the system DLLs have different dependencies so I had to give up.

I am used to the NT4 version of Winfile as it is a lot faster than later file managers. Part of its appeal is I run 12 to 16 partitions on most of my machines and Winfile handles that a lot better than the tree control on later versions of file managers.

What dependencies it have? Something, which not may be changed/patched/forced?
If archive with WINFILE.exe and its DLL may be attached to post - do this, please. If archive with exe and dlls too big - attach archive with exe only.


Alex