Non ascii support under 95 is by MBCS. A curious Ascii/unicode mix where characters can be either 8 or 16 bits. You don't want to know the rest. Just note that there is chinese/japanese support in 95, it's more memory efficient than in NT, and it's not a home cooked in IE4 thing.
True, unicode is an NT only thing (CE too, but that doesn't count). NT and COM both use unicode as their internal string type, but will exchange between ascii and unicode really easily. Use unicode for getting the last smidgeon of 'performance' from NT apps. Otherwise use MBCS for international stuff under 95, or ascii. Depending on what mood you're in.
You need a recompile to switch between the different modes, and there are significant differences in the source to get over this (there is a different entry point for unicode apps). However, VC++ has a heap of macros (TCHAR and _T) for dealing with this invisibly, as well as explicit conversion macros that actually work.
Win32s was nearly a practical joke. Micros~1 admitted to it before its' release, during its' existance and when they failed to support it soon after. It existed purely to try and egg some Win16 developers into writing for Win32 - in order to sell Windows 95. Win32s doesn't count.
Porting to CE? I'm right with you on that one. It supports an absurdly small subset of the Win32 API, and most Win32 API code is far too lardy to be worth trying to make it run on a CE machine. Writing from scratch for CE is a slightly more plausible pastime, but you have to ask some very serious questions about why you wouldn't develop for Palm or Epoc instead.
Only half true. Windows NT (even workstation) is truly multiuser. The services run under the system account. Most people log in as administrator, and DCOM components invoked on the server are run under the account of the remote user.
Only one user can be the interactive user i.e. the one that gets a screen to play with. AFAIK there's nothing stopping you writing your own multiuser shell onto the existing multiuser kernel and running it as user mode code (the NT4 windowing stuff runs in kernel mode).
What I wanted to say was that quite a lot of the API has sprouted WhateverEx(...) and the documentation for Whatever(...) now states that "Whatever is provided for compatibility, new applications should use WhateverEx(...)" and on having a look this normally means it has sprouted a security descriptor, which can have NULL passed if you don't feel like doing anything clever with security. It works. It's easy. It's fast and it's mostly quite cool.
The problem is that only the shrink wrap industry really codes down to the API's these days - it's just not even remotely efficient for the majority of developers who are sent scampering over to VB / ASP to bump up their development speed (and lose maintainability in the process IMHO, but that's another argument). Since VB is effectively just glue for COM components, this exposes you to the vagueries of Microsoft internal wranglings in all their horror.
If it's not data access components of the week (ADO wrapping OLEDB, which is effectively a driver specification), or cookie wrapper of the week (AUO, an object that wraps sending tons and tons of site server cookies to the client and tracking via LDAP), then it's Active Directory or its' I-don't-exist-really younger brother ADSI. Add to this MTS, wondering what COM+ is going to do and worrying about the quantity of proxying going on ("what the client thinks it has is a database connection object, when in fact it has a proxy that invokes one of the connections from the connection pool") and the feeling that you are losing control of what is going on builds almost as fast as Wrox can sell books explaining it.
That being said, most of it has a tendency to work. And most of it does do something you would have had to code up yourself. Some of it is quite cunning. And it is all rediculously over priced.
If you want to slate the Win32 API, I suggest you have a look at the RAS API - and check the version compatibility boxes.
Absolutely. The basic windows API hasn't really changed since Windows 3.0. A 'C' message loop, window class, minimalist "hello world" will do exactly the same thing on Windows 3.0 through to Win2k.
Interesting to note they have a motion blurring 'demo' that looks frighteningly like the T-buffer stuff that kicked off two days ago. That was crap too. They both look like the cartoon rendering of Tom (of &Jerry fame) being hit by a plank. Lots of similar images laid ontop of another to give the impression of movement, garbage.
Presumably the root of all these difficulties are that as we bang vertices over to the accelerator, it considers each frame as a stand alone rendering. This was what OpenGL was designed for, after all. What, to me, seems to be missing is the ability to pass the velocity for a vertex over to the card as well, hence opening the floodgates for manufacturers to add motion blurring as they see fit.
Or frame interpolation, good idea? Send to card at 25fps, render at 75fps, freeing up a truckload of processor time and a truckload of AGP bandwidth into the deal.
Crivens, at this rate we may actually see some innovation rather than merely bumping up fillrates month on month.
I haven't had to do any recruiting for about a year now, but even then I noticed I was interviewing more those in the industry for "easy" money and less because it's just about the only thing they want to do.
Less people who know assembly? Less people who know any damn compiled language at all more like (and VB doesn't count). There are those, and possibly not a minority, who neither know nor care what the stack is. I once had to interview someone for a C++ job, couldn't tell you what an object was, but was mightilty excited when I told him we'd give him a P2 with 128 meg to develop on.
Actually this could prove extremely healthy for Linux. As far as a MS based developer is concerned (and there are loads and loads of them), the main problem with Linux is that we don't know how to develop on it. How, for instance, am I to make a DCOM server under Visual C if I'm using Linux (I know there is a unix dcom library, but it costs almost as much as NT server, and I still can't use ATL). Likewise an ASP page (without resorting to chillisoft's $900 odd ASP for Apache thing).
NT has a completely different set of problems: Stability and Price (or to be more accurate, absurd licensing). Especially if you want to connect more than, say, five users. So the question is how to make the best of both worlds? How to make use of the inherent stability of Linux to run the database, net connection, etc. And host a middle tier on NT, where it's easy to develop?
It seems to me that Embedded NT could help out here. It should be possible to make a diskless board boot from a Linux box and just host the middle tier. Bingo, we have an easy to develop for application layer. The Win95 clients can merilly connect via DCOM, share their files (and be logged on via) Samba, and everyone's happy.
Have yourselves a URL. http://www.microsoft.com/embedded/winnt.htm
Slashdot Mirror
Non ascii support under 95 is by MBCS. A curious Ascii/unicode mix where characters can be either 8 or 16 bits. You don't want to know the rest. Just note that there is chinese/japanese support in 95, it's more memory efficient than in NT, and it's not a home cooked in IE4 thing.
True, unicode is an NT only thing (CE too, but that doesn't count). NT and COM both use unicode as their internal string type, but will exchange between ascii and unicode really easily. Use unicode for getting the last smidgeon of 'performance' from NT apps. Otherwise use MBCS for international stuff under 95, or ascii. Depending on what mood you're in.
You need a recompile to switch between the different modes, and there are significant differences in the source to get over this (there is a different entry point for unicode apps). However, VC++ has a heap of macros (TCHAR and _T) for dealing with this invisibly, as well as explicit conversion macros that actually work.
Dave .
Win32s was nearly a practical joke. Micros~1 admitted to it before its' release, during its' existance and when they failed to support it soon after. It existed purely to try and egg some Win16 developers into writing for Win32 - in order to sell Windows 95. Win32s doesn't count.
Porting to CE? I'm right with you on that one. It supports an absurdly small subset of the Win32 API, and most Win32 API code is far too lardy to be worth trying to make it run on a CE machine. Writing from scratch for CE is a slightly more plausible pastime, but you have to ask some very serious questions about why you wouldn't develop for Palm or Epoc instead.
Dave.
Only half true. Windows NT (even workstation) is truly multiuser. The services run under the system account. Most people log in as administrator, and DCOM components invoked on the server are run under the account of the remote user.
Only one user can be the interactive user i.e. the one that gets a screen to play with. AFAIK there's nothing stopping you writing your own multiuser shell onto the existing multiuser kernel and running it as user mode code (the NT4 windowing stuff runs in kernel mode).
Dave.
Bugger, I hadn't finished. (Bad keyboard day).
What I wanted to say was that quite a lot of the API has sprouted WhateverEx(...) and the documentation for Whatever(...) now states that "Whatever is provided for compatibility, new applications should use WhateverEx(...)" and on having a look this normally means it has sprouted a security descriptor, which can have NULL passed if you don't feel like doing anything clever with security. It works. It's easy. It's fast and it's mostly quite cool.
The problem is that only the shrink wrap industry really codes down to the API's these days - it's just not even remotely efficient for the majority of developers who are sent scampering over to VB / ASP to bump up their development speed (and lose maintainability in the process IMHO, but that's another argument). Since VB is effectively just glue for COM components, this exposes you to the vagueries of Microsoft internal wranglings in all their horror.
If it's not data access components of the week (ADO wrapping OLEDB, which is effectively a driver specification), or cookie wrapper of the week (AUO, an object that wraps sending tons and tons of site server cookies to the client and tracking via LDAP), then it's Active Directory or its' I-don't-exist-really younger brother ADSI. Add to this MTS, wondering what COM+ is going to do and worrying about the quantity of proxying going on ("what the client thinks it has is a database connection object, when in fact it has a proxy that invokes one of the connections from the connection pool") and the feeling that you are losing control of what is going on builds almost as fast as Wrox can sell books explaining it.
That being said, most of it has a tendency to work. And most of it does do something you would have had to code up yourself. Some of it is quite cunning. And it is all rediculously over priced.
If you want to slate the Win32 API, I suggest you have a look at the RAS API - and check the version compatibility boxes.
Dave.
Absolutely. The basic windows API hasn't really changed since Windows 3.0. A 'C' message loop, window class, minimalist "hello world" will do exactly the same thing on Windows 3.0 through to Win2k.
Not at all. There was some network logging in stuff, but the basis of the OS wasn't even remotely multiuser.
Interesting to note they have a motion blurring 'demo' that looks frighteningly like the T-buffer stuff that kicked off two days ago. That was crap too. They both look like the cartoon rendering of Tom (of &Jerry fame) being hit by a plank. Lots of similar images laid ontop of another to give the impression of movement, garbage.
:)
Presumably the root of all these difficulties are that as we bang vertices over to the accelerator, it considers each frame as a stand alone rendering. This was what OpenGL was designed for, after all. What, to me, seems to be missing is the ability to pass the velocity for a vertex over to the card as well, hence opening the floodgates for manufacturers to add motion blurring as they see fit.
Or frame interpolation, good idea? Send to card at 25fps, render at 75fps, freeing up a truckload of processor time and a truckload of AGP bandwidth into the deal.
Crivens, at this rate we may actually see some innovation rather than merely bumping up fillrates month on month.
Dave
Of course Back Orifice is fair game. You have to upload it and get it going, of course.
:)
Wasn't there something about terminal services being included in Win2k server?
Dave
Yes. Oh, god yes.
:)
I haven't had to do any recruiting for about a year now, but even then I noticed I was interviewing more those in the industry for "easy" money and less because it's just about the only thing they want to do.
Less people who know assembly? Less people who know any damn compiled language at all more like (and VB doesn't count). There are those, and possibly not a minority, who neither know nor care what the stack is. I once had to interview someone for a C++ job, couldn't tell you what an object was, but was mightilty excited when I told him we'd give him a P2 with 128 meg to develop on.
Jeez. Where will it all end.
Dave
Actually this could prove extremely healthy for Linux. As far as a MS based developer is concerned (and there are loads and loads of them), the main problem with Linux is that we don't know how to develop on it. How, for instance, am I to make a DCOM server under Visual C if I'm using Linux (I know there is a unix dcom library, but it costs almost as much as NT server, and I still can't use ATL). Likewise an ASP page (without resorting to chillisoft's $900 odd ASP for Apache thing).
:)
NT has a completely different set of problems: Stability and Price (or to be more accurate, absurd licensing). Especially if you want to connect more than, say, five users. So the question is how to make the best of both worlds? How to make use of the inherent stability of Linux to run the database, net connection, etc. And host a middle tier on NT, where it's easy to develop?
It seems to me that Embedded NT could help out here. It should be possible to make a diskless board boot from a Linux box and just host the middle tier. Bingo, we have an easy to develop for application layer. The Win95 clients can merilly connect via DCOM, share their files (and be logged on via) Samba, and everyone's happy.
Have yourselves a URL.
http://www.microsoft.com/embedded/winnt.htm
So, exactly how far out am I?
Dave