Welcome to WIndexService - a rapid text search and file find utility which piggy-backs on Microsoft Index Server (TM).


An executive summary and business model of the resume standard as outlined below -

Consultants, freelancers and job seekers of all industries, all countries, all languages edit their resume by adding these standard and human-readable codes to their resume using the right-click. They email their resume to agencies, project management companies and end-users, or even to consolidators; alternatively they site their resume as a word document on their own or some service-provider's website; alternatively, a consolidator makes bulk resumes available for free or chargeable download (charging can be effected by zipping the bulk resumes with a secret password, which is only divulged by email on payment - and it can be changed every month or issue period). These agencies, project management companies, end-users etc can search instantly on a wide range of database-type parameters without any database (and without any database maintenance and data entry). The search results then enable the searcher to immediately view the complete resume. The result is a high powered universal system for zero investment and zero training.

WIndexServer is free.
Microsoft Indexing Service is free.
The attached proposed coding standard is free.


Q. Why is WIndexService necessary?

A. Because the manual search facility provided with Microsoft Indexing Service (MIS) is clumsy and primitive, but MIS is itself a very fast and efficient search engine.... and it is free with Windows XP Professional and various other flavours of Windows...


Q. What is the relation of WIndexService to your existing product WFindStr.EXE ?

A. WIndexService is much faster but does not have fuzzy searching (yet! - ask if you want or need it!) and WIndexService has the limitations of MS Indexing Service itself - i.e. no searching on CD Rom drive or networked drive (but I think networked drive IS in fact searchable - see below). WIndexService and MIS both require a downloadable (free) plug-in from Adobe (called an IFilter) in order that PDF files are searchable. Do a google search on [PDF indexing service] to find that... WIndexService can search on the 6 NVF's (non-visible fields) which are attached to most file types, especially MS Word (.doc) files; whereas WFindstr does not have access to those fields.


Q. Are there similar products to WIndexService?

A. Yes - ISSearch and AimAtFile both seem similar, although I am not sure if they allow searching on the non-visible fields. They both sell for about US$ 30-00, whereas WIndexService is free.


Q. Where do MIS and WIndexService really score over other text search utilities?

A. They allow you to code and search on non-visible fields attached to the .PDF, .doc, .htm, .JPG, .GIF, .TIF or other file.


Q. What were your envisaged markets when you developed and issued WFindStr and WIndexService?

A. I had 2 markets in mind - my CD3WD Project and also the searching of resumes/ CV's by recruitment agencies and corporate HR Departments of all types - the CD3WD project is a collection of technical and scientific e-books, so WIndexService can be applied to any and all collections of technical and scientific e-documents on local hard drive.


Q. Is it possible to overcome the non-networked limitations of MIS and WIndexService?

A. Yes - use an incremental copy utility like Microsoft's ROBOCOPY.EXE or sync.exe to synchronize and update a large collection of files from a central server to a number of desktop or laptop pc's over the LAN, and then do local searches. Local hard disc space is these days usually no limitation.....

Check also the article http://www.aimingtech.com/search_lan.htm , which explains how to use the string "query://REMOTESERVER/CATALOGNAME" as the Catalog in order to query from a PC the indexed catalog on a remote PC or remote server; note the catalog must be a shared folder. I tried this code by the way, and a few variations of it, and could not make it work...


Q. What are the advantages of searching on the non-visible fields?

A. Firstly, one can search on graphics files (if you or someone else categorizes them). Secondly, free text search often does not have sufficient power when searching resumes - especially it tends to pick up wrong matches . If one adopts a local intra-company or nationally- or internationally-accepted standard then the use of human-readable codes for various attributes such as Country Experience, Skill Keywords, Foreign Languages, Industry Sector, Nationality/WorkPermit, Job Titles, Age, Companies worked for, Qualifications, Contract/Permanent workstyle, Payment Rate etc etc etc can all be manually attached to the Resume/CV by the person whose resume it is (i.e. self-coding) and can all be searched for. Actually, all such coded fields could be stored inside a normal word document in the main text, but might raise objections as being ugly to look at; therefore to store them inside the various non-visible fields would be a good resolution. The ideal would have been to store all codes inside one only of the NVF's, but since each NVF has a length limitation of 255 characters, that would have been impossible. As it is, I had to work out carefully how to allocate which descriptor to which NVF...

