#define MARKERSIZE 5
#define BEGMARKER "<A>"
#define ENDMARKER "</A>"
#include <iostream>
class A 
{
    char beginA[MARKERSIZE ];
    int i;
    char b;
    char endA[MARKERSIZE];

public:
    A() : i(0xabcd), b('X')
    {
        std::cout << "CTOR" << std::endl;
        strcpy(beginA,BEGMARKER);
        strcpy(endA,ENDMARKER);
    } 

    ~A()
    {
        std::cout << "DTOR" << std::endl;
    }

    void displayme()
    {
        printf("ADDR BEG = %p\n",beginA)
        printf("ADDR I = %p\n", &i);
        printf("ADDR B = %p\n", &b);
        printf("ADDR END = %p\n",endA)
    }
}

#include <sys/types.h>
#include <unistd.h>
#include <signal.h>
#include <A.hpp>

int main()
{
    for(int i=0 ; i<10 ; ++i)
    {
        A *a = new A();
        //a->displayme();
        //delete a;
    }

    //send a SIGSEGV signal to generate core
    pid_t pid = getpid();
    kill(pid,11);
}

 
-bash-2.05b# ulimit -c unlimited
-bash-2.05b# ./a.out > /dev/null
Segmentation Fault (core dumped)
-bash-2.05b# od –c core.1233| grep "<   /   A   >"|wc –l
11

<object>
    <field name="PersistedXml" type="string">
        <?xml version="1.0" encoding="utf-16"?>
        <Acl>
            <Ace IdentityName="NT AUTHORITY\Authenticated Users" 
                   DisplayName="NT AUTHORITY\Authenticated 
                   Users" SID="***" 
                   Rights="3" />

            <Ace IdentityName="NT AUTHORITY\NETWORK SERVICE" 
                   DisplayName="NT AUTHORITY\NETWORK SERVICE" 
                   SID="**" 
                   Rights="63" />
            <Ace IdentityName="fbamembers:admin" 
                   DisplayName="admin" 
                   SID="" 
                   Rights="63" />

            <Ace IdentityName="fbaroles:users" 
                   DisplayName="Users" 
                   SID="" 
                   Rights="3" />
        </Acl>
    </field>
</object>

1. Merge two files into another - copy smalefile1 + smallfile2 largefile
2. Decompress Files - extract
3. pushd and popd same as that for bash.
4. Associate a folder to a drive - subst X: C:\windows
5. Tree structure for directory - tree
6. Find files or find string with in a file - find/findstr
7. Hiding files within another file(NTFS Filesystem Specific) - type 1.jpg > 1.txt:hidden.jpg
8. Alias a command - doskey ls=dir
9. Starting Add/Remove Programs - appwiz.cpl
10. Show listening process and port - netstat -no|findstr "LISTEN"

Console.WriteLine(list.RoleAssignments.Xml);

 <permissions>
  <permission memberid=3 mask=9223372036854775807 />
  <permission memberid=4 mask=756052856929 />
  <permission memberid=5 mask=1856436900591 />
  <permission memberid=7 mask=206292717568 />
  <permission memberid=8 mask=206292717568 />
 </permission>

            foreach (SPRoleAssignment ra in list.RoleAssignments)
            {
                foreach (SPRoleDefinition role in ra.RoleDefinitionBindings)
                {
                      // check ra.Member.Name,  role.Name , role.BasePermissions
                }

            }

//JAVA
bool func(String name)
{
    if ( "true".equals(name) ) {
        ...
    } else {
        ...
    }
}

All most all of us are aware about server side scripting languages where the processing of the code takes place in the server and final HTML output is send back to the client for browser rendering. Similarly MS has a technology which is similar to that which is ASP.NET. ASP.NET has a very rich set of controls and features that enables us to write scalable and extensible web applications. So before we proceed to I would like to touch upon how ASP.NET is being handled by MS web server named Internet Information Server (IIS).



Within IIS we have a mapping list for extensions which map *.aspx to a particular DLL name which will be processing the request for resources of type *.aspx (eg: http://code.grep.in/sample.aspx). Now whenever a request is received by server it redirects the request to corresponding DLLs which are called Internet Server API (ISAPI) extensions. Now similarly they have ISAPI filters, ISAPI extensions are end points where they process the most part of the request. ISAPI filters can be cascaded in the sense we can have multiple ISAPI filters through which the request can go. There are specific hook point where we can plug-in these ISAPI filters. So for processing *.aspx request we have extensions which does all the ASP.NET file parsing and response building. ASP.NET also has something like ISAPI filters and ISAPI extensions and they are HTTP Modules and HTTP Handlers respectively.

SharePoint Technology Stack
Figure 2 shows the technology stack related to SharePoint. Light blue components are the basic foundation on which SharePoint is built upon. What SharePoint returns back by consuming those fundamental services are colored dark blue and dark red.We don’t have to understand all of it you will be able to co-relate few of them by the end of this article.



There are rich set of feature supplied by Core Workspace Services which can be referred to as Windows SharePoint Services (WSS, the blocks in dark blue) and the Applications/Portals can be referred to as MOSS (Microsoft Office SharePoint Server, the blocks in dark red).MOSS is built on top of WSS technology so it extends the WSS features and provides much more new features and tighter integration with Microsoft Office Applications like Word, Excel etc.

Windows SharePoint Services V2 vs V3
Before we jumpstart into architecture let me tell you few of the interesting design changes. In v2 WSS used to have a ISAPI filter which sits in IIS and which sees the Inclusion and Exclusion list to figure out if it is a ASP.NET Page or WSS requestas shown in Figure 3. Once that is done WSS Extension used an unmanaged code to interact with ASP.NET.So the integration was tighter with IIS rather than ASP.NET and they had problems with WSS code getting ran before ASP.NET context gets initialized. Another problem was that WSS had implemented its own ASP.NET parser for handling the ASP.NET pages residing in databases as there was not mechanism to do so in ASP.NET 1.1. This particular WSS ASP.NET parser lacked lot many features supported by classic ASP.NET parser. There was always non-sync with parser features with this implementation.



In order to avoid all the issues and conflicts they redesigned WSS on using ASP.NET. Now WSS it completely written using ASP.NET and now they have HTTPModules and HTTPHandlers to serve the request. ASP.NET 2.0 provided a mechanism to fetch pages from databases using HTTPModules which is called Virtual Path Provider; clients can extend the Virtual Path Provider to implement their own ways to fetch ASP.NET pages. WSS has one called SPVirtualPathProvider within SPRequestModule which does the processing for database persistent ASP.NET pages.

Windows SharePoint Services Architecture
From the technology stack diagram we know the features provided by WSS. Figure 4 shows the internal components and a sample flow of request.Wildcard mapping (*) enables the request to be routed to ASP.NET extension; another way to look at WSS is serving all types of resource like *.doc, *.ppt, *.aspx.




Within ASP.NET runtime they create a worker request for the same incoming request and we have a application factory which manages all the applications like SharePoint application (SPHttpApplication). The entire application specific configuration like external DB connector details all resides in web.config which get reread on modification enabling us to do only the fly changes without affecting older application instances. Older application instances will be still alive if it is in use but destroyed once it has processed all the assigned requests. With ASP.NET we can have multiple modules as show like Auth Modules, Session Modules, SPRequestModule etc. SPRequestModule is one which fetches the URL residing in databases.We can see various HttpHandlers like SPHttpHandler, ASP.NET Page handler, ASP.NET Web service handler etc. SPHttpHandler is the HttpHandler responsible for WSS related handling.



WSS is a kind of operating system for a web – a network built on the HTTP and HTML protocols. We have Administrative Object Models to mine the data within WSS in an organized object model hierarchy.Given below is the general WSS architecture that we can think off.
From the diagram itself it is evident that WSS is an user-friendly system of content creation, storage and management. WSS has various databases associated with it like

• Configuration DB
• Metadata
• Configuration settings
• Information about every single IIS Web site that has been SharePoint-extended in the Web farm
• A Web farm can have only single configuration DB and multiple content DB
• Content DB
• Actual site content
• User Information
• Admin DB
• Central Administrator tool

References

• Inside Sharepoint Building Your SharePoint Infrastructure
• SharePoint User Management
• WSS v2 vs WSS v3
• WSS V3 Architecture
  

• MOSS Architecture
• User profile management in WSS and MOSS
• Overview of Administrative Object Model

Labels: ASP.NET, sharepoint, wss