Surely you're joking? Do you actually fail to understand how broken such a behavior would be? Consider the relatively trivial case of a #included file which contained two namespaces, and attempted to reference one another through uses clauses. This is a blatant CFAD behavior.
I've done it plenty of times before. I've even put #included files inside a template struct using a type parameter for what would have been a typedef, then using different types. I've never had to reference the global namespace, but if this was a problem, defines would be a good workaround.
The source code has to support this, though.
This sentence alone is enough warning that any experienced programmer would be cluebulbing right now.
This goes for any style of writing code. The source has to be written to support declaritive header files if you want to use those. Any piece of code has to be written to support the things you want it to. Anything can be abused if you don't use it correctly.
C doesn't offer namespaces.
C doesn't offer multiple namespaces but does have a single namespace, where all the names go. I specifically said singular namespace, wich C does have.
Then you had just as many massive coupling problems as the original author appears to. #including source is the wrongest of the novice linking mistakes, and whereas that's a total zealot thing to say, I don't care, because it's also true. You would do well to read up on the basics before giving out any more bad advice.
That page tells you in two different places to use headers as always but provides exactly zero reasons as to why.
You say there would be coupling issues; have you actually done this in a project? Maybe you just don't know how to use this technique correctly? There are masses of things than are powerful but can be abused if you don't know what you are doing. To make them safe, there are rules and constraints that need to be followed, just like there are in using pointers or kernel programming.
Templates aren't code, and inlined code doesn't go into precompiled headers (in fact it cannot, for obvious reasons.)
If it isn't code, then what is it? Just what is your definition of code, anyways? No, it won't be converted into ML until the parameters have been supplied, but so what? You also can't compile something until you've selected a target architecture. Does that mean it's not code unless it has the CPU type embedded? It's a piece of information that's missing before it can be compiled. When somebody says "for the obvious reasons" it usually means they really don't know but for whatever reason believe it anyway. State the obvious reasons. If template code can go into them, what's to stop non-template code?
If you had read the standard, then you would know that inline is a hint, not a requirement, much like register. In fact, the language specifies that the programmer cannot control inlining, and that inlining is totally the compiler's decision. If your compiler listens to you, that's because it's being nice, not because you told it to.
So? How is this in conflict with what I said? In the real world, compilers give you some control over inlining and how you use it will affect the code's performance; something you should be aware of.
No they most certainly do not. I suspect you're referring to #pragmas within the source; a real C programmer knows that #pragmas are not C, but rather an explicit backdoor introduced by ISO during standardization. The focus of C and C++ was originally and remains to this day that of portability; #pragma is the work of the devil and should never, ever occur in code. This should begin to give you minor cluebulb about why real programmers are frustrated with MSVC; see also _tmain, main(int, char*, char*), void main(), et cetera.
Including all the source code into one main file compiled to one object can work, if the source files cooperate. C can have problems with the namespace, but C++ allows multiple namespaces and you can even put the namespace blocks in the main file around the #includes. The source code has to support this, though. It's best if all the source files to be included are under your control. For libraries that expect to use a declarative header, use it like it was intended.
I've done this on lots of projects and it works great. Most of the arguments here are either about performance or an appeal to tradition (that's the way we've always done it... must be the only true way). Modern compilers will create pre-compiled headers that can include code, usually used for template and inline definitions; modern compilers don't get the same benefits from the traditional model anymore. Actually, even larger projects seem to take longer to link with iostream and windows.h than the source does to compile. The compiler's ability to optomize code may be increased greatly, espescially its ability to inline functions. Too much inlining will cause code bloat, but the compiler's options should give you control over the balance. Modern compilers also allow you to change the compilation options mid-file. Any debugger or source analyzer shouldn't have problems handling inline or same-file implementations, or you're using bad tools. It can also be easier to create test code; create a series of test files t01.cpp, t02.cpp (each with a main) but include only one. The others are there for reference but don't interfere. This is also useful for testing a prototype replacement for a component; include the new one and comment out the old include. Going back is trivial.
It's more a question of coding style than anything. Personally, I hate maintaining redundant information of any kind, and this very much includes the prototypes in the header with the actual functions. Source code redundancy is bad for all the same reasons that database redundancy is bad. Making my C++ member functions inline and including their files frees me from this.
I don't think this will work too well in Java. A Java source filename = the.class filename = the ONE public class exported by the file. Unless you want a total of 1 public class, it won't work. Java doesn't use header files anyways. Class binaries export everything public automatically.
The Object Manager provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to/dev/hda1.
The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.
The programming style for UNIX or even a POSIX target is different from Win32. This isn't due to NT, but the Win32 subsystem and all the libraries that are initialized up startup for new Win32 processes. NT is perfectly happy to make a new process with a copy of the parent's address space with no new memory or threads or libraries or anything. fork() in SFU is as fast and efficent as it should be.
I'd like to add that in order for selection to work, there needs to be a consistent environment, or at least one that changes slowly. Selection molds the genes to reflect the environment; the more consistent the environment, the better evolution can reflect it.
If an instance of mutation X is culled because it is wasteful, but becomes beneficial later when the environment changes, the mutation will need to happen again to get a chance to propogate. Although the probability is the same the second time, the first chance was wasted on a now obsolete environment. This can work if the environment changes slowly enough for the evolutionary cycle to adapt. For changes that are too rapid, the organisms will be left with selectional choices that poorly match the new environment. Culling mutation X worked last time (in the old env.), but evolution can't see the future and has to constantly correct itself to adapt to the changing environment.
Since each organism or even each population don't live in a closed environment (each seperated from each other) part of the environment is other organisms. Together, the species' will tend to drift until a balance between them is reached where each can be specialized, AKA each species having a niche.
E.g., if I remember right, for example, the file server security in NT 3.5 and the pre-SP1 NT 4.0 was entirely in the client. Yes, the client was supposed to check for itself if it's allowed to access a file, and if not, back down. However, if the client was not that nice, it could go ahead and request the file anyway... and get it.
Where did you get that silly idea? NT has always used impersonation of the client's account to detirmine access.
1. The client connects to the file server with the SMB protocol to start a session and to establish the client's identity in the form of a token. Authentication of the client's identity is handled by a LSA authentication module such as samsrv.dll for the local user database, msv1_0.dll for an NTLM domain or kerberos.dll for a kerberos domain (2000 or later). The security token is generated by one of these packages and passed along to the SMB server at impersonation level. If the client doesn't explicitly log on, he gets an anonmyous token. In any case, the session must have a security token associated with it to proceed.
2. Before accessing anything on behalf of the client, the thread servicing the request impersonates the client using their token. Instead of using the process's access level for access, the client's token is used. At the kernel level.
See this page about SMB authentication; it's written for NT3.x. See also Security Subsystem Architecture, although for Win2k, the architecture really hasn't changed that much; just expanded to include Active Directory.
Have you looked at Process Explorer? It's a task manager type progam that provides tons of extra information: for each process you can see its parent, the startup options, a list of every kernel handle it has open, every library it has loaded, a cpu and memory usage graph, a list of threads with stack and status for each, what services (if any) are running inside it (for the svchosts mainly), what sockets are open, environment variable information, image strings and more. Lots of other tools at sysinternals.com too.
bollocks, as one very obvious example that anyone who has ever used VB cannot fail to miss VB's object model so poor you often have to hack around VB to do a good design.
VB's object model is based on COM. When programming in certain other object-oriented imperative languages (like.NET or Java) I miss the everything-is-an-interface so anybody can implement it model that VB has. VB doesn't have inheritance so you have to write wrappers, but it isn't any worse than all the wrappers commonly needed for a sizable.NET project. I usually end up writing a mess of them to redirect stupidly placed events (click events on the container, not the item??) and working around single-only inheritance. Here's an article about implementing traditional inheritance in VB6.
VB also encourages the development of slow runtime bound objects via activeX/OLE when faster runtime bound objects via DLL's are available in other languages.
COM interface function calls are implemented using a vtable, just like Java functions, overridable.NET functions and C++ virtual functions are. A vtable adds at most 1 indirection to a function call. DLLs? Just what do you think COM and ActiveX libaries are? Besides, VB has no problem using dynamicly loaded functions from a DLL.
Try doing MAPI development (not simple MAPI) in VB, it's not quite impossible but your going to be writing a serious hack.
Do you have a good VB library for MAPI? If not, let's see you do MAPI without a library from Java. If you do have a library, it sounds like it isn't too great.
And try doing any data manipulation.
ADO seems to work nicely.
No, accounting applications, that used MAPI as a transport to send data to other copies of Excell etc....
You might try DCOM, the standard network transport for COM objects like the ones that VB and Excel provide.
Ok then more than 95% of the time, and statisticly I can generalise.
Oh, you have real statistical evidence to support your position? Let's have it!
Maybe the reason you are having so many problems with VB is that when it comes to that language, you don't know what you are doing and would rather blame the tools?
I'm also kinda curious... if I have a root terminal open on my desktop, can a malicious program running as me do something similar?
On Windows, console windows aren't vulnerable (I don't think). If you did have a vulnerable window on the same desktop as a malicious program ready to exploit it (without using a job object to contain it), the malware could take it over. This is a bit of a problem with RunAs.
If this can be done on X too, then it's a security deficiency in both.
X on UNIX is like GDI on Windows. The issue is in Win32.USER, the window manager. Although X isn't vulerable, certain window managers could be; it depends on how messages are sent between windows.
I thought MS issued a hotfix for this a couple of years ago, around about the time XP SP1 was released, I thought.
Sending unsolicited WM_TIMER messages to another process has been blocked, but there are still other messages that can cause arbitrary code execution. The messaging model was inherited from versions of Windows way before security was considered. Sending messages (even the unsafe ones) to other processes can't be blocked or it would break way too many things. No security isn't an option in NT, so the solution is to break the environment into sandboxes. Inside each sandbox, however, there is no security; all the security is at the front door.
So why, when security flaws are caused by applications doing something that the Windows API documentation specifically instructs them not to do, is this considered a flaw in Windows?
It's not, but that doesn't stop some people from blaming Windows anyway. It also doesn't prevent 3rd party developers from writing insecure apps, that (when trusted by an admin) can break the system. Notice that Microsoft threatens to stop supporting interactive services in the docs, to try and get developers to clean up their act, but they will never do it, as Microsoft has compatibility as too high a priority.
It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message. Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user. A creates a window on the interactive desktop (a big no-no) with a textbox in it. B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.
First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop. Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job. MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that. Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.
I've read that book, and it's a really good reference. Like I said before, the problem with using NtCreateProcess directly is that it doesn't do all the Win32 specific initialization that CreateProcess exported by kernel32.dll does.
NtCreateProcess creates an empty process object with no memory, no threads and only the inherited handles. It does not load an executable. It does not load any libraries, except ntdll. It does not connect to the Win32 or any other subsystem. These are all things that kernel32.CreateProcess does automatically. It's easy to create a thread, allocate memory and load libraries into the new process but connecting to the Win32 subsystem is undocumented. Although many of Win32's functions just wrap to a native function or are simple library functions, the Win32 server also maintains plenty of it's own shared state. In order to take advantage of any of Win32's own services, like the windowing environment, you have to register your process with the Win32 server, implemented in csrss and win32k with an undocumented procedure offically accessible only through kernel32.CreateProcess. SFU doesn't have this problem because its processes do not (and can not) use Win32's services.
In the section "Forking a Win32 Process", Nebbett explains and has a code example of exactly how to get fork to work, including contacting the Win32 subsystem. I don't know why the Cygwin developers don't use it, since at least one of them has read the book. Another problem mentioned is that most DLLs do not expect to be forked and behave badly, including certain versions of msvcrt. Given that cygwin apps usually only depend on the cygwin library and other unix-imported fork aware code, this shouldn't be a big problem.
Ummmm, no. Cygwin could detect the type of Windows running at startup and then execute different code based on the platform. Cygwin could load the NtCreateProcess function dynamically when NT is detected and use the old style copy everything method for 9x. One code base, and one binary that behaves differently based on the platform. See LoadLibrary, GetProcAddress, , GetVersionEx and VER_PLATFORM_WIN32_NT.
Underneath the Win32 API is the NT Native API. NtCreateProcess can be called with the SectionHandle parameter set to NULL which produces a new process with the same address space as the ParentProcess handle, mapped copy-on-write just like fork. CreateProcess from win32 calls this function to create a new process but does not expose all of the functionaility. SFU and the POSIX subsystem have to use NtCreateProcess too, but take advantage of SectionHandle=NULL.
Cygwin uses copy-on-create to simulate copy-on-write by copying the entire address space to the child. This is slow and wastes memory. The cygwin mailing lists have had endless arguments on why they don't take advantage of NtCreateProcess. Here's a small thread. Also, there is the problem that Win32 does a lot more than just call NtCreateProcess: the native function creates a new process but nothing else. It allocates no memory, creates no threads, and loads no libraries. When you call CreateProcess from Win32, it does all that for you. Since Cygwin implements Posix (and related) over Win32, not Posix over NT (as opposed to SFU which is over NT), they feel compelled to use only Win32 functions. It would be nice to have a cygwin fork that creates its own subsystem, an open-source SFU, that would take advantage of this kind of thing.
Depending on fork to provide stability is a workaround for the real problem: the app crashing. Besides, if your data areas are well defined, you can put them in shared memory sections and have the children map that copy-on-write at the same addresses.
top - pslist
ptree - pslist
w - psloggedon
ls -al - dir/adhs, fsutil (both standard)
finger - finger (standard)
unzip - expand (standard, for CABs), cygwin unzip, rar
mount - (automatic), fsutil, linkd (from resource kit)
make - make (comes with SDK)
grep - find (standard)
piping with | > < are the same perl cygwin for other UNIX processing utils.
If you have to recover data by hand, you've already failed because data critical enough for you to be willing to go through that should have been backed up in the first place. Fixing config files or even the filesystem itself with a hex editor is already hard enough. Yes, a binary database would make that harder, but if you've gotten to that point there has already been a failure in preventative maintenence. It's something that you should never have to do; it doesn't matter how hard it is. Either the data is trivial enough that it doesn't matter if it is lost or it should be on a backup schedule. Don't depend on it being fixable by hand if corruption occurs. Picking a format that might make it easier to recover by hand if the storage is only somewhat corrupted is wasting time on a trivial benefit; one that you should never depend on.
There are some benefits that the registry has over/etc: Much greater security granularity: equivalent of every line of a config file as opposed to the entire file. Standardized structure for subkeys and values. Every file in/etc gets to pick their own unique format, each incompatible. Reinventing the wheel? Every file invents a new way to delimit entries and form structures. About the only thing that is standard is the newline character for ending lines. It provides its own support for journalling and symbolic links even if the underlying FS doesn't. It also stores extra metadata, such as strings that should be expanded with environment variables. It provides one interface for accessing all configuration, for users or the system. A program can edit a single entry with a key handle without having to parse and the entire file. Two processes can edit what would be the same file at the same time with all the synchronization handled by the OS. Otherwise you'd have to come up with your own method, and create a daemon to host it (unless you actually trust every client to behave) Sure, you could break your config files into one entry per file and many directories in a hierarchy, but then you are just using the filesystem to store metadata and structure directly; you've traded one binary database for another.
Why does anyone use binary databases for anything? Why not make the filesytem's datasets all text? It'd be easier to recover, since binary DBs have virtually no gain over text ones...
What's one more layer of indirection? It's the difference between being able to get the data back and not. A binary registry (especially one as hairy as Windows) is a hell of lot harder to fix/recover than a text file -- and even more difficult to find on in a fucked up disk image. I know, I've tried both.
There are filesystems that will store tiny files (< 1 cluster) directly inside of the file table itself. If your text config files were put in there, along with the metadata for the entire FS, it would be even harder to recover manually.
And a point where it doesn't need to be any more complicated. Want to trade some more empty meaningless cliches?
That was in response to your (assuming same AC) attitude that given a choice between two methods, the simplest is the best. Simplicity is certainly a good thing, to a certain extent. What you really want is a balance between simple and complex, specialized and generic. I think the registry is a good balance. It has a journal to protect against sudden crashes, and mirroring or backups are a better method of protection against hardware corrpution than relying on recovery by hand.
Here's an annecdote: of all the NT based systems I've owned and used, I have never seen a case of registry or filesystem corruption not caused by hardware failure (that wasn't recovered automatically, i.e. journal cleanup or chkdsk).
Even without Citrix/TS, each desktop object has its own grapical surface. You can create as many desktops as you want. The graphic surface exists for each, even if it isn't being displayed. The only thing that Citrix/TS do is connect these to a video driver that renders the display across the network. The method of connecting a window station to a video driver and set of input devices is undocumented but all the back end parts are already there.
Before you can read a text file, you need to process the binary filesystem format. If you can do that, what's one more layer of indirection? There's nothing stopping you from using a disk editor to access data in a registry hive and it's about as easy as doing the same thing on a filesystem database. You're just trading one database for another. There's a point where oversimplifying the design causes more problems and weaknesses than it fixes.
The Windows registry on NT is provided by the Configuration Manager, a kernel mode executive subsystem. The CM exports its own type of object, the Key object, which is handled like any other type of kernel object. A registry key consists of an ACL, a set of values, and a set of subkeys arragned in a hierarchy. Each non-volaitle key is backed by a file, known as a registry hive; subkeys can be stored in the same hive as the parent or be mounted from a different one. Hives are opened and locked by the kernel and are journalled to prevent corruption.
/etc uses the filesystem database to store configuration groups directly and different formats for each type of file to store entries. Security is provided for each file. The registry uses a specialized database that is aware of each line of data; it provides enough metadata to distinguish between strings and integers and binary data, providing a string label for each item. Security is provided for each key. Although you can arrange keys and values any way you like, key level security usually provides a lot more granularity than file level. The standard config consumer on UNIX has one file for config, even if there are many entries. The standard on Windows is to give each app a base key which can contain as many securable subkeys as needed.
Both are databases. Given the choice between a general purpose format that leaves the details up to each client to re-invent and a specialized database designed specifically for configuration, which one sounds better? Which one is easier to use in a standardized way?
The NT core has always been multi-user. The Win32 subsystem server has been multi-user since NT 3.51, although you needed 3rd party Citrix to really take advantage of it with remote GUI sessions. NT4 TS had the first Microsoft provided multi-user access to GUI sessions on the Win32 server. The stuff like session namespaces had to be added to work around all the apps that were not multiuser aware.
The only thing that TS and Citrix provide are remote GUI sessions. NT has always been able to service multiple users on other protocols such as Telnet or SSH or X-Windows or filesharing.
I'm not aware of any kludges that Citrix had to use. Care to name any specific ones? NT 3.51, the earliest version Citrix supports, already has window station and desktop objects to divide USER into different sessions. Each window station has a keyboard, mouse, clipboard, a set of global atoms, and a set of desktops. Each desktop contains a display surface, windows, menus and hooks. Bothobjects have ACLs that control security, i.e. you need access to the desktop object before you can send messages to the windows contained inside of it. Citrix and TS don't provide these objects; NT already has them, since 3.51. They create window stations that connect to non-console devices with the RDP protocol drivers; there's two for the display: rdpcdd.sys and rdpdd.dll, one for keyb and mouse: termdd.sys, one misc redirector: rdpdr.sys. These are just normal video and input drivers, except they have to be connected to a session manually since they do not serve physical devices. The functions to connect a window station to custom devices are undocumented, but the OS itself was only missing the protocol and front-end.
Windows 3.1 is based on DOS, barely has file locking, and no security. The first version of NT, numbered to match the other one, 3.1 is different. It has tons of local and domain security, is portable, and can support multiple APIs.
The old Win16 API was expanded and revised to include security, portability, memory protection, multiple users, and networking to form Win32. Old Win16 programs can still run in NT inside of a VM. Multiple Win16 programs can run in a single address space, as they expected to before to communicate or can be divided into seperate VMs. INI file access was redirected to the registry, a new specialized database for storing config information that includes security. Most Win16 programs can run fine in NTVDM as a normal user, but a few try to do things that would comprimise security. Microsoft's attitude, even then, was for the developers to fix it or forget it.
This is a lot like MacOS to OSX; a VM with a seperate API that maintains the old environment inside of itself but is independent from the rest of the system. Unfortunately, the DOS origin Windows line didn't die at version 3.1; it went on to 4.x, aka Windows 95 and 98 and ME. The security design has never been lax in the NT line but has been non-existant in the 9x line. NT didn't have an official consumer OS until XP, some 8 years after NT was first released.
The real enemy here is short-term marketing. If Microsoft had never created 95, and instead moved everything to NT, security would not be such a problem today. Their biggest excuse is that NT used too much memory (12-16MB minimum for NT3.1 vs 4MB for 95) and didn't provide enough compatibility. 95 provided excelent DOS compatibility because the old DOS was still there and it had no problems giving apps direct hardware access, and it used the old 3.1 code base for even more compat. NT had to re-implement all the DOS and Win16 interfaces and virtualize all the hardware a DOS app might expect to find; allowing direct access would be a huge security hole. Those things would not have been such a problem a few years later, but MS just had to release a new consumer OS to make some cash fast. And they did; 95 made them millions if not billions. Otherwise, OS2 or something would have won. Now the long term problems of apps and developers that expect no security, because that's what the devs expect for a consumer OS, is biting them back.
Longhorn promises (sorta, it's a bit vague) to make Win32 depreciated and sandboxed and replace it with.NET and Avalon. We'll see.
Dynamic libraries use a special type of shared memory to load the image. It's similar to a normal memory-mapped file, except that no actual section object exists (you can't use the same functions to access them) and they are always mapped copy-on-write in the address space so that 1. writes made in one do not affect the others and 2. when the library cannot be loaded into its preferred address, the altered fixups are private.
Still, you are right that there is no magic way to fix all vulnerabilities and that any kind of overflow can be and is dangerous.
If you put it that way, Windows 2003 (NT5.2) is an upgraded version of XP (NT5.1) which is an upgraded version of 2000 (NT5.0) and 2000 is an upgraded version of NT4->NT3.51->NT3.5->NT3.1 and NT3.1 was written from scratch using ideas and a team from VMS. The only other base OS series from Microsoft is the 9x line, based on Win3.1.
Many of the divisions between those OSes were manufactured by the marketing department; 2000 Server has exactly the same files as 2000 Professional, plus a couple of registry entries and extra server-side applications.
Slashdot Mirror
I've done it plenty of times before. I've even put #included files inside a template struct using a type parameter for what would have been a typedef, then using different types. I've never had to reference the global namespace, but if this was a problem, defines would be a good workaround.
This goes for any style of writing code. The source has to be written to support declaritive header files if you want to use those. Any piece of code has to be written to support the things you want it to. Anything can be abused if you don't use it correctly.
C doesn't offer multiple namespaces but does have a single namespace, where all the names go. I specifically said singular namespace, wich C does have.
That page tells you in two different places to use headers as always but provides exactly zero reasons as to why.
You say there would be coupling issues; have you actually done this in a project? Maybe you just don't know how to use this technique correctly? There are masses of things than are powerful but can be abused if you don't know what you are doing. To make them safe, there are rules and constraints that need to be followed, just like there are in using pointers or kernel programming.
If it isn't code, then what is it? Just what is your definition of code, anyways? No, it won't be converted into ML until the parameters have been supplied, but so what? You also can't compile something until you've selected a target architecture. Does that mean it's not code unless it has the CPU type embedded? It's a piece of information that's missing before it can be compiled.
When somebody says "for the obvious reasons" it usually means they really don't know but for whatever reason believe it anyway. State the obvious reasons. If template code can go into them, what's to stop non-template code?
So? How is this in conflict with what I said? In the real world, compilers give you some control over inlining and how you use it will affect the code's performance; something you should be aware of.
I said that modern comp
Including all the source code into one main file compiled to one object can work, if the source files cooperate. C can have problems with the namespace, but C++ allows multiple namespaces and you can even put the namespace blocks in the main file around the #includes. The source code has to support this, though. It's best if all the source files to be included are under your control. For libraries that expect to use a declarative header, use it like it was intended.
.class filename = the ONE public class exported by the file. Unless you want a total of 1 public class, it won't work. Java doesn't use header files anyways. Class binaries export everything public automatically.
I've done this on lots of projects and it works great. Most of the arguments here are either about performance or an appeal to tradition (that's the way we've always done it... must be the only true way). Modern compilers will create pre-compiled headers that can include code, usually used for template and inline definitions; modern compilers don't get the same benefits from the traditional model anymore. Actually, even larger projects seem to take longer to link with iostream and windows.h than the source does to compile.
The compiler's ability to optomize code may be increased greatly, espescially its ability to inline functions. Too much inlining will cause code bloat, but the compiler's options should give you control over the balance.
Modern compilers also allow you to change the compilation options mid-file.
Any debugger or source analyzer shouldn't have problems handling inline or same-file implementations, or you're using bad tools.
It can also be easier to create test code; create a series of test files t01.cpp, t02.cpp (each with a main) but include only one. The others are there for reference but don't interfere. This is also useful for testing a prototype replacement for a component; include the new one and comment out the old include. Going back is trivial.
It's more a question of coding style than anything. Personally, I hate maintaining redundant information of any kind, and this very much includes the prototypes in the header with the actual functions. Source code redundancy is bad for all the same reasons that database redundancy is bad. Making my C++ member functions inline and including their files frees me from this.
I don't think this will work too well in Java. A Java source filename = the
- The Object Manager provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to
/dev/hda1. - The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
- Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
- Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
- I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.
The programming style for UNIX or even a POSIX target is different from Win32. This isn't due to NT, but the Win32 subsystem and all the libraries that are initialized up startup for new Win32 processes. NT is perfectly happy to make a new process with a copy of the parent's address space with no new memory or threads or libraries or anything. fork() in SFU is as fast and efficent as it should be.I'd like to add that in order for selection to work, there needs to be a consistent environment, or at least one that changes slowly. Selection molds the genes to reflect the environment; the more consistent the environment, the better evolution can reflect it.
If an instance of mutation X is culled because it is wasteful, but becomes beneficial later when the environment changes, the mutation will need to happen again to get a chance to propogate. Although the probability is the same the second time, the first chance was wasted on a now obsolete environment.
This can work if the environment changes slowly enough for the evolutionary cycle to adapt. For changes that are too rapid, the organisms will be left with selectional choices that poorly match the new environment. Culling mutation X worked last time (in the old env.), but evolution can't see the future and has to constantly correct itself to adapt to the changing environment.
Since each organism or even each population don't live in a closed environment (each seperated from each other) part of the environment is other organisms. Together, the species' will tend to drift until a balance between them is reached where each can be specialized, AKA each species having a niche.
1. The client connects to the file server with the SMB protocol to start a session and to establish the client's identity in the form of a token.
Authentication of the client's identity is handled by a LSA authentication module such as samsrv.dll for the local user database, msv1_0.dll for an NTLM domain or kerberos.dll for a kerberos domain (2000 or later). The security token is generated by one of these packages and passed along to the SMB server at impersonation level. If the client doesn't explicitly log on, he gets an anonmyous token. In any case, the session must have a security token associated with it to proceed.
2. Before accessing anything on behalf of the client, the thread servicing the request impersonates the client using their token. Instead of using the process's access level for access, the client's token is used. At the kernel level.
See this page about SMB authentication; it's written for NT3.x.
See also Security Subsystem Architecture, although for Win2k, the architecture really hasn't changed that much; just expanded to include Active Directory.
Have you looked at Process Explorer? It's a task manager type progam that provides tons of extra information: for each process you can see its parent, the startup options, a list of every kernel handle it has open, every library it has loaded, a cpu and memory usage graph, a list of threads with stack and status for each, what services (if any) are running inside it (for the svchosts mainly), what sockets are open, environment variable information, image strings and more. Lots of other tools at sysinternals.com too.
I stand corrected. I thought more was offloaded to the window manager.
Here's an article about implementing traditional inheritance in VB6.COM interface function calls are implemented using a vtable, just like Java functions, overridable
DLLs? Just what do you think COM and ActiveX libaries are? Besides, VB has no problem using dynamicly loaded functions from a DLL.Do you have a good VB library for MAPI? If not, let's see you do MAPI without a library from Java. If you do have a library, it sounds like it isn't too great.ADO seems to work nicely.You might try DCOM, the standard network transport for COM objects like the ones that VB and Excel provide.Oh, you have real statistical evidence to support your position? Let's have it!
Maybe the reason you are having so many problems with VB is that when it comes to that language, you don't know what you are doing and would rather blame the tools?
Shatter attack
It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.
First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.
I'm suprised nobody has done a Google search for site:microsoft.com "user profile" security default
Default Access Control Settings in Windows 2000, which haven't changed in XP. Power Users can read (but not modify) everyone's profiles by default while normal Users cannot. The Power Users group is there mainly for compatibility. Maybe you are a Power User? Also, these are the defaults and can be modified.
Security Recommendations for Roaming User Profiles Shared Folders: this is for roaming profiles but it's the same idea.
How to disable simplified sharing and set permissions on a shared folder in Windows XP, which may be affecting your ability to see/modify the current ACLs.
See also HOW TO: Restore a User Profile in Windows 2000
Also see Security Templates overview; apply a standard template (included in XP) or create your own for tighter security.
I've read that book, and it's a really good reference. Like I said before, the problem with using NtCreateProcess directly is that it doesn't do all the Win32 specific initialization that CreateProcess exported by kernel32.dll does.
NtCreateProcess creates an empty process object with no memory, no threads and only the inherited handles. It does not load an executable. It does not load any libraries, except ntdll. It does not connect to the Win32 or any other subsystem. These are all things that kernel32.CreateProcess does automatically. It's easy to create a thread, allocate memory and load libraries into the new process but connecting to the Win32 subsystem is undocumented. Although many of Win32's functions just wrap to a native function or are simple library functions, the Win32 server also maintains plenty of it's own shared state. In order to take advantage of any of Win32's own services, like the windowing environment, you have to register your process with the Win32 server, implemented in csrss and win32k with an undocumented procedure offically accessible only through kernel32.CreateProcess.
SFU doesn't have this problem because its processes do not (and can not) use Win32's services.
In the section "Forking a Win32 Process", Nebbett explains and has a code example of exactly how to get fork to work, including contacting the Win32 subsystem. I don't know why the Cygwin developers don't use it, since at least one of them has read the book.
Another problem mentioned is that most DLLs do not expect to be forked and behave badly, including certain versions of msvcrt. Given that cygwin apps usually only depend on the cygwin library and other unix-imported fork aware code, this shouldn't be a big problem.
Ummmm, no. Cygwin could detect the type of Windows running at startup and then execute different code based on the platform. Cygwin could load the NtCreateProcess function dynamically when NT is detected and use the old style copy everything method for 9x. One code base, and one binary that behaves differently based on the platform.
See LoadLibrary, GetProcAddress, , GetVersionEx and VER_PLATFORM_WIN32_NT.
Underneath the Win32 API is the NT Native API. NtCreateProcess can be called with the SectionHandle parameter set to NULL which produces a new process with the same address space as the ParentProcess handle, mapped copy-on-write just like fork. CreateProcess from win32 calls this function to create a new process but does not expose all of the functionaility.
SFU and the POSIX subsystem have to use NtCreateProcess too, but take advantage of SectionHandle=NULL.
Cygwin uses copy-on-create to simulate copy-on-write by copying the entire address space to the child. This is slow and wastes memory. The cygwin mailing lists have had endless arguments on why they don't take advantage of NtCreateProcess. Here's a small thread.
Also, there is the problem that Win32 does a lot more than just call NtCreateProcess: the native function creates a new process but nothing else. It allocates no memory, creates no threads, and loads no libraries. When you call CreateProcess from Win32, it does all that for you. Since Cygwin implements Posix (and related) over Win32, not Posix over NT (as opposed to SFU which is over NT), they feel compelled to use only Win32 functions.
It would be nice to have a cygwin fork that creates its own subsystem, an open-source SFU, that would take advantage of this kind of thing.
Depending on fork to provide stability is a workaround for the real problem: the app crashing.
Besides, if your data areas are well defined, you can put them in shared memory sections and have the children map that copy-on-write at the same addresses.
top - pslist /adhs, fsutil (both standard)
ptree - pslist
w - psloggedon
ls -al - dir
finger - finger (standard)
unzip - expand (standard, for CABs), cygwin unzip, rar
mount - (automatic), fsutil, linkd (from resource kit)
make - make (comes with SDK)
grep - find (standard)
piping with | > < are the same
perl
cygwin for other UNIX processing utils.
If you have to recover data by hand, you've already failed because data critical enough for you to be willing to go through that should have been backed up in the first place. Fixing config files or even the filesystem itself with a hex editor is already hard enough. Yes, a binary database would make that harder, but if you've gotten to that point there has already been a failure in preventative maintenence. It's something that you should never have to do; it doesn't matter how hard it is.
/etc: /etc gets to pick their own unique format, each incompatible. Reinventing the wheel? Every file invents a new way to delimit entries and form structures. About the only thing that is standard is the newline character for ending lines.
Either the data is trivial enough that it doesn't matter if it is lost or it should be on a backup schedule. Don't depend on it being fixable by hand if corruption occurs.
Picking a format that might make it easier to recover by hand if the storage is only somewhat corrupted is wasting time on a trivial benefit; one that you should never depend on.
There are some benefits that the registry has over
Much greater security granularity: equivalent of every line of a config file as opposed to the entire file.
Standardized structure for subkeys and values. Every file in
It provides its own support for journalling and symbolic links even if the underlying FS doesn't.
It also stores extra metadata, such as strings that should be expanded with environment variables.
It provides one interface for accessing all configuration, for users or the system.
A program can edit a single entry with a key handle without having to parse and the entire file. Two processes can edit what would be the same file at the same time with all the synchronization handled by the OS. Otherwise you'd have to come up with your own method, and create a daemon to host it (unless you actually trust every client to behave)
Sure, you could break your config files into one entry per file and many directories in a hierarchy, but then you are just using the filesystem to store metadata and structure directly; you've traded one binary database for another.
Why does anyone use binary databases for anything? Why not make the filesytem's datasets all text? It'd be easier to recover, since binary DBs have virtually no gain over text ones...
Here's an annecdote: of all the NT based systems I've owned and used, I have never seen a case of registry or filesystem corruption not caused by hardware failure (that wasn't recovered automatically, i.e. journal cleanup or chkdsk).
Even without Citrix/TS, each desktop object has its own grapical surface. You can create as many desktops as you want. The graphic surface exists for each, even if it isn't being displayed. The only thing that Citrix/TS do is connect these to a video driver that renders the display across the network.
The method of connecting a window station to a video driver and set of input devices is undocumented but all the back end parts are already there.
Before you can read a text file, you need to process the binary filesystem format. If you can do that, what's one more layer of indirection? There's nothing stopping you from using a disk editor to access data in a registry hive and it's about as easy as doing the same thing on a filesystem database. You're just trading one database for another.
There's a point where oversimplifying the design causes more problems and weaknesses than it fixes.
The Windows registry on NT is provided by the Configuration Manager, a kernel mode executive subsystem. The CM exports its own type of object, the Key object, which is handled like any other type of kernel object. A registry key consists of an ACL, a set of values, and a set of subkeys arragned in a hierarchy. Each non-volaitle key is backed by a file, known as a registry hive; subkeys can be stored in the same hive as the parent or be mounted from a different one. Hives are opened and locked by the kernel and are journalled to prevent corruption.
/etc uses the filesystem database to store configuration groups directly and different formats for each type of file to store entries. Security is provided for each file.
The registry uses a specialized database that is aware of each line of data; it provides enough metadata to distinguish between strings and integers and binary data, providing a string label for each item. Security is provided for each key.
Although you can arrange keys and values any way you like, key level security usually provides a lot more granularity than file level. The standard config consumer on UNIX has one file for config, even if there are many entries. The standard on Windows is to give each app a base key which can contain as many securable subkeys as needed.
Both are databases. Given the choice between a general purpose format that leaves the details up to each client to re-invent and a specialized database designed specifically for configuration, which one sounds better? Which one is easier to use in a standardized way?
The NT core has always been multi-user. The Win32 subsystem server has been multi-user since NT 3.51, although you needed 3rd party Citrix to really take advantage of it with remote GUI sessions. NT4 TS had the first Microsoft provided multi-user access to GUI sessions on the Win32 server. The stuff like session namespaces had to be added to work around all the apps that were not multiuser aware.
The only thing that TS and Citrix provide are remote GUI sessions. NT has always been able to service multiple users on other protocols such as Telnet or SSH or X-Windows or filesharing.
I'm not aware of any kludges that Citrix had to use. Care to name any specific ones? NT 3.51, the earliest version Citrix supports, already has window station and desktop objects to divide USER into different sessions. Each window station has a keyboard, mouse, clipboard, a set of global atoms, and a set of desktops. Each desktop contains a display surface, windows, menus and hooks. Both objects have ACLs that control security, i.e. you need access to the desktop object before you can send messages to the windows contained inside of it. Citrix and TS don't provide these objects; NT already has them, since 3.51. They create window stations that connect to non-console devices with the RDP protocol drivers; there's two for the display: rdpcdd.sys and rdpdd.dll, one for keyb and mouse: termdd.sys, one misc redirector: rdpdr.sys. These are just normal video and input drivers, except they have to be connected to a session manually since they do not serve physical devices. The functions to connect a window station to custom devices are undocumented, but the OS itself was only missing the protocol and front-end.
Windows 3.1 is based on DOS, barely has file locking, and no security. The first version of NT, numbered to match the other one, 3.1 is different. It has tons of local and domain security, is portable, and can support multiple APIs.
.NET and Avalon. We'll see.
The old Win16 API was expanded and revised to include security, portability, memory protection, multiple users, and networking to form Win32. Old Win16 programs can still run in NT inside of a VM. Multiple Win16 programs can run in a single address space, as they expected to before to communicate or can be divided into seperate VMs. INI file access was redirected to the registry, a new specialized database for storing config information that includes security. Most Win16 programs can run fine in NTVDM as a normal user, but a few try to do things that would comprimise security. Microsoft's attitude, even then, was for the developers to fix it or forget it.
This is a lot like MacOS to OSX; a VM with a seperate API that maintains the old environment inside of itself but is independent from the rest of the system. Unfortunately, the DOS origin Windows line didn't die at version 3.1; it went on to 4.x, aka Windows 95 and 98 and ME. The security design has never been lax in the NT line but has been non-existant in the 9x line. NT didn't have an official consumer OS until XP, some 8 years after NT was first released.
The real enemy here is short-term marketing. If Microsoft had never created 95, and instead moved everything to NT, security would not be such a problem today. Their biggest excuse is that NT used too much memory (12-16MB minimum for NT3.1 vs 4MB for 95) and didn't provide enough compatibility. 95 provided excelent DOS compatibility because the old DOS was still there and it had no problems giving apps direct hardware access, and it used the old 3.1 code base for even more compat. NT had to re-implement all the DOS and Win16 interfaces and virtualize all the hardware a DOS app might expect to find; allowing direct access would be a huge security hole. Those things would not have been such a problem a few years later, but MS just had to release a new consumer OS to make some cash fast. And they did; 95 made them millions if not billions. Otherwise, OS2 or something would have won. Now the long term problems of apps and developers that expect no security, because that's what the devs expect for a consumer OS, is biting them back.
Longhorn promises (sorta, it's a bit vague) to make Win32 depreciated and sandboxed and replace it with
Dynamic libraries use a special type of shared memory to load the image. It's similar to a normal memory-mapped file, except that no actual section object exists (you can't use the same functions to access them) and they are always mapped copy-on-write in the address space so that 1. writes made in one do not affect the others and 2. when the library cannot be loaded into its preferred address, the altered fixups are private.
Still, you are right that there is no magic way to fix all vulnerabilities and that any kind of overflow can be and is dangerous.
If you put it that way, Windows 2003 (NT5.2) is an upgraded version of XP (NT5.1) which is an upgraded version of 2000 (NT5.0) and 2000 is an upgraded version of NT4->NT3.51->NT3.5->NT3.1 and NT3.1 was written from scratch using ideas and a team from VMS.
The only other base OS series from Microsoft is the 9x line, based on Win3.1.
Many of the divisions between those OSes were manufactured by the marketing department; 2000 Server has exactly the same files as 2000 Professional, plus a couple of registry entries and extra server-side applications.