Quote - Exactly the same limit as for 32 bit processors!!!!

No it isn't.  The limit for 32 processors is 4GB.  Even a 16 bit segment and a 32 bit offset still translates to a 32 bit linear address.

kawecki - Did you disassemble the resulting binary correctly?  Some disassemblers default to 16 bit unless you specify otherwise.  (also what operating system are you running under?)

There is no need for far procedure calls under Win32, as everything fits under the linear 4 GB address space in a single segment.  Segmentation doesn't even extend the address space because you are still limited to a 32 bit linear address.  (under 16 bit, segmentation was the only way to address memory past 64K, which was too small an amount even way back when.  8086 real mode calculated the linear address by segment * 16 + offset; the 80286 allowed up to 16 MB of physical RAM to be addressed, but only in segments of 64 K.  The 386 extended the address space up to 4 GB and added 32 bit mode as well.  From the 386 onward, the maximum segment size for 32 bit mode was the same as the linear address space).

Furthermore, in protected mode, the privilege level is determined by the code segment selector.  Being able to call into another segment could allow a process to elevate its privilege level, which is a clear no-no.

Besides, all this would result in a great increase in complexity which is simply not necessary.  Simply mapping a DLL into the address space of a process that wants to load it is all that is needed.

It is also not possible to extend the address space past 4GB under 32 bit mode, as linear addresses are 32 bits, period.  There is something called PAE (physical address extensions), which has existed for awhile that allows for up to 64 GB of physical RAM to be installed in a system, though any one process is still limited to addressing 4GB of that.

64 bit systems don't use the entire 64 bit address space (yet).  I think that Vista only uses 40 bits of it, for up to 1 TB of addressable memory per process (an amount unlikely to be exceeded in Vista's operational lifetime).

Quote - Hm. I run XP64 on an AMD64x2. No problems at all.
Driver support for XP64 isn't perfect, to say the least. My system is all out nVidia, which certainly helps - nVidia has good solid XP64 drivers for both their chipsets and graphics.

I seem to remember something not working properly when I tried XP64 (the trial version).  It was awhile ago, and things might have improved.

Actually, if I remember correctly, the problem was with antivirus software.

Quote - More I read, more bigger are my doubts if XP64 or Vista64 runs under 64 bit mode.

As much as I wouldn't put it past Microsoft to try something stupid like that, what you are talking about is not possible.

Quote - FACT #1
All the Wndows DLL function calls are performed by means of the instruction **CALL SEGMENT:ADDRESS
**

I am pretty sure that that is NOT the case, as far procedure calls are privileged instructions and cannot be executed in user mode.

Functions in a DLL are loaded into the process's address space at runtime, and are accessible just like any other.  call address works the same way whether or not what is located at address was loaded into memory when the program was loaded by the operating system, or later on as the result of loading a DLL.

The reason that a 64 bit program cannot link to a 32 bit DLL (and vice versa) is that you can't combine 32 and 64 bit code within the same process (as the processor can only be running in one mode at a time, and that mode can only be switched from ring 0.

Certain DLL's would have to exist in both 32 and 64 versions, but they can easily be compiled both from the same source code, changing only compiler options.

Pretty much the extent of 16 bit code still seen today is in installer stubs that inspect the operating system environment; and where it detects the operating system is only 16 bit (i.e., DOS or Windows 3.1, informs the user that the application requires a 32 bit version of windows, and exits).  Including 16 bit support as well would just make the operating system even larger, and for no appreciable benefit.  (People may cry "forced upgrade", but anyone who is still actually using 16 bit apps for anything probably isn't going to be upgrading to Vista, and probably isn't even using XP either).

Quote - Need more companies to take on MS for an OS. More competitions, less costs.

There's the old saying: "It's the software stupid".  The main reason why PC's running windows are so ubiquitous and make up the vast majority of all (home) computer systems, despite other platforms being arguably superior from a technical standpoint.

Right now the only platform that runs Poser, Bryce, Carrara, and all my games is Windows, so I'm stuck using that.  I have an AMD64 processor, but I'm stuck on a 32 bit system because support for XP64 blows (probably intentionally), and I'm not going anywhere near Windows Virus-ta.

Maybe once ReactOS is stable enough to be used as an everyday system Micro$oft will finally get smart if they want to continue to be able to market Windows to anyone other than the most technologically illterate of computer users.

In order to run 32 bit code (under a 64 bit operating system), you have to actually switch the processor into 32 bit mode while that process is running.  Windows (XP-64 and Vista 64 bit) handle this automatically, switching to the proper processor mode when switching to another process and then switching back.

It's the same thing with running 16 bit processes under 32 bit windows; the operating system handles all the necessary mode switches automatically.  Probably the main reason that 64 bit windows can't handle 16 bit code is probably because the added complexity it would entail isn't worth it, considering that 16 bit is about as obsolete as it gets.

The advantage to 64 bits over 32 bits is the greatly increased address space.  Under 32 bits, a process is limited to 2 GB of memory (3GB with the proper kernel switches and the application relinked to work with it), no matter how much RAM you have installed.  It doesn't even matter how much swap space you have or are willing to use, you can only address 4GB with a 32 bit pointer, and the kernel takes up 2GB of that.

