Recentely INTEL and AMD are only producing 64 bit processors.
Of course this is going to be the next step along the Software developing
process as well.
We are actually using MASM32 that is a fairly perfect tool to learn
Assembly and to dive a little into the machine code crunching.
I'd like to ask to experienced Assembly programmers like many of you are,
What kind of tools are we going to use in the next few years?
What good 64 bit assembler projects are around and specifically what do
you prefer to use for 64 bit Assembly for your personal developing projects
and work? Also you can comment why you prefer to use HLA/GOASM/MASM/...
Thanks
On a related note, I was reading recently how only 1% of Vista installs were 64-bit and how 47% of Window 7 installs were 64-bit.
GOASM is great for 64bit because you don't have to change much
invoke MessageBox,0,'hello','title',MB_OK works on both fine because it auto converts the calling convention for you, it also auto converts eax,ecx etc.. to rax,rcx. Frame is auto convereted, Donkey has a 64bit switch in the headers you can set aswell so that it auto uses the corrected structures. i'm adding a auto code converter to, to my preprocessor so I literally won't have to change anything but maybe a few things manually from 32bit code for 64bit :D haha.
The only thing missing is the 64bit SEH which jeremy says hes workin
Quote from: E^cube on July 23, 2010, 12:57:44 PM
GOASM is great for 64bit because you don't have to change much
invoke MessageBox,0,'hello','title',MB_OK works on both fine because it auto converts the calling convention for you, it also auto converts eax,ecx etc.. to rax,rcx. Frame is auto convereted, Donkey has a 64bit switch in the headers you can set aswell so that it auto uses the corrected structures. i'm adding a auto code converter to, to my preprocessor so I literally won't have to change anything but maybe a few things manually from 32bit code for 64bit :D haha.
The only thing missing is the 64bit SEH which jeremy says hes workin
I've started reading some stuff from jeremy docs, just to have an idea,
and it looks quite good and promising.
What do you mean with:
The only thing missing is the 64bit SEH which jeremy says hes workin
?
Well it doesn't have some high level directives like .if, .elseif etc... but jeremys workin on built in ones and i've written preprocessor ones which i'll release when I fix something. But in regards to session handling it changed drastically from 32bit to 64bit, instead of on the stack I believe it's an addition to the peheader. Granted if you're on xp+ you can just use AddVectoredExceptionHandler which is > SEH and regular exception handlers, greater in that it recieves crashes before the other two, and the fact you can add as many different handlers as you want!
Yes I am slowly moving towards x64. With my own written assembler that has INVOKE and .IF .ELSEIF .ENDIF and MACRO's and all other HLL goods that I need.
I am running x64 every day already.
32 bits forever !!!!!
:P
well - until after i am dead and gone, at least
Quote from: BogdanOntanu on July 23, 2010, 04:13:23 PM
Yes I am slowly moving towards x64. With my own written assembler that has INVOKE and .IF .ELSEIF .ENDIF and MACRO's and all other HLL goods that I need.
I am running x64 every day already.
My pc is X64, my OS is win7 64, but I'm not :P
Quote from: dedndave on July 23, 2010, 04:14:17 PM
32 bits forever !!!!!
:P
well - until after i am dead and gone, at least
I suppose you were involved in 16 bit assembly as well some decades
ago :bg - you never know, maybe one day you just get rid of win xp,
32 bit stuff and start moving 64 bit, even if you'd be a bit older than now :P
I'm just learning, so I have to look ahead as well while I try to put a couple
of
mov together.
QuoteI suppose you were involved in 16 bit assembly as well some decades ago
shooooooooooot - i remember the 4004 :lol (great for BCD math)
probably still have one in the shed
i know i have several 8008's
Quote from: dedndave on July 23, 2010, 05:31:30 PM
shooooooooooot - i remember the 4004 :lol (great for BCD math)
probably still have one in the shed
i know i have several 8008's
Maybe, under the hood, Hutch is working for a MASM64 package...
By the way, many young programmers are building stuff of that kind
and Microsoft will do a working ML64 someday. Stay tuned, 64 is
coming :8)
Quoteunder the hood, Hutch is working for a MASM64 package
yah - but i don't think he is going to forget us 32-bit guys :bg
Quote from: dedndave on July 23, 2010, 05:31:30 PM
shooooooooooot - i remember the 4004 :lol (great for BCD math)
probably still have one in the shed
i know i have several 8008's
Hi,
Well ya got me beat. Fairchild F8 was my first. From
the chip sheets the 8008 did not look too nice. How did
you like it?
Regards,
Steve N.
it was no pleasure - lol
thing about the 4004 and 8008 was they needed to be surrounded by a bunch of support chips to get going
there was very little large-scale integration back then
the 8080 was a little better - and, at the same time, more of the functions started appearing in LSI
things like disc controllers, USARTS, etc - in early days, that was all done with discrete logic
and - you needed a 5V power sub-station - lol - we used TTL, which was power hungry
(before TTL, there was RTL and DTL which were just as power hungry, but much slower)
Try Vacuum Tubes. I still have a few of those hidden away in a box somewhere.
Dave.
Well my first was a Honeywell 58, :dazzled: god bless me.
Now I prefer x64 and in ten years x128 as well. :P
i learned vaccuum tubes back in the 60's - lol
in fact, it was a little difficult to understand how transistors worked at first
because i was used to tubes (or "valves", as Z calls them - lol)
nowdays, i am a rare breed because i know tubage :bg
tubes are still the best for some things (old-timer opinion)
Quote from: dedndave on July 23, 2010, 11:20:48 PM
tubes are still the best for some things (old-timer opinion)
As far as I know they are still used for the best quality sound machines.
Quote from: frktons on July 23, 2010, 11:00:10 PM
Well my first was a Honeywell 58, :dazzled: god bless me.
Now I prefer x64 and in ten years x128 as well. :P
God bless ya old timer! :cheekygreen:
they are still used in high-power applications too
i used to have a 2 KW linear for ham radio - had a pair of 3-500Z's in it that glowed a nice orange if you hit them hard :P
(http://www.hamradiomarket.com/articles/Ten%20Tec%20Centurion%20Images/42201.jpg)
Very nice picture indeed :lol
Slightly larger than my Computer filpflops.
yah - and don't drop the transformer on your toe, either - lol
Cool picture. That's some good geek porn.
I have always owned a valve audio amplifier. The current one which I have owned is a 1965 Radford STA15 made by Arthur Radford in Bristol. 4 x EL34 power valves, a GZ34 rectifier and it weighs 35 pounds with all of the trasnformers built onto the chassis.
Still eats a 100 watt RMS transistor amplifier alive.
Heathkit used to make a mono amp
it was nothing to look at - lol
but it had a pair of 6146's in it for 80 of the cleanest watts you ever heard
it was a kit (of course) - and didn't break the pocket-book
i would love to have a pair of those amps :bdg
here we go - this is it, i think
(http://www.heathkit-museum.com/hifi/images/aa-121.jpg)
actually - this one has (4) 6CA7's (same as EL34)
the one i am thinking of looks very similar, but only has one knob
This is the Radford.
(http://www.radiomuseum.org/images/radio/radford_audio_ltd/power_amplifier_sta_15_series_3_430573.jpg)
i love the handles
do they imply that it takes 2 people to carry it ? - lol
I think 128-bit (we are talking about address lines here) in the next 10 years is far fetched, and in fact I think its far fetched to ever happen using traditional transistors like we do.
2^64 = 18,446,744,073,709,551,600
A volume representing this many cubic units would have to be:
(2^64)^(1/3) = ~2,642,246 units wide
So a cube with this many bits would have to be 2.6 million bits by 2.6 million bits by 2.6 million bits
In the past 10 years we have barely gone a single order of magnitude larger in typical installed memory (512 meg -> 4 gig) and I dont expect that over the next 10 years that we will go more than another single order of magnitude larger (4 gig -> 48 gig) if that ever happens...
One of the things we have done in recent times is incorporated the most space-consuming media (video) onto computers .. video has existed for a hundred years and no media that requires more space has yet to be invented .. perhaps when true 3D recording (not this stereo-vision stuff that they are calling 3D) becomes possible.... only then will there be any sort of consumer need...
How about SSE XMM0 through XMM7? (I dont know exactly what you mean by address line though)....
We may not use 128 bit numbers much however having wider registers is invaluable for data comparison/transfer
In terms of hard drive addressing I can think of *potential* applications that could be performed on BOINC style distributed computing setups with the majority of the world being online within 10 years with a little imagination
Quote from: Rockoon on July 24, 2010, 04:30:32 AM
I think 128-bit (we are talking about address lines here) in the next 10 years is far fetched, and in fact I think its far fetched to ever happen using traditional transistors like we do.
2^64 = 18,446,744,073,709,551,600
A volume representing this many cubic units would have to be:
(2^64)^(1/3) = ~2,642,246 units wide
So a cube with this many bits would have to be 2.6 million bits by 2.6 million bits by 2.6 million bits
In the past 10 years we have barely gone a single order of magnitude larger in typical installed memory (512 meg -> 4 gig) and I dont expect that over the next 10 years that we will go more than another single order of magnitude larger (4 gig -> 48 gig) if that ever happens...
One of the things we have done in recent times is incorporated the most space-consuming media (video) onto computers .. video has existed for a hundred years and no media that requires more space has yet to be invented .. perhaps when true 3D recording (not this stereo-vision stuff that they are calling 3D) becomes possible.... only then will there be any sort of consumer need...
Well, somehow this is true, but you have to consider that entrepreneurs
tend to exploit tech stuff in a different way than tech people. They just want
to sell the potential it has, even if it is not really usable for the time being.
The production of new x128 processors could not follow real need but business
need and
business is business and our world is driven by that. :P
Quote from: oex on July 24, 2010, 04:42:45 AM
We may not use 128 bit numbers much however having wider registers is invaluable for data comparison/transfer
This could be a good reason to have new and more powerful processors,
maybe with a different design to manage bit/bytes stuff in the way the
actual market requires.
:bg
Dave,
One person can lift it but you need both handles. Top box is full of transformers, all of which are masterpieces, amp has 100k range and its largely due to the excellent power transformer and output transformers. Its 10k square wave looks like a bipolar transistor profile but without the multiple harmonics on the leading edge.
I laugh at some of the old valve amps, nice warm soft slow sound, the Radford is really crisp and fast. 15 watts RMS (actually 22 watts RMS) is different to a similar transistor output, it will drive transients of much higher amplitude without clipping it as a transistor does. My 100 watt plus amps of many years ago did not outperform it and they were smartarse differential input split power supply models.
You could nearly dupliicate the result if you applied a very slight treble cut on the input side as you took the ring off the transistor models but the different harmonic structure still made them sound different.
A mate of mine bought it new here in OZ in 1966 for 120 Pounds, roughly $240.00 which was a lot of money back then.
I have a complete set of new Mullard valves for it, the EL34s, GZ34s and the small signal valves for the front end but the current set sound fine.
yah - tubes just handle large transients better
of course, transistor circuits are usually direct-coupled, which eliminates the need for expensive output transformers
i am guessing they are using push-pull circuits with the tubes
most of the old AM modulators were built the same way
it gives you a freebie reduction in odd-ordered harmonic distortion
Dave,
Its a shame you are not on this side of the world as I would like to get just a littlle maintainance done on it. My older brother is a valve era electronic man but he hates audio and he is on his way to retirement so its hard to get anything out of him at the moment. It still has 1965 electrolytic power capacitors in it which still seem to be working OK but if its left on for a long time it starts to "motorboat" on the right channel so something is going out of value. With a bit of scouring internationally you can get the high voltage bits for it but its no joy to find them.
Other thing is my oscilloscope has not been turned on for years and it would probably go BANG with the age of the capacitors.
tube circuits are actually much easier to troubleshoot than transistor circuits
that's because, with transistors, you have to do most everything with no voltage applied
tubes will take a beating, so long as the filament voltage and plate voltage are right
you can power them up and make measurements
if you do that with transistors - 9 times out of 10, you will be replacing them - and still not found the problem :bg
Quote from: oex on July 24, 2010, 04:42:45 AM
How about SSE XMM0 through XMM7? (I dont know exactly what you mean by address line though)....
What about them? 128-bit words does not mean a 128-bit processor.
Even the 8086 + 8087 could manipulate 64-bit integers (via the FPU) ..and thats a 16-bit architecture
128-bit address lines means 128-bit addressing. Able to address 2^128 ( = 3.4E+0038 ) bytes.
We didnt call the 80386 a 32-bit machine because it could manipulate 32-bit words. We called it a 32-bit machine because its memory bus pointers were 32-bits in size, capable of addressing 2^32 individual bytes.
With the advent of the Pentium MMX, we could manipulate 64-bit words natively. That didnt make it a 64-bit architecture. It still only had 32-bit pointers.
The AMD64 architecture has 64-bit pointers. It can conceivably address 2^64 bytes of memory. It also has 64-bit words, but it could just as easily have 128-bit words, or even 256-bit words. It would still be a 64-bit architecture.
Quote from: frktons on July 24, 2010, 05:05:32 AM
Well, somehow this is true, but you have to consider that entrepreneurs
tend to exploit tech stuff in a different way than tech people. They just want
to sell the potential it has, even if it is not really usable for the time being.
That reasoning would have brought about 64-bit computing, but it didn't. It is only recently that 64-bit addressing has become marketable.
I think many people are unfamiliar with how long we stood in the 32-bit world. The 80386 came out in 1985, and before that we were using a 20-bit architecture. That push from 20-bit limits through to the 32-bit limit took more than several decades.
At the time many people ran a 20-bit OS (DOS and then 5 years later Windows 3.0) just like many people run a 32-bit OS today even though they have a 64-bit machine.
It is so 1990 all over again. I personally ran XP/64 for years and it is only now, two whole major OS version later, that 64-bit OS's are just starting to take over.
I personally rely on Valve's hardware surveys to get a good grasp of the market. The surveys are taken via their Steam gaming platform, but it isnt just a top-end sampling by any stretch. Most steam games run on 8 year old hardware just fine.
Win XP 32-bit: 32.99%
Win 7 64-bit: 26.65%
Vista 32-bit: 14.01%
Win 7 32-bit: 12.07%
Vista 64-bit: 6.75%
Win XP 64-bit: 0.56%
Win 2003 64-bit: 0.32%
The remaining %'s are for MacOS.
2GB of ram is still the most common configuration.
Win XP 32-bit: 32.99% :U
i would have thought more, actually
there are so many mom and pop computers in the world
they check their e-mail and play solitaire, and that's about it - lol
but, there are millions of them
Quote from: dedndave on July 24, 2010, 04:47:14 PM
Win XP 32-bit: 32.99% :U
i would have thought more, actually
there are so many mom and pop computers in the world
they check their e-mail and play solitaire, and that's about it - lol
but, there are millions of them
And most of them have probably purchased a new laptop sometimes since the release (January 2007) of Vista :)
These same people buy new machines because their computer is virus infested, and you know how bad Windows XP is for grandma in that regard!
Quote from: dedndave on July 24, 2010, 04:47:14 PM
there are so many mom and pop computers in the world
they check their e-mail and play solitaire, and that's about it - lol
but, there are millions of them
These arent counted in this index this is the gamers index.... While you'll find all sorts of wild claims as to what an 'average gamer' is many people will have multiple computers and rarely use many of their capabilities:
http://gigaom.com/2010/02/17/average-social-gamer-is-a-43-year-old-woman/
Further there is the assumption that Steam has equal worlwide appeal.... In reality computer specifications are far from evenly spread with the US and UK having many orders of magnitude higher general unused processing power than other poorer countries
QuoteThese arent counted in this index this is the gamers index
that makes a huge difference
you must assume that a large percentage of the world population are neither gamers nor programmers :bg
they usually don't have "the best stuff" - lol
many are using the second-hand computers that were sold after someone else upgraded
because, that is all they can afford or, in many cases, justify spending
as for the average gamer being a 43-yr old woman - that has got to be a skewed statistic
you are talking about little old ladies that have "farms" on facebook - lol
when i think of "serious gamers", i think of a male in 20's or early 30's that plays interactive "combat" or RPG type games
these are the guys that spend the extra bucks for 64-bit machines and graphics adapters that require their own fan
Quote from: Rockoon on July 24, 2010, 03:05:22 PM
That reasoning would have brought about 64-bit computing, but it didn't. It is only recently that 64-bit addressing has become marketable.
The reverse is what I meant. We had 64 bit processors well ahead of their
real use [64 bit OS and applications]. So we could have 128 bit processors in the same way.
There is no need and no applicable area, but they can be sold nevertheless.
Quote
I think many people are unfamiliar with how long we stood in the 32-bit world. The 80386 came out in 1985, and before that we were using a 20-bit architecture. That push from 20-bit limits through to the 32-bit limit took more than several decades.
Actually we are using a 40 bit addressing architecture, if I correctly recall,
the 64 bit are not fully used, but it could have changed without INTEL informing me :lol
We should consider that things tend to speed up a little in tech field, so instead
of 25 years the next step could take less :P
Quote
I personally rely on Valve's hardware surveys to get a good grasp of the market. The surveys are taken via their Steam gaming platform, but it isnt just a top-end sampling by any stretch. Most steam games run on 8 year old hardware just fine.
Win XP 32-bit: 32.99%
Win 7 64-bit: 26.65%
Vista 32-bit: 14.01%
Win 7 32-bit: 12.07%
Vista 64-bit: 6.75%
Win XP 64-bit: 0.56%
Win 2003 64-bit: 0.32%
Considering Mac, Linux and others 64 bit OS we are at about 50% user/server market.
Don't you think in the next 10 years we are going towards bigger figures?
So the original question and the title of the thread:
Are we going to 64 bit Assembly?could be easily replied:
yes, we can in Obama style, or whatever you like. :lol
You could just as easily say "are we going to multi-threaded assembly?" If you want, go for it.
ML64 is going back to the days of masm version 1 - basic functionality (no invoke, which pisses off a lot of people).
I like the bare-bones approach of ml64 for writing win64 programs, but I also use fasm for non-win64 things.
We will see 16-bit DOS/win3 programs dying off, because long mode won't support v86 mode, but 32-bit programs
won't die for a long time.
I think we're up to 53-bit addressing now aren't we? And if you add the win7's together they beat xp :P
Quote from: sinsi on July 25, 2010, 07:30:50 AM
ML64 is going back to the days of masm version 1 - basic functionality (no invoke, which pisses off a lot of people).
Maybe somebody could write a simple pre-processor that would take in a MASM source file containing invoke instructions, and do nothing except spit out a file that translated the INVOKE to its equivalent lower-level instructions...
Then a person could call the pre-processor, followed by ML64.
Quote from: sinsi on July 25, 2010, 07:30:50 AM
You could just as easily say "are we going to multi-threaded assembly?" If you want, go for it.
ML64 is going back to the days of masm version 1 - basic functionality (no invoke, which pisses off a lot of people).
I like the bare-bones approach of ml64 for writing win64 programs, but I also use fasm for non-win64 things.
We will see 16-bit DOS/win3 programs dying off, because long mode won't support v86 mode, but 32-bit programs
won't die for a long time.
I think we're up to 53-bit addressing now aren't we? And if you add the win7's together they beat xp :P
Yes, we could :P
ml64 needs some renovation, and Microsoft is going to use it for his 64 bit stuff.
Probably new versions will be shipped as Microsoft feels the need for them.
If not, we have
FASM ,
GOASM and a few more suitable packages.
Well, win-XP is not going to survive more than 5 years, except on Dave's valve computer :lol
Quote from: cork on July 25, 2010, 07:54:40 AM
Maybe somebody could write a simple pre-processor that would take in a MASM source file containing invoke instructions, and do nothing except spit out a file that translated the INVOKE to its equivalent lower-level instructions...
Then a person could call the pre-processor, followed by ML64.
yes, a person could after somebody write it.
I guess Microsoft itself has enough persons and somebody
to do that.
And many others are capable to do that as well, or have already done it.
Quote from: sinsi on July 25, 2010, 07:30:50 AM
I think we're up to 53-bit addressing now aren't we? And if you add the win7's together they beat xp :P
It depends on the chip and motherboard.. the architecture itself is capable of addressing 2^64 bytes of memory even if the hardware isn't..
...much like the first 80386's couldn't be loaded with 4 gigs of ram (4 megs was probably your max) that in no way means that the architecture didn't support it. It just means that those address lines werent connected to anything.
Quote from: Rockoon on July 25, 2010, 01:12:23 PM
It depends on the chip and motherboard.. the architecture itself is capable of addressing 2^64 bytes of memory even if the hardware isn't..
...much like the first 80386's couldn't be loaded with 4 gigs of ram (4 megs was probably your max) that in no way means that the architecture didn't support it. It just means that those address lines werent connected to anything.
Yes Rockoon, we are not fully using 64 bit so far, but we are going that way I guess.
You never used a C/C++ compiler, did you?
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using oneThat's so funny, I'm just learning C for the time being. :P
Quote from: frktons on July 25, 2010, 01:58:14 PM
Quote from: Rockoon on July 25, 2010, 01:12:23 PM
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one
That's so funny, I'm just learning C for the time being. :P
That jab is specifically at C++ "intrinsics" ..
C/C++ fanatics first claim that their compilers are better than ASM programmers, and when shown that this isnt true (as is easily demonstrated with even sloppy SIMD code), they claim that intrinsics extensions in the various compilers put them on a better footing with SIMD than the C++ standards themselves would allow
So I am pointing out that am still unaware of any C++ compiler than will ever emit an RCL or RCR instruction under any circumstances other than with actual inline assembler. No RCL or RCR intrinsics are possible because there is no concept of a 'flags' register in the C/C++ abstract machines, and no C/C++ expression can clue the compiler in enough to leverage RCL or RCR either.
I dont use C/C++ because there is always a better choice for my needs. For RAD it was VB6, and for one-off computations its been VB.NET console applications.. all can be augmented with ASM. I use ASM for libraries, not applications. C/C++ doesnt buy me anything I need.
Quote from: Rockoon on July 25, 2010, 02:36:10 PM
That jab is specifically at C++ "intrinsics" ..
C/C++ fanatics first claim that their compilers are better than ASM programmers, and when shown that this isnt true (as is easily demonstrated with even sloppy SIMD code), they claim that intrinsics extensions in the various compilers put them on a better footing with SIMD than the C++ standards themselves would allow
So I am pointing out that am still unaware of any C++ compiler than will ever emit an RCL or RCR instruction under any circumstances other than with actual inline assembler. No RCL or RCR intrinsics are possible because there is no concept of a 'flags' register in the C/C++ abstract machines, and no C/C++ expression can clue the compiler in enough to leverage RCL or RCR either.
I dont use C/C++ because there is always a better choice for my needs. For RAD it was VB6, and for one-off computations its been VB.NET console applications.. all can be augmented with ASM. I use ASM for libraries, not applications. C/C++ doesnt buy me anything I need.
Well, I've heard something like compilers are better than programmers, but I didn't buy it. :P
This is an old, unsolvable debate that I don't like to join anyway.
I had the idea that interfacing C and MASM was one of the preferred way to get system job
done, and easily done as well. ::) These two languages are supposed to interface easily with each other.
I'm a bit curious, if you don't mind, about what language you are using to interface Assembly
and how easy/productive this mixed language programming is in your opinion.
I think you are crazy if you thirst for 64biz.
The only reason for to be dead keen on 64biz can only have one reason: the disability to develop reasonable algorithms in the environment which is given.
See the "C" programmers some years ago: at that time they cried for 32bits because they were unable to declare unsigned 16bit values in there overloaded inefficient "C" programs.
Nowadays these same stupid "programmers" are unable to manage the meanwhile very versatile contrived 32bit environment so they cry for the next 64biz hop. And all these stupid gamerz will confirm this rule...
Quote from: TASMUser on July 25, 2010, 11:16:21 PM
I think you are crazy if you thirst for 64biz.
The only reason for to be dead keen on 64biz can only have one reason: the disability to develop reasonable algorithms in the environment which is given.
See the "C" programmers some years ago: at that time they cried for 32bits because they were unable to declare unsigned 16bit values in there overloaded inefficient "C" programs.
Nowadays these same stupid "programmers" are unable to manage the meanwhile very versatile contrived 32bit environment so they cry for the next 64biz hop. And all these stupid gamerz will confirm this rule...
I'm learning C and Assembly, and I use a X64 bit machine with a win7 64 bit.
I guess it is natural to think about 64 bit. The C compiler I use "Pelles'C" is a
64 bit compiler, so while I learn I also ask myself what are the differences, and
why if I compile a C program in 32 bit mode it is slower than the same C
program compiled in 64 bit mode?
By the way, I am neither crazy nor thirsty for 64biz, just naturally curious. :P
:bg
Frank, in answer to your original question YES but don't hold your breath waiting. Its like watching paint dry and well written 32 bit is fast.
Quote from: hutch-- on July 26, 2010, 04:20:10 PMwell written 32 bit is fast.
In fact, there seem to be very few cases where 64-bit code beats 32-bit code. I wonder what is the role of the code and memory caches in this.
Quote from: hutch-- on July 26, 2010, 04:20:10 PM
:bg
Frank, in answer to your original question YES but don't hold your breath waiting. Its like
watching paint dry and well written 32 bit is fast.
Thanks Hutch. Of course it's better to breathe. :U
Fortunately enough I don't have to code anymore for living, and I keep a relaxed attitude
towards IT stuff, and
learning for FUN.
Time is short, neurons are fewer than once, so I like to go slowly trying to make faster
code. What a nonsense :lol :P Really funny, worth doing :8)
Quote from: jj2007 on July 26, 2010, 05:16:00 PM
In fact, there seem to be very few cases where 64-bit code beats 32-bit code. I wonder
what is the role of the code and memory caches in this.
Me too, I'd like to understand why the few progs I compiled in 64 bit mode with
Pelles'C compiler are about 20% faster than the same progs compiled in 32 bit mode ::)
Those are C program by the way.
Quote from: jj2007 on July 26, 2010, 05:16:00 PM
I wonder what is the role of the code and memory caches in this.
If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.
-r
Quote from: redskull on July 26, 2010, 06:45:01 PM
Quote from: jj2007 on July 26, 2010, 05:16:00 PM
I wonder what is the role of the code and memory caches in this.
If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.
-r
That's my theory, too. Unfortunately, I can't test it :bg
If everything but the cache is twice as big...
Quote from: frktons on July 26, 2010, 12:45:32 AM
I'm learning C and Assembly, and I use a X64 bit machine with a win7 64 bit.
I guess it is natural to think about 64 bit. The C compiler I use "Pelles'C" is a
64 bit compiler, so while I learn I also ask myself what are the differences, and
why if I compile a C program in 32 bit mode it is slower than the same C
program compiled in 64 bit mode?
Frank, if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done. As 16bit progs run slow on NT (and hang Win9x :), 32bits run slightly slow under 64bits OS, too.
Alex
Quote from: Antariy on July 26, 2010, 10:06:49 PM
Frank, if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done. As 16bit progs run slow on NT (and hang Win9x :), 32bits run slightly slow under 64bits OS, too.
Alex
Thanks Alex for the explanation. This have to be one of the reasons X64 bit machine and 64 bit OS
like more 64 bit applications. :lol
Quote from: Antariy on July 26, 2010, 10:06:49 PM
if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done.
Very well explained, thanks Alex. Of course, the marketing will say "look, 64-bit apps are faster" - and you cannot prove the contrary because you cannot make a 64-bit app run on a 32-bit OS.
I wonder if this comparison would be valid, for the same identical 64-bit processor:
Quotexx cycles for App32 on OS32
xx cycles for App32 on OS64
xx cycles for App64 on OS64
Quote from: redskull on July 26, 2010, 06:45:01 PM
Quote from: jj2007 on July 26, 2010, 05:16:00 PM
I wonder what is the role of the code and memory caches in this.
If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.
-r
but all things arent twice as big on the AMD64 design (which intel also uses)
The native machine word is still 32-bit. It is only pointers that have been forced larger.
So some data structures, such as pointer heavy linked lists and trees, are negatively effected, while others.. like hash tables and other pointer-less structures, arent effected at all.
32-bit programs recompiled (that is, using a compiler) for 64-bit are usually faster because there are over twice as many registers for the compiler to work with. Thats a big win in non-trivial algorithms which otherwise would be moving local variables to-and-from L1 a lot.
WOW64 doesnt add much overhead. All that overhead is on folder virtualization (redirecting /system32 to /syswow64) .. the overhead is in front of slow disk operations so really cant be effectively measured without writing code so absurd that it would never pass a code review.
The meaningful negative effects are all about the larger pointers.
it seems like, when you double the architecture width, you need to quadruple everything else
4 times as much RAM
4 times as much disk space
Quote from: Rockoon on July 28, 2010, 01:55:18 AM
The meaningful negative effects are all about the larger pointers.
Agreed, but high-level languages are notorious for being pointer-heavy. C++ objects come almost exclusively from the heap, you have to use pointers to get inheritance, STL containers, etc, etc. Lord knows how Java works, but I suspect it's pointer-centric as well. More reasons to use ASM, of course!
-r
Something we should take into account is that 64 bit tech and software
are relatively new. Many things are not still stable nor optimal.
The only hope is that, being it the de facto modern tech everybody
uses or is going to use, it'll get more stable and optimal as time passes by.
People who have to take care of legacy code are going to stick to 32 bit
programming for some more years. The "free from legacy code" people
like me, can look at the future with a more relaxed attitude, hoping for
the better, and jumping from a tech to the other to have a look at what's
happening around. :P
32-bit will be here for a long, long time, just for that reason: legacy DOS code. I know several businessess (and have worked at many, too) that simply just can't upgrade to 64-bit versions of Windows, because their tangled web of software has some critical dependency on some tiny DOS program that was written by a company that's now out of business. As long as 64-bit Windows doesn't have some easy, streamlined way to run 16-bit DOS programs (even if it's done in software), I wager it won't be adopted en masse in the business world.
-r
Quote from: jj2007 on July 27, 2010, 10:07:56 AM
Quote from: Antariy on July 26, 2010, 10:06:49 PM
if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done.
Very well explained, thanks Alex. Of course, the marketing will say "look, 64-bit apps are faster" - and you cannot prove the contrary because you cannot make a 64-bit app run on a 32-bit OS.
I wonder if this comparison would be valid, for the same identical 64-bit processor:
Quotexx cycles for App32 on OS32
xx cycles for App32 on OS64
xx cycles for App64 on OS64
Sorry, Jochen, I not very good understand you. One good man help me to understand, what you don't say sarcastic.
I don't have 64bit CPU and OS for playing, but by my work I have "touched" with many-many computers.
You remember, how "nice" you format diskette under Win9x? Because 16bit implementing of these systems is awesome.
On 64-bit OS, to 32bit program, available more than 3.5 GB of memory. This is tested on one notebook with x64 CPU and Windows 7 x64 Edition.
Prog, which allocate pieces by 25.6 MB, get 150 these pieces. So - 3.75 GB. If pieces smallest, may be allocated more.
No bad reason: give to 32bit app nearly 4GB of memory on 64bit OS, right? On 32bit systems, to app available <2 GB usually, and <3GB with /3GB switch (I mean XP and 2003).
If you can test 64bit app on 32bit CPU - you grandmaster Yoda, not less! :)
Alex
About Jochen's:
Quote
.... and you cannot prove the contrary because you cannot make a 64-bit app run on a 32-bit OS.
I don't like WinAPI calling sheme on Win64. Those scheme is no good. Many actions with RSP, some demands (align of RSP) and preserving space for args before calling. For which need fastcall convention, if it make
fastcall slower/equal that
stdcall?
Alex
As with old 16 bit code, in years to come, the disadvantage of 32 bit programming
versus 64 bit programming will become more and more evident. New OSes will run
64 bit code faster and better, and the same will not be true for 32 bit. As I forecast
the market will push everybody towards 64 bit programming, no matter what.
Actually the market is pushing towards 64 bit machines and OSes. Is it that strange
that next generation programming will be 64 bit?
Quote from: frktons on July 30, 2010, 07:58:03 AM
As with old 16 bit code, in years to come, the disadvantage of 32 bit programming
versus 64 bit programming will become more and more evident. New OSes will run
64 bit code faster and better, and the same will not be true for 32 bit. As I forecast
the market will push everybody towards 64 bit programming, no matter what.
Actually the market is pushing towards 64 bit machines and OSes. Is it that strange
that next generation programming will be 64 bit?
Nope. Look at how much legacy win16 code is out there, that's why OS's come in 32 and 64 bit.
All 64-bit code is, the OS makes sure the selectors are set for long mode, the same process happens for 32-bit code except for that 1 bit.
Still have to setup the ldt, page tables etc.
64-bit is great for the extra registers and an assumed minimum level of SSEx as well as the address space.
The calling convention for win64 is ludicrous though...as I always complain :bg
Quote from: sinsi on July 30, 2010, 08:14:10 AM
Nope. Look at how much legacy win16 code is out there, that's why OS's come in 32 and 64 bit.
All 64-bit code is, the OS makes sure the selectors are set for long mode, the same process happens for 32-bit code except for that 1 bit.
Still have to setup the ldt, page tables etc.
64-bit is great for the extra registers and an assumed minimum level of SSEx as well as the address space.
The calling convention for win64 is ludicrous though...as I always complain :bg
16 bit code is running in "compatible mode" under 32 bit, and 32 bit code is running in "compatible mode"
under 64 bit mode. This is what I mean. Hardware is already 64 bit. old applications run on "virtual machines"
losing some speed and efficiency. If you run 8 bit code in "virtual machines" it doesn't mean you are at the
top of market thoughts. :P
Legacy code is important, this is the only reason it still runs on modern OSes and CPUs. But legacy tend to
diminish and change over time :P
Quote from: frktons on July 30, 2010, 08:59:28 AM
But legacy tend to diminish and change over time :P
Man, do I wish I worked at your job. I find things are just the opposite; people latch onto their legacy 16-bit apps, and outright refuse to change. Accountants refuse to spend money to upgrade software "which still works fine". Programmers create "new" applications by copy and pasting existing 16-bit code to get programs finished ASAP and managers off their backs. People lost the source to that antique, undocumented software written by a consultant 20 years ago that's now irreplaceable because the guy who wrote it went through a bad divorce and killed himself. We can't upgrade that payroll code that's written in Qbasic because Joe used to come in hungover and name every variable foo1, foo2, etc, and then got fired for banging the bosses daughter. Those half-million lines of C-code can't be refactored because there isn't enough manpower to rewrite the old code *and* add new features, and the CEO will stomp the floor if he doesn't see any results. And so on.
-r
:bg
red,
Sounds like you are having PHUN there. I have heard most of these over time but the one that always made me laugh was someone with a pile of old QBASIC cobbled together by a family member 20 years ago offers you the chance to evaluate then rewrite this pile of crap. Strange when they are disappointed by your lack of interest unless they want to specify the design requirements and PAY for it.
Quote from: redskull on July 30, 2010, 12:32:34 PM
I find things are just the opposite; people latch onto their legacy 16-bit apps, and outright refuse to change.
-r
Cute description :bg
You could add that these apps were written for slooooow hardware, and are therefore amazingly fast on a modern CPU...
I'm not sure which is worse; moron users or obsolete programmers. It's always been amazing to me that non-technical users would rather have what's familiar, even though it's ridiculous, complex, and hard to use, rather than learning something new that's better. One time I realized that one of the prompts the data entry drones had to fill in could be automatically retrieved from data elsewhere, so I went ahead removed that prompt, thinking I would get a nice 'attaboy' for making everyone's life easier. Moments later, I had an office full of secretaries who wanted my head on a pike, because they were just so used to typing in that data that removing it threw their entire universe out of tilt.
And then there's the relic programmers, who still think Windows and object oriented programming is some flash in the technology pan. We have an embaressing large amount of "background network programs", which are really DOS programs that stay open and scan a hardcoded directory for a file every three seconds; if another program outputs that file to that directory using a mapped drive, the first one springs to life and does whatever is has to. When i offered to rewrite these as actual windows services that use sockets for communication, I was told that "we don't go for those trendy hi tech fads here". I wish i was kidding, but I work for a $10M a year company, and you can open any of our cash register drawers in the country by sending a carefully worded email to a particular address. Really.
fuck my life :'(
-r
I had my fair share of that crap some 30 years ago. Now thanks to God I'm almost
free from that nightmare. Now I just learn Assembly for FUN, and I can dream 64
bits, modern pc and OS, without having some nasty boss behind my shoulders taking
me back to the hard reality. :P
Quote from: Antariy on July 30, 2010, 09:59:25 PM
But, a priory, I may to say, what 32bit app cannot be runned in 64bit mode with folders redirection only. Simple, because 64bit mode don't have (have, but use as another) some instructions, for example "push cs". Not very used instruction, but... :)
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.
Quote from: Antariy on July 30, 2010, 09:59:25 PM
And, if 32bit app call to imported API, it called by address, which lies in 32bit range. So, in range of first 4GB must exist thunking code - to 64bits system.
You dont seem to understand. There is
no thunking in 64-bit windows. 64-bit code cannot call 32-bit code, or vise-versa.
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.
The transition from 16-bit to 32-bit used thunking mechanisms to allow in-process mixing of 16-bit and 32-bit code. Win64 does not allow any in-process mixing.
Quote from: Antariy on July 30, 2010, 09:59:25 PM
For memory-management functions thunking code must done more things - alloc only in 32bit range, have table of allocations, and check it - what if all in 4GB space be allocated, etc.
So, if I don't mistaked, memory management under 64 for 32bit must be slower (not very).
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.
Protected mode and Long mode allow 4K pages to be swapped around by simply manipulating an internal pointer, that further each process can have its own ordering, and so forth.
Quote from: Antariy on July 30, 2010, 09:59:25 PM
One of probable ways, how Microsoft done 32-to-64 thunking - with using RPC.
This mechanism is very used on all NT's. For example, when you call "WriteConsole[A/W]", progs run call to csrss.exe (Client-Server Run-time SubSystem).
This mechanism is used on both 32-bit and 64-bit OS's. Inter-process communications hasnt changed.
Quote from: Antariy on July 30, 2010, 09:59:25 PM
About AMDs' x64 extensions: it looks as very fastly developed and launched stuff, because many things looks as not very thinked-over.
How so? If it was just a rush to market, they wouldn't have obsoleted instructions in Long mode.
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.
RockoonQuote
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 :)
Quote
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)?
Quote
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 :)
Quote
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.
Quote
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.
Quote
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.
Quote
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 :)
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.
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.
BogdanOntanuQuote
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
HutchQuote
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
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.
Quote from: hutch-- on August 02, 2010, 11:19:52 AM
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
Quote from: hutchThen 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?
Quote from: Antariy on August 02, 2010, 08:18:29 PM
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 (http://netez.com/2xExplorer/), the old (and free) version of xPlorer2 (http://zabkat.com/x2facts.htm), which offers a Winfile-type interface but many more tricks.
Quote from: jj2007 on August 02, 2010, 10:56:17 PM
Quote from: Antariy on August 02, 2010, 08:18:29 PM
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 (http://netez.com/2xExplorer/), the old (and free) version of xPlorer2 (http://zabkat.com/x2facts.htm), 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 :)
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.
HutchQuote from: hutch-- on August 03, 2010, 03:28:35 AM
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