#Windows NT & 3ds
49 messages in this thread
Will the new Release of 3DS be for NT only? I was planning to get
Windows 95, but now am wondering if I should get NT. How much is it?
I have not even heard AutoDesk say that they are Offically developing
an NT or '95 version. If it will run on Windows '95 and it has a
"Windows" sticker on it it will run under NT. I run NT and I love it
Autodesk said that it will be avalible after Siggraph. As for
running under win95, if they dont make any multi-thread calls, it
should run under win95. Im able to run a couple of window nt program
under win95.
Actually, we said that it would be available "around the end of the
year".
>>Actually, we said that it would be available "around the end of >>the year".
But you didn`t said what year <bg>!
>>Actually, we said that it would be available "around the end of the year".
Which is after Siggraph ;^).
John Stetzer
JWS
>> if they dont make any multi-thread calls, it should run under win95…
If they don't make any multi-thread calls, what would be the point of
moving over to NT? The living hell of Windows? Note that Win95 is
nothing more than a biffed up version of Windows for Workgroups. I
only hope it doesn't run on straight Windows as it would mean having
to live with terrible memory management, horrible performance, the
works…
NT is the first thing close to a true multitasking, multithreading
OS. That added to the portability makes a perfect candidate for
serious applications. Windows (or its bastard sibling Win95) is
nothing more than a "friendly" interface to DOS so people scared of
having to type (they usually have their VCR's ever flashing the
12:00am) could grasp computing.
I think it's great Microsoft has the two separate as it will cater
both users, the neophyte ever scared, and the power user with serious
needs…
On a different, but related note, I've seen some concern about
IPAS'es. What I can say is that if someone was able to write a good
IPAS plugin using the tools available for the PharLap environment, he
or she should be able to port/rewrite it for NT blindfolded, with
boxing gloves and drunk out of his/her shorts….
Note that this (as usual) is not directed at you. I'm just following
the thread and got a bit sick of this Win95 mumbo jumbo.
>>blindfolded, with boxing gloves and drunk out of his/her shorts…
Have you been spying on us, Gus?
– G
Would you care to engage in public speculation as to how IPASes might be
implemented as DLLs under WinNT? Or how hard/easy it would be to make porting
them from DOS to WinNT? Or whether developers would need to keep separate code
bases for each implementation?
Are you saying there's going to be a WinNT do_dialog(), along with all the
other DOS-specific IPAS calls? Will there be a main() that's called
repeatedly, so older state-machine IPASes will continue to work? What about
running more than one 3DS/NT on a system, and how contention between DLLs might
be managed?
No, of course I don't mind. Specially when I don't have a clue what I'm talking
about. <g>
Regardless what they do or how they implement, writing in NT is a breeze
compared to the nightmarish development environment available for PharLap. I
can put together any interface for Win/Nt in a couple of minutes of work using
a ton of different tools available. If you've noticed my recent IPAS work, you
will see I gave up all together using the IPAS library's dialog functions. I
wrote my own GUI library which is nothing more than a subset of the Win GDI.
Contention? Welcome to the multithreaded, multitasking world. All my data
structures are isolated. I've been doing my own context switching for quite
some time (multitasking under PharLap). Note that my background is low level
drivers running in such environments so it's sort of second nature to me to
treat all data as "contention prone".
I guess the best of all worlds would be both: an IPAS interface and a PlugIn
interface. It is somewhat simple to implement the old style IPAS call structure
so people could just recompile their code. I can only dream about the NEW
plugin architecture. Can you image all the possibilities of an open ended DLL
interface? Doing anything you feel like? Concurrently? How about distributed
processing, remote procedure calls, etc. Network rendering at its best. Imagine
being able to have Photoshop up and running with your texture map, as you
swoosh here and there, the 3D scene is automatically rendered. Or how about
running some wild formulas using Excel and having the keys in the keyframer
updated in real time (Ed Kelerman will go berserk with this one). Scripting
language? Can you imagine what people would do with a Visual Basic VBX able to
act directly on 3DS? Now… what I really can't wait is to get my hands on a
DEC Alpha/4 (1.2 GHz + 2G RAM)….
So if I was to buy NT, would it be able to run everything made for Win95?
How much is NT anyway? Also, I am thinking of buying IPAS disk #6 with
skin.axp, and want to know if when the new 3ds comes out ,will it work, or will
I have to buy an updated version.
>> would it be able to run everything made for Win95?
I doubt it…
>> IPAS disk #6
I have no idea
You can be that all of my IPAS customers will be "made whole" vis a vis this NT
news. I'm sure that all of the other developers will also do the best that
they can to maintain good customer relationships.
– G
HSC software ,Seconds that sentiment and is eagerly awaiting the opportunity to
provide our plugin technology for an NT based 3DS, with little or no pain to
our
customers, just lots of gain!!!
JD
HSC Software
(Kai's Power Tools)
You've got impeccable energy, Jim!
Onward into the future…
– G
Well, I didn't want you to get away with statements like "it'll be easy to port
IPASes to WinNT." 🙂 Especially if we need to qualify that with the
bleeding-edge variants that you've been doing in your code. I was thinking of
the average Joe's code. It's not that I'm rooting for a just-a-recompile
compatibility library. I think the "onward to the future" approach is a good
one, because it encourages third-party developers to enage in continuous new
development, as opposed to making everything so backwards compatible that
software publishers can milk profits from yesterday's binaries.
Yes, I do revel at the potential of what will be possible in a new world of
IPAS. For InterChange, it means making a link with 3D Studio so that every
file format, in and out, becomes available to 3D Studio. If InterChange is on
the user's system, 3DS will become "aware" of it with a little glue code IPAS
DLL.
>> …the average Joe's code…
By definition, there can't be "average Joe's" doing IPAS work. If someone can
put together an IPAS using Watcom/Metaware + PharLap SDK, he or she should just
fly through the Win/NT tools.
You make it sound like the IPAS NT kit already exists. 😉
The point is not the kit. It doesn't really matter how the kit will look like
(provided it does what we expect). The point is the fact that there are a ton
(literary) of development tools available for Microsoft stuff whereas not much,
if anything, is available for PharLap/Watcom/Metaware.
>Yes, I do revel at the potential of what will be possible in a new world of
IPAS. For InterChange, it means making a link with 3D Studio so that every
file format, in and out, becomes available to 3D Studio. If InterChange is on
the user's system, 3DS will become "aware" of it with a little glue code IPAS
DLL.<
-=-=-=-=-=-
sounds great! Kinda like Photoshop's plug in type file format stuff. Move it
to the proper directory (or tell 3DS where it is), and it automagically appears
in the "Save as.." option. Open arch. software rules.
JNJ
Yes, exactly. For that matter, I hope they are considering a way to integrate
PhotoShop plug-ins with video post… 🙂 Although the 32-bit versions of
these aren't up to snuff, they will be, soon.
>I hope they are considering a way to integrate PhotoShop plug-ins with video
post… 🙂 <
another great idea. That would be very useful as well.
Speaking of backwards compatibility, have you ever tried to think of a way to
make an existing IPAS work under Windows? The exact functionality of IPAS
under PharLap has always puzzled me. For example, when I call malloc() in my
IPAS, how does that malloc() know about the PharLap virtual memory system, if
my IPAS doesn't have to be licensed to handle PharLap virtual memory? How does
3DS negotiate that first pointer into shared memory, handing it to the IPAS
when it starts? Might not there be a way to fool an IPAS into running under
Windows?
The malloc() case is pretty generic. First, I think I will be boring to death
the non programmer but… here goes any way.
The compiler has its own "heap" management tools. Some memory gets allocated
before hand and the runtime library takes care of allocating/freeing memory
from that pool. When a request for memory exceeds the size of free heap memory,
the runtime library issues a system call requesting more memory (through
standard DOS calls). This call is the same whether you're using DOS, PharLap,
DOS4GW, whatever… The runtime library gets a pointer and starts using it. It
doesn't care where that memory is. The OS (PharLap in this context) will try to
map that memory. If it can't it will swap a couple of pages off to disk. The
runtime library has no knowledge of what goes on under the hood.
Because the runtime library uses standard DOS calls to allocate memory (and for
everything else for that matter), porting to anything else can only be
accomplished by using a different library. The binaries are not, and cannot be
compatible. By using a different compiler (or simply a different combination of
compiler switch/runtime library) your source, however, should be portable. Just
keep everything nice and ANSI. The core engines should never rely on any non
standard (i.e. Windows/PharLap/Amiga specific) functions. All my code
(excluding most UI) can be ported by simply recompiling it on the desired
target.
It's also good to point out not to rely on byte ordering. This will be a big
issue when porting code to non Intel architectures. Converting non Intel to
Intel is cheap on a Pentium. The other way around (MIPS for instance) is very
expensive in terms of CPU cycles. Keep a good abstraction layer within your
data structures.
Perhaps I don't understand how PharLap works. I assumed that it replaced
malloc/free with its own heap management. But you're saying that an IPAS links
in the standard Metaware malloc/free, which trickle down to the regular DOS
memory allocation calls, which get intercepted by PharLap, which is also
managing all of protected mode memory, so the app doesn't know the difference,
as long as it is good 32-bit code. Did I get that right? Except does DOS
reall have 32-bit-friendly memory allocation calls? (Or 48 bit, etc.) So DMPI
fits in here somewhere, too, for the big memory handling. PharLap is bound into
3DS.EXE, and since IPASes run only when 3DS.EXE has already run, it all works.
I think my misunderstanding was that PharLap replacement functions were getting
linked into replace some low-level OS calls…
The guy answering the int 21h call is bound to 3DS.EXE. Your IPAS only calls
it. That's the piece of code that makes up the PharLap dos extender. You should
get the PharLap SDK. In fact, I can't understand how one can really exploit the
PharLap environment not completely understanding it. It's just DOS on steroids.
Yes, the calls are all the same. Only when pointers are passed or other
peculiarities of 32 bit are involved you have a new set of calls. Those calls
that differ, the compiler generates specific code. That's the reason for the
different compiler switches. By the way, all registers are 32 bits. When you
write a buffer for instance, you still call the same old 21h function 40h. The
difference is that now ECX has the amount to write as opposed to just CX.
PharLap will trap the call (as every other call), map the memory down to real
mode, and divide the buffer into 64k chunks so DOS can digest it.
I do have the PharLap SDK, that doesn't mean I memorized it. 🙂 Memory
allocation worked, I didn't question it. I assumed all sorts of terrible
things were happening under the hood. You must keep in mind that I quit my
last "real job" in the mid-80s because they threatened to assign me to a task
that involved coding in 80186 assembly.
So, is there any hope for a "code museum" that might let old IPASes run with
the new 3DS under WinNT?
I have access to a four processor Alpha (not that multiple processor will do me
any good). But at 266MHz, rendering power should give me 90% faster
performance over my 486-66 midget (guestimate).
Link A. Parikh
>I have access to a four processor Alpha (not that multiple processor will do
me any good). But at 266MHz, rendering power should give me 90% faster
performance over my 486-66 midget (guestimate). <
If it'll run NT, I suspect 3DS will take advantage of all the processors.
Also, a 266 Alpha will render several times the speed of a P90! The floating
point power of the Alpha is much higher than an Intel based systems. FP does
the rendering. I'd say you should bug someone into getting NT installed on
that system.. 🙂 Who makes it?
JNJ
>>>>I have access to a four processor Alpha (not that multiple processor will
do me any good). But at 266MHz, rendering power should give me 90% faster
performance over my 486-66 midget (guestimate). <
If it'll run NT, I suspect 3DS will take advantage of all the processors.<<<
I don't want to assume anything. Doesn't Autodesk have to compile different
versions of 3DS/NT for processors other than Intel? I don't know if it is
difficult, and I'm sure Autodesk is looking to people wanting to use Alpha's.
If there are different versions for RISC NT machines I'm sure R5 will come on
CD-ROM and have all versions like Intel, Alpha, PowerPC(NT).
I have no doubt that Yost/Autodesk will make a fully cross platform,
multithreaded 3DS. The recompile for different processors isn't as hairy as it
sounds. It is only the optimizing of one file for each processor. I'd say
it'd add, at the utterly most, a couple weeks to get running versions on all
platforms. MS says it's only like 2 days work.. I bet it's already done.
Beta testing will be something of a hassle though. I suspect the Alpha will be
the processor of choice for 3DS'ers.
Who makes your 4 processor Alpha? Do you know? I haven't heard of anything
like that before. I assume it's running Unix right now, right?
JNJ
Hi Gus!
>>> On a different, but related note, I've seen some concern about IPAS'es.
What I can say is that if someone was able to write a good IPAS plugin using
the tools available for the PharLap environment, he or she should be able to
port/rewrite it for NT blindfolded, with boxing gloves and drunk out of his/her
shorts….<<<
Now I've got this mental picture of you……………………..<ROTFL>
Murph'
>>>> …blindfolded, with boxing gloves and drunk out of his/her shorts….
>> Now I've got this mental picture of you.
That's only when I dress up for formal meetings…
>> That's only when I dress up for formal meetings…<<
Ahhh….Come on Gus….I'll bet you clean-up real good!
You probably even wear shoes……right? <BG>
Murph'
<Autodesk said that it will be avalible after Siggraph. As for running under
win95, if they dont make any multi-thread calls, it should run under win95.
Im able to run a couple of window nt program under win95.>
Wrong. Win95 multi-threads just as NT does. I'm not arguing robustness of NT
vs. Win95, but you're getting mixed up with Win32s, which is for Win3.1 and
will not multithread.
Brad
>> Wrong. Win95 multi-threads just as NT does.
Wrong, wrong… unless you know something I don't Win95 is in no way
multithreaded.
>Win95 multi-threads just as NT does.
wrong. they're different
<wrong. they're different>
Yes, Win95 and NT are different, but with Win32 apps, they both multithread.
Brad
>with Win32 apps, they both multithread
I just told you what I've been told on NT forum. It could be wrong.
JNJ
I may have misread this, but I was in a book store the other day and picked up
a book on Win95. One of the questions asked was "Will NT apps be able to run
on Win95", and the answer was "Yes, the only difference between
Win95 and WinNT is that NT support multiple processers, and has level c2
security in it". The book carried on to say that Win95 uses the same 32 bit
API that NT uses. Also Win95 has Pre-emptive multitasking like NT, not
co-operative multitasking like Windows 3.x, and all programs that were written
in NT to Microsoft programming specs. will work in Win95.
So hopefully 3D-Studio NT will work in Win95.
Once again, this is what I read from Microsoft, so if it is incorrect, Im
sorry.
Thanks
Gregg Daly
Why do you care so much about Win95? What difference does it make if a NT app
runs in Win95 (by the way, what you read is only true if Microsoft changes the
"current version" of Win95). Win95 is NOT a sort off "light" version of NT.
Win95 is Windows as you have today with several features (read "hacks") added
to it. It still runs over DOS (yes, 16 bits DOS). It relies on DOS' FAT file
system, has no support for application protection (i.e. crash one, crash all),
it is still based on co-operative multitasking (i.e. hang one, hang all). Win95
is NOT, by any means, an OS. It's a GUI for DOS (the actual OS).
NT will separate the men from the boys. For Windows you've got Bob. For NT you
have 3DS.
The only reason I can think off to want Win95 (as opposed to NT) would be
because of the lesser system resources required to run it. Well, with less
system resources you won't run 3DS even today. If you have 3DS running today,
that machine will do just fine with NT.
I got the UNIX cd and am preparing to install it. But as I am
watching this thread, I am thinking I may want to re-partion and
allow for WINNT also to play with it for a while. I am going to work
with UNIX, because I need it at work, but I may also look into this.
Can I use existing DOS and Windows programs on Windows NT? Or do I
need specially compiled programs?
You can have almost any number of partitions running different OS'es.
Linux has a boot manager called LILO. You can set it up so it
presents you all three options (DOS, NT, and Linux). You can do the
same with NT's boot manager.
Regarding running 16 bit Windows programs and DOS programs under NT;
as long as they don't try to handle the hardware directly (with
exceptions such as com port, printer, etc.), you should have no
problems.
Gus;
>> you should have no problems.
Thanks again,
Dennis
Any thoughts on the DPS PAR under NT?
–Nat'n
>> Any thoughts on the DPS PAR under NT?
I have some of my own, but they don't mean anything. You should ask DPS… <g>
How did you configure your WinNT boot manager to load Linux? I tried
with WinNT 3.1 but it wouldn't work. Did 3.5 change that?
I didn't. I run Linux on a separate machine dedicated to it. I've just heard of
people (quite a few for that matter) who has done it. I would install LILO
first. It would select between Linux and "DOS". When you select DOS it would in
turn load the NT boot loader (which would present you with the DOS/NT choice).