The x86-64 also adds an additional 8 registers (available only in 64 bit mode) to an architecture that is sorely lacking in registers.  (Which even so still only gives it half the architectural registers that most RISC architectures have).

Quote - Depending on the mediaeval village forget above 30s, they all are dead!

At the age of fourteen, he was a married man
At the age of fifteen, the father of a son
At the age of sixteen, his grave it was green

That wasn't QUITE true (though wars and plagues were certainly a frequent cause of early death).  IF (and that was a very big IF) you survived infancy and early childhood, you stood a pretty decent chance of making it to at least 60 or 70, even back then.

The primary reason for the great increases of life expectancy in the 20th century was the dramatic reduction in infant mortality.  If half of all babies that are born die before their 5th birthday, that is going to grossly skew the average life expectancy downward.

Quote - > Quote - I've got Poser 7 loading as I type this on a Vista test machine (at work).  So far, I'm annoyed by the constant "Are you sure you want to..." pop-up messages. 

 

Yes, the User Account Control in Vista is perhaps the most annoying thing Microsoft has ever introduced.  Fortunately, it can be turned off.

Welcome to the world of UNIX/Linux.  Possibly the one single positive feature of Vista is that it is actually feasible to run Windows with limited user privileges and switch to super user mode only when necessary.  Such has been standard procedure in the Unix world for years.  (Under Ubuntu, you can't even "log in" as a superuser, you use the "sudo" command for anything that requires superuser access).

The upside is that your computer is significantly more secure because much malware will not be able to do whatever it is it's trying to do because it won't have the necessary permissions to do so.  (And when you get a pop-up that says that Gator is trying to install itself, you can click no to prevent it).

Though poorly written software is probably going to make it a bitch at times.  (For YEARS now Windows programs have been doing things that would make them require higher levels of access than they should need.  i.e., storing data in the Program Files directory, something that should be a no-no, as for a limited user to write to anywhere in that folder is supposed to be absolutely forbidden).

Quote - It was a consideration because it was one of the top complaints from the Community Survey (this past year and the year before it)by members and that is what the survey is for, to see thoughts/suggestions of members taking the survey. 

Top complaint, by what percentage of this site's membership?  Because it's mostly the people who want the change who are going to speak up.  The people who don't have a problem with nudity (or just nudity in thumbnail previews) probably aren't going to bother to say "Oh, by the way, I think that nudity in thumbnails should remain acceptable under the TOS."

So if something like 25% of the members of the site complain about nudity in thumbnail previews, and the rest of the site's membership is completely silent on the issue, what does it really mean?

Quote - True, but, as I said earlier...had there been no bitching, I'm willing to bet every drop of blood in my body that it would still be up there.  Supid policies come into place when pepole can't use their common sense.

He was pointing out a certain double standard.  If Rendo admin had any sense they would have come to their senses and realized how stupid the new thumbnail policy actually is.  Instead, they decided that their idiotic new policy was so sacrosanct that even Leonardo now has to comply with it.

Put I guess puritanical prudery trumping art is the new norm in today's society :cursing:

Maybe instead of filtering nudity, we should filter out the prudes who have a problem with the human body.

This is REALLY getting rediculous.  When you go and censor Leonardo da Vinci, that's when you've really gone off the deep end.

I'm sure the admins will spot their mistake and quickly take it down :rolleyes: 

There has to be a number of works out there that have to be considered among the great masterpieces in the history of art, that would be banned completely from this site.

Then of course you have certain brain-dead prudes who think that any depiction of the unclothed human form whatsoever is pornography (and should be banned).

Implementing a policy of censorship tends to stir things up.

Quote - We have been discussing this and getting everything in place for a lot longer than that..  When a policy change is made it doesn't happen overnight at all, it is discussed and planned out for a lengthy period of time.  

Obviously not long enough to figure out what a stupid idea it was.

Here's an idea - and one that should have been thought of and implemented eons ago - have the thumbnail be a downsized version of the original image, so that a viewer knows exactly what he is getting when he clicks on it.  Instead of having people waste their time opening up a boring image that the artist managed to create an interesting thumbnail preview for, or missing an image they would have liked because the thumbnail wasn't interesting enough in itself; and even further complicating matters with this stupid, retarted new thumbnail policy.

And if someone doesn't wish to see nude thumbs, they can configure their settings so that they, along with the original image, remain hidden.

Quote - I mean really what if too many thumbnails  fail to meet the requirements and Renderosity is forced to either change the rules back to the way they were or remove nudes from the gallery.

Sure this is speculation but how far is it from what could happen.

Or what they plan on having happen someday.  (Of course, you can tell which direction they would go next)

Also, need I mention the irony that the new standards for thumbnails are in fact more stringent and prudish than many beaches around the world?

Oblivion uses DirectX.

If other OpenGL apps seem to work fine but Poser 7 consistently crashes, then it could be something to do with the app itself (it's clear that thing still has a few bugs that need to be fixed).

If you get the same problems even when you are running your video card at the stock speed, then it's not even the overclocking that's causing it, just Poser 7's bad programming.

Though it's probably the case that nVidia deliberately rates their 7600 parts at lower speeds than they're actually capable of so they don't compete with their higher-end 7900 parts.