Re:That was flamebait if I have ever seen it
on
Windows ATMs by 2005
·
· Score: 1
The parent was trying to say the the NT kernel is free of holes, and the ATMs won't be running extra services. Can you name any kernel-level or base driver exploits in NT5.1? What makes you think that RPC will be running on an ATM? So what if the OOTB settings aren't so good? You can change them, you know. You can stop and set unused services like RPC to disable. You can also have those services start in whatever user account you want. Windows XP embedded provides tons of control over configuration. Besides, UNIX root != NT Administrator or SYSTEM; there is no account that ignores security. It's mostly up to whoever puts this package together, what software they leave exposed, how it's configured.... regardless of what operating system it will be running.
Do you have any expierence with XP embedded? You have lots of control over what gets installed, you create a custom package. You can leave out most of the win32 subsystem and use native apps. You can even have a custom session manager.
Did you know that DirectInput isn't actually any faster than GDI input?
GDI stands for Graphical Device Interface. GDI has nothing to do with the mouse or keyboard. There are the mouse and keyboard drivers, any filters, the window station, and the user32 messaging from the win32 subsystem.
It sounds like your brother doesn't have Windows configured properly... is he using some obscure drivers, or have 20 gator-look-alike apps loaded? Are the video settings EXACTLY the same (aa, res, depth, af)?
And if it's running on 98% of systems, then there will be a large quantity of stupid users using an insecure distro that leaves ssh wide open, along with everything else. Forget about those users even knowing what a port is.
And Windows NT has software restriction policies. Not third party. Implemented at a low level. Use group policy to specify what binaries your normal users are allowed to run, by hash or certificate.
The best solution is to provide something else that they are relatively unfamiliar with...
Oooh. Security through obscurity?
Lock down explorer, and they'll figure out that IE allows them to browse the hard drive. Hide the shit on the hard drive and they'll still find a way in because everyone knows "C:\windows\system32\cmd.exe" will get them in from just about anywhere they can find a place to type it.
That's why you enforce the 'allow users to only run these programs by hash' policy. It's implemented much lower than explorer.
What makes that diffrent from a Windows terminal server? Each user can have their own profile. Are you saying that the client/server model is impossible to use, even with Linux?
And you can have Terminal Services on Windows too. Besides, both *NIX and WinNT can be properly secured as a desktop so that the user can't break anything without opening the case.
I'm looking over the dependcies of msvbvm6.dll (the runtime vb library) and I don't see any undocumented or ordinal-refreneced functions right off... VB can't be too dependent on Windows internals, since the same library is used on both NT and 9x. AFAIK, VB is dependent only on the official win32 api.
This is comparing apples to oranges: Windows certainly supports thin clients; it's called "terminal services". Non-obsolete Microsoft products are quite compatible with it too.
I can monitor lots of stuff: I just crank the volume on my sound card, then add volume from a set of speakers, and I can hear the bus activity. When I move windows, or do any IO, I can hear it on the speakers.
Comparing all the applications that come with a Linux distribution to all the applications that come with a Windows distribution seems fair, especially when those apps are included in many popular distros. If you want to compare kernels, what was the last vulnerability in the Windows NT kernel?
You can always convert UTF-8 to Unicode using MultiByteToWideChar and the CP_UTF8 flag.
New API? Windows NT has always been based on Unicode, had Unicode versions of the win32 APIs, and used Unicode internally. It's not Microsoft's fault that software like libc can only handle ASCII. UTF-8 is just a hack to cram non-english characters into ASCII-compatible characters so they will be compatible with UNIX programs that can't tolerate non-ASCII character sets.
No, it's not possible to create filenames that are empty or are named "??" with the win32 api, since ? is used as a wildcard. You can create them using the native api, as it has less checks than win32. Anyways, you can use the GLOBALROOT link or the convenient "C:" etc links to get to all of the drives, so what's the problem? I guess one problem is that the native api supports this much better, without the need for things like ??, but it's poorly documented, and not officially supported. That definitely is Microsoft's fault, but it's more political than technical.
You expect WaitForMultipleObjects to be able to use a third party file descriptor? Either you figure out how they are doing it, or tell them (the library's developers) to support a wait function. Besides, if they just call ReadFile or whatever without specifying an event for an overlapped operation, the call is synchronous; the operation is complete when the function returns.
A thousand threads? What needs 1000 threads? NT as much better methods of handling multiple requests like IO completions ports (much more efficent than running one thread per transaction concurrently).
Wide character filenames solve nothing and cause unbelievable pain for anybody trying to quickly upgrade 8-bit software.
If the code was written so that character types are abstracted, then it wouldn't be a problem. Besides, you can still use the ascii versions.
However they do not make it accessable to the FileOpen call that almost all C libraries make open() call, therefore by my definition it is inaccessible.
Yes, that's because the win32 api needs to be compatible with previous applications. Still, you can use symlink "GLOBALROOT" to get to "\" in the namespace. \\??\GLOBALROOT\Device\HarddiskVolume2\WINNT. Otherwise you will have to use the native api.
And you cannot send a file descriptor returned by open() to WaitForMultipleObjects. Again this could be fixed if they would realize that "fd" *is* a "handle".
What do you want to wait on? Pending file operations? Overlapped file operations are meant for async IO, and they take an event handle that is waitable.
You mean like runas.exe? For example: runas/user:mymachine\administrator cmd. You could always make a cmd script that automatically has the username and password filled in, only readable by the users you want to have sudo privelege.
You cant install many because the installers are being stupid. It would be the same on Linux if the majority of third-party installers required root access. This isn't a OS design issue, it's about the software available.
Still, you can have SOME standardization, as mentioned in the grandparent, but still leave room for uniqueness and customization. Taking this back to KDE vs GNOME, they could become more standardized as window managers, ie supporting the same features, and become more of an interchangable set of applications.
Slashdot Mirror
The parent was trying to say the the NT kernel is free of holes, and the ATMs won't be running extra services. Can you name any kernel-level or base driver exploits in NT5.1? What makes you think that RPC will be running on an ATM? So what if the OOTB settings aren't so good? You can change them, you know. You can stop and set unused services like RPC to disable. You can also have those services start in whatever user account you want. Windows XP embedded provides tons of control over configuration. Besides, UNIX root != NT Administrator or SYSTEM; there is no account that ignores security.
It's mostly up to whoever puts this package together, what software they leave exposed, how it's configured.... regardless of what operating system it will be running.
Do you have any expierence with XP embedded? You have lots of control over what gets installed, you create a custom package. You can leave out most of the win32 subsystem and use native apps. You can even have a custom session manager.
It sounds like your brother doesn't have Windows configured properly... is he using some obscure drivers, or have 20 gator-look-alike apps loaded? Are the video settings EXACTLY the same (aa, res, depth, af)?
And mabye you don't have Windows configured properly, and that's why it's running slower.
And if it's running on 98% of systems, then there will be a large quantity of stupid users using an insecure distro that leaves ssh wide open, along with everything else. Forget about those users even knowing what a port is.
And Windows NT has software restriction policies. Not third party. Implemented at a low level. Use group policy to specify what binaries your normal users are allowed to run, by hash or certificate.
Bad drivers and otherwise poor configurations can crash anything.
- The best solution is to provide something else that they are relatively unfamiliar with...
Oooh. Security through obscurity?- Lock down explorer, and they'll figure out that IE allows them to browse the hard drive. Hide the shit on the hard drive and they'll still find a way in because everyone knows "C:\windows\system32\cmd.exe" will get them in from just about anywhere they can find a place to type it.
That's why you enforce the 'allow users to only run these programs by hash' policy. It's implemented much lower than explorer.What makes that diffrent from a Windows terminal server? Each user can have their own profile. Are you saying that the client/server model is impossible to use, even with Linux?
And you can have Terminal Services on Windows too. Besides, both *NIX and WinNT can be properly secured as a desktop so that the user can't break anything without opening the case.
I'm looking over the dependcies of msvbvm6.dll (the runtime vb library) and I don't see any undocumented or ordinal-refreneced functions right off... VB can't be too dependent on Windows internals, since the same library is used on both NT and 9x.
AFAIK, VB is dependent only on the official win32 api.
This is comparing apples to oranges: Windows certainly supports thin clients; it's called "terminal services". Non-obsolete Microsoft products are quite compatible with it too.
I can monitor lots of stuff: I just crank the volume on my sound card, then add volume from a set of speakers, and I can hear the bus activity. When I move windows, or do any IO, I can hear it on the speakers.
It is at least a little Debian's fault for endorsing (by including in their distro) a version of software whose developers don't fix the bugs in.
Comparing all the applications that come with a Linux distribution to all the applications that come with a Windows distribution seems fair, especially when those apps are included in many popular distros. If you want to compare kernels, what was the last vulnerability in the Windows NT kernel?
Core? Four of these are in Office, and the last is in vb scripting, hardly a critical core component.
You can always convert UTF-8 to Unicode using MultiByteToWideChar and the CP_UTF8 flag.
New API? Windows NT has always been based on Unicode, had Unicode versions of the win32 APIs, and used Unicode internally. It's not Microsoft's fault that software like libc can only handle ASCII. UTF-8 is just a hack to cram non-english characters into ASCII-compatible characters so they will be compatible with UNIX programs that can't tolerate non-ASCII character sets.
No, it's not possible to create filenames that are empty or are named "??" with the win32 api, since ? is used as a wildcard. You can create them using the native api, as it has less checks than win32. Anyways, you can use the GLOBALROOT link or the convenient "C:" etc links to get to all of the drives, so what's the problem? I guess one problem is that the native api supports this much better, without the need for things like ??, but it's poorly documented, and not officially supported. That definitely is Microsoft's fault, but it's more political than technical.
You expect WaitForMultipleObjects to be able to use a third party file descriptor? Either you figure out how they are doing it, or tell them (the library's developers) to support a wait function. Besides, if they just call ReadFile or whatever without specifying an event for an overlapped operation, the call is synchronous; the operation is complete when the function returns.
A thousand threads? What needs 1000 threads? NT as much better methods of handling multiple requests like IO completions ports (much more efficent than running one thread per transaction concurrently).
You mean like runas.exe? For example: runas /user:mymachine\administrator cmd.
You could always make a cmd script that automatically has the username and password filled in, only readable by the users you want to have sudo privelege.
You cant install many because the installers are being stupid. It would be the same on Linux if the majority of third-party installers required root access. This isn't a OS design issue, it's about the software available.
linked into the OS kernel
What? Can you give an actual example of something from IE in or some other application part of the kernel?
Still, you can have SOME standardization, as mentioned in the grandparent, but still leave room for uniqueness and customization.
Taking this back to KDE vs GNOME, they could become more standardized as window managers, ie supporting the same features, and become more of an interchangable set of applications.