Note also that this concept is ideal for foreign language resumes - the keywords can always be done in using the quasi-english codes, regardless of the language in which the resume is written - and therefore searches are always the same and do not discriminate against foreign language resumes.


Q. How does one edit these non-visible fields in a file?

A. Right click on the file from Windows Explorer or My Computer and choose the Summary Tab; edit then press Apply, OK - so simple! Press the Advanced or Simple buttons if necessary.... The only exception to this which I can find is HTM and HTML files - they have such fields in the header - check out code in this HTM file by pressing View/Source on your browser... Note that each one of these non-visible fields has a maximum length of 255 characters.


Q. How do I set up and/or start Indexing Service on my computer?

A. Use the windows Help system. Or Start/Settings/Control Panel/Administrative Tools/ Computer Management/Services and Applications/Indexing Service. Note that MIS has to be setup and/or started on your PC and also has to be left for maybe 2-3 hours to index before WIndexService will find any matches... Once MIS has indexed then searching will almost always be immediate, even on files recently changed or added..


Q. Please outline/detail your proposed standard codes for resumes.

A. All the non-visible fields Title, author, subject, keywords, category, and comments have to be hijacked by the standard I am afraid - see below for the proposed standard's descriptors and where I have allocated them to; this allocation was done on the basis of the probable space required by each descriptor.

Windows searches are NOT case-sensitive, but people doing the coding should probably try to be consistent as per the examples listed below in case someone writes a search system based on Linux (which IS case-sensitive).

Skill codes as per S_C#, S_VB, S_Oracle, S_Linux, S_PHP, S_AnalystProgrammer, S_DataArchitect, S_NursingSister, S_EFL, S_Word, S_Excel, S_AccountingSoftware, S_Pastel, etc etc.. Note that MINOR skills should be coded as MS_CarMaintenance or MS_Welding... Store in field Keywords or DocKeywords.

Companies and organisations Worked For as per O_RollsRoyce, O_DFID, O_WorldBank, O_EU, O_PressandShear, O_ARAMCO, O_BElliot, O_Digital, O_Maersk, O_DeutschePost etc.. Store in field Title or DocTitle.

Country experience codes as per C_USA, C_Canada, C_SaudiArabia, C_KSA, C_Tanzania, C_TZ etc.. Store in Field Author or DocAuthor.

Desired location as D_Global, D_GB, D_UK, D_UKSE, D_UKNorth, D_Manchester, D_Malawi, D_MW, D_EU, D_CH, D_Switzerland etc.. Store in field Subject.

Age as per YG_1945, YG_1940,YG_1935,YG_1930,YG_1925,YG_1920 and YL_1950, YL_1955,YL_1960,YL_1965,YL_1970,YL_1975,YL_1980,YL_1985, YL_1990,YL_1995,YL_2000,YL_2005. Note that this is required to define that someone is born between 1945 and 1950. We do not recommend that age is used as a search criteria, but let us be practical - sometimes it is, and sometimes the searcher even wants the older wiser and more experienced person (!). I chose 5 year bands as being reasonably accurate for search purposes. The searcher only needs to input 1 or 2 such age-related expressions, say YG_1960 and YL_1980... This element of the coding is clumsy but perfectly effective - it is dealing with something which should really be a numeric field. Note that YG stands for 'year of birth greater than or equal to' and YL for 'year of birth less than'. Use the years approximately 70 years ago through approx 15 years ago in 5 year increments.... Store also in field Subject.

Job Titles as per J_AnalystProgrammer, J_DatabaseAdviser, J_DataArchitect, J_ServiceManager, J_MaintenanceEngineerIII, J_MaintenanceEngineer, J_Receptionist, J_DataEntryClerk, J_StudentApprentice etc.. Store in field Comments.

Work status as per W_Contract and/or W_Permanent Store also in field Comments.

Industry Sector as per I_aerospace, I_auto, I_transport, I_university, I_machinetools, I_shipping, I_retailing etc.. Store also in field Comments.

Availability is very very changeable; we do not recommend that it is stored or searched on; but if you must then use as per: A_200606, A_200607, A_200608, A_200609, A_200610, A_200611, A_200612, A_200701... (Availability less than or equal to June 2006). Meaning that one is available June 2006 (200606). Store also in field Comments.

Rate in US$ per hour as per RG_10 RG_20 RG_30 RG_40 RL_50 RL_60 RL_70 RL_80 RL_90 RL_100 RL_200 RL_300 RL_400 RL_500. if you are paid and/or charge by the day or year, convert accordingly based on 8 hrs/day and 230 days per year. Euro, Yen, GBP etc convert also accordingly. Store also in field Comments.

Languages as per L_English, L_French, L_German, L_Swahili, L_Tagalog etc.. Note if language capability is basic only then use the convention ML_English (ML meaning minor language). Store in field Category.

Qualifications as per Q_BSc, Q_MPhil, Q_PhD, Q_MBA, Q_HND, Q_OND, Q_GCSE, Q_OLevel, Q_CityandGuilds etc.. Also as Q_MechnicalEngineering, Q_MechEng, Q_ChemEng, Q_ManagementScience, Q_Architecture etc.. Can also store as Q_BSc_MechEng - combining both qualification level and qualification subject; but I/we recommend also storing each on its own - i.e. Q_BSc_MechEng, Q_BSc, and Q_MechEng. Store also in field Category.

Nationality / Work Permit as per N_UK, N_GB, N_British, N_Britain, N_Scottish, N_Scotland, N_EU, N_Nigerian, N_Ecowas, N_USA, N_Mexico, N_Mexican, N_NAFTA, N_Canada, N_Canadian. In general I/we recommend use the name of the country and not the adjective - i.e. N_SaudiArabia and not N_SaudiSArabian, but if you want to be safe and to be picked up by searches (which are NOT controlled) - then use both options (and even use N_KSA also). All persons who are EU should definitely use N_EU as well as N_France, N_Germany, N_Italy or whatever. Store also in field Category.


Q. Can additional fields or attributes be added to this standard?

A. Of course - anyone with any ideas and/or wishes on this just contact me and if it is reasonable we will add it to this web page standard... But I think I have thought of everything.


Q. What about file naming for the resumes?

A. I recommend we do as per WeirAlexander_19490104_EN.doc, WeirAlexander_19490104_FR.doc for a French language translation, WeirAlexander_19490104_DE.doc for a German version, WeirAlexander_19490104_EU_EN.doc for an EU-format resume, WeirAlexander_19490104_UN_EN.doc for a UN version, WeirAlexander_19490104_P11_EN.doc for a P11 version etc..

Thus it is FamilyNameOtherNames_dateofbirthyyyymmdd_Language2-lettercode.doc for word document files (which most resumes are these days).

Also the name of a submitted CV should always be the same, and therefore agencies and project management companies can just overcopy any and all previous versions. They can store in sub-directories (sub-folders) according to the first letter of the surname, since too many files in one directory tends to slow down the system.


Q. Should I code my own resume/CV using this standard?

A. Definitely - checkout mine at http://www.cd3wd.com/resume/resume.doc - this kind of thing can take off exponentially as individuals and resume-users get a wind of it.... And it is (almost) invisible therefore no harm is done by using the codings..... Maybe we should have some standard descriptor inside the resume - "This resume is coded in the non-visible fields using the http://www.cd3wd.com/WIndexServer/ standards" ....


Check this file for an updated version of this page http://www.cd3wd.com/WIndexService/WIndexService.htm


PS – I am a commercial programmer, specializing in C#, Visual Basic (VB), Visual Studio Net, Sql Server, Oracle, Access,  etc etc – Client Server and Web Database solutions.  I freelance and work for anyone anywhere – email me if interested, and/or view my Resume at http://www.cd3wd.com/resume/resume.htm and at http://www.cd3wd.com/resume/resume.doc .  And I am interested in doing other Systems which are useful to Mankind – so little of IT work has any socially beneficial impact – such Systems I am interested to do free of charge – contact me. But of course I also need to make money to stay alive - therefore commercial contracts of almost all types are extremely appealing to me.