Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

IRQL rules for RtlXxxString functions

James_HarperJames_Harper Member Posts: 1,615
The documentation for RtlXxxString and friends in most cases says IRQL must be PASSIVE_LEVEL. Is this a hard and fast rule that the verifier/PREfast/checked build is going to trip me up on, or is some flexibility allowed?

If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool, can I get away with calling RtlCompareUnicodeString? Or is it more that the RtlCompareUnicodeString routine itself might be paged out?

My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary length, so they need to be managed separately to the DeviceIdentification. The names reflect the name of a network resource that in turn has an arbitrary length (there probably is an actual limit, but it's probably longer than I want to allocate "just in case").

Thanks

James
«1

Comments

  • Thomas_DivineThomas_Divine Member Posts: 325
    I wouldn't toy with RtlXXXString IRQL requirements if you can find another
    way.

    In some situations it may be possible to upcase the strings at some prior
    point at passive level (or when they are defined). If you can pull this off,
    then you can 1.) check the Length and then 2.) if Length matches use
    RtlCompareMemory on the Buffer at DISPATCH_LEVEL.

    Thomas F. Divine


    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
    Sent: Saturday, December 7, 2013 11:46 PM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] IRQL rules for RtlXxxString functions

    The documentation for RtlXxxString and friends in most cases says IRQL must
    be PASSIVE_LEVEL. Is this a hard and fast rule that the
    verifier/PREfast/checked build is going to trip me up on, or is some
    flexibility allowed?

    If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool,
    can I get away with calling RtlCompareUnicodeString? Or is it more that the
    RtlCompareUnicodeString routine itself might be paged out?

    My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary length,
    so they need to be managed separately to the DeviceIdentification. The names
    reflect the name of a network resource that in turn has an arbitrary length
    (there probably is an actual limit, but it's probably longer than I want to
    allocate "just in case").

    Thanks

    James

    ---
    NTDEV is sponsored by OSR

    Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

    OSR is HIRING!! See http://www.osr.com/careers

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Daniel_TerhellDaniel_Terhell Member Posts: 1,349
    >If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool,
    >can I get away with >calling RtlCompareUnicodeString? Or is it more that
    >the RtlCompareUnicodeString routine itself might >be paged out?

    The routine may be paged out but also the character tables are said to
    reside in paged memory. If you don't need this for sorting but use this only
    to check if two strings are equal, instead of using RtlCompareUnicodeString,
    consider using RtlCompareMemory on the non paged buffers instead.

    //Daniel
  • anton_bassovanton_bassov Member Posts: 5,022
    > If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool, can I get away
    > with calling RtlCompareUnicodeString? Or is it more that the RtlCompareUnicodeString routine itself
    > might be paged out?


    Let's speculate a bit. IIRC, PASSIVE_LEVEL requirement means that you are not allowed to invoke any code subjected to this constraint on the paging IO path to the pagefile (which, IIRC, runs at APC_LEVEL) . This, in turn, implies that the code in question either may be pageable itself, or it may access pagefile-backed data behind the scenes. Otherwise, IRQL requirement to accessing pageable memory should be <=DISPATCH_LEVEL due solely to inability to block at elevated IRQL.....



    To summarize, calling a function with PASSIVE_LEVEL constraint at any other IRQL seems to be pretty unwise..



    Anton Bassov
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    The tables required for sorting are huge, and I would expect them to be
    pageable. There is no need to use the CompareString if equality is all
    that is required, bearing in mind that some characters that have aliased
    codes in Unicode, such as ".", might compare as "equal" under the "compare
    Unicode string" function and "not equal" under the "compare memory"
    option. Note that the "Code Red" exploit used this technique to bypass
    the checking for ".." in the cgi path, thus allowing the exploit to escape
    confinement. The ".." it checked for was by looking for two of the Page
    00 "." characters (U002E, if I remember my codes right, which might not be
    the case...), so the exploit used a dot character from another Unicode
    page, which was not seen as ".." by the checking software, but WAS seen as
    ".." by the rest of the file system, hence the ability to break out of the
    sandbox.
    joe
    >>If I can guarantee that the buffers for my UNICODE_STRING are
    >> NonPagedPool,
    >>can I get away with >calling RtlCompareUnicodeString? Or is it more that
    >>the RtlCompareUnicodeString routine itself might >be paged out?
    >
    > The routine may be paged out but also the character tables are said to
    > reside in paged memory. If you don't need this for sorting but use this
    > only
    > to check if two strings are equal, instead of using
    > RtlCompareUnicodeString,
    > consider using RtlCompareMemory on the non paged buffers instead.
    >
    > //Daniel
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    I think the Unicode tables are pageable, and thus this limitation.

    You can compare the strings bytewise (case-sensitive) at any IRQL using memcmp() or such.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com

    "James Harper" <xxxxx@bendigoit.com.au> wrote in message news:xxxxx@ntdev...
    The documentation for RtlXxxString and friends in most cases says IRQL must be PASSIVE_LEVEL. Is this a hard and fast rule that the verifier/PREfast/checked build is going to trip me up on, or is some flexibility allowed?

    If I can guarantee that the buffers for my UNICODE_STRING are NonPagedPool, can I get away with calling RtlCompareUnicodeString? Or is it more that the RtlCompareUnicodeString routine itself might be paged out?

    My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary length, so they need to be managed separately to the DeviceIdentification. The names reflect the name of a network resource that in turn has an arbitrary length (there probably is an actual limit, but it's probably longer than I want to allocate "just in case").

    Thanks

    James
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > I think the Unicode tables are pageable, and thus this limitation.
    >

    That would explain the requirement.

    > You can compare the strings bytewise (case-sensitive) at any IRQL using
    > memcmp() or such.
    >

    I'm using the name of the storage resource as the device identification. The storage resource name is ascii, so I'm having the usermode pass it to the kernel as ascii so it is always converted to the same unicode (I sanitise the ascii first), so a RtlCompareMemory should be fine.

    Except that converting to Unicode isn't something I really wanted to do so I was hoping for usermode to do the conversion and pass the Unicode into the kernel directly. Because the conversion would be done in the context of the usermode process locale though, two processes could have the same ascii that results in different Unicode, I think. Is there a way I can reliably sanitise the Unicode without requiring any of the RtlXxx string routines?

    Thanks

    James
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Note that case-insensitive compare is extremely complex in Unicode, so if
    it is required you have to obey the PASSIVE_LEVEL constraint.

    Otherwise, if bitwise equality suffices, a bitwise compare will do just fine.
    joe


    > I think the Unicode tables are pageable, and thus this limitation.
    >
    > You can compare the strings bytewise (case-sensitive) at any IRQL
    > using memcmp() or such.
    >
    > --
    > Maxim S. Shatskih
    > Microsoft MVP on File System And Storage
    > xxxxx@storagecraft.com
    > http://www.storagecraft.com
    >
    > "James Harper" <xxxxx@bendigoit.com.au> wrote in message
    > news:xxxxx@ntdev...
    > The documentation for RtlXxxString and friends in most cases says IRQL
    > must be PASSIVE_LEVEL. Is this a hard and fast rule that the
    > verifier/PREfast/checked build is going to trip me up on, or is some
    > flexibility allowed?
    >
    > If I can guarantee that the buffers for my UNICODE_STRING are
    > NonPagedPool, can I get away with calling RtlCompareUnicodeString? Or is
    > it more that the RtlCompareUnicodeString routine itself might be paged
    > out?
    >
    > My DeviceIdentification consists of two UNICODE_STRINGs of arbitrary
    > length, so they need to be managed separately to the DeviceIdentification.
    > The names reflect the name of a network resource that in turn has an
    > arbitrary length (there probably is an actual limit, but it's probably
    > longer than I want to allocate "just in case").
    >
    > Thanks
    >
    > James
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • anton_bassovanton_bassov Member Posts: 5,022
    > Because the conversion would be done in the context of the usermode process locale though,
    > two processes could have the same ascii that results in different Unicode, I think.

    Actually, I have always thought locale works on per-system basis, rather than per process one.
    Am I wrong?


    Anton Bassov
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > > Because the conversion would be done in the context of the usermode
    > > process locale though,
    > > two processes could have the same ascii that results in different Unicode, I
    > > think.
    >
    > Actually, I have always thought locale works on per-system basis, rather than
    > per process one.
    > Am I wrong?
    >

    I meant that if different user processes did the conversion then it could result in different Unicode representations.

    James
  • anton_bassovanton_bassov Member Posts: 5,022
    > I meant that if different user processes did the conversion then it could result in different
    > Unicode representations.

    ...but my question still stands - I have always thought locale concept works on SYSTEM-WIDE basis, so that you cannot have locale A for the user X and locale Y for the user B. Things like user preferences, home directory, etc are user-specific, but locale is not (otherwise Logon screen may be displayed in language that a given user does not understand) Is this suggestion correct?

    Anton Bassov
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > Actually, I have always thought locale works on per-system basis, rather than per process one.

    The "Language for Unicode programs" settings, which governs MBCS<->Unicode conversions, is system-wide.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • Pavel_APavel_A Member Posts: 2,681
    On 09-Dec-2013 17:12, Maxim S. Shatskih wrote:
    >> Actually, I have always thought locale works on per-system basis, rather than per process one.
    >
    > The "Language for Unicode programs" settings, which governs MBCS<->Unicode conversions, is system-wide.

    http://www.microsoft.com/en-us/download/details.aspx?id=13209

    - pa
  • Pavel_APavel_A Member Posts: 2,681
    Locale is per thread:
    http://msdn.microsoft.com/en-us/library/windows/desktop/dd374051(v=vs.85).aspx

    -- pa

    On 09-Dec-2013 14:49, xxxxx@hotmail.com wrote:
    >> I meant that if different user processes did the conversion then it could result in different
    >> Unicode representations.
    >
    > ...but my question still stands - I have always thought locale concept works on SYSTEM-WIDE basis, so that you cannot have locale A for the user X and locale Y for the user B. Things like user preferences, home directory, etc are user-specific, but locale is not (otherwise Logon screen may be displayed in language that a given user does not understand) Is this suggestion correct?
    >
    > Anton Bassov
    >
  • MikaeMikae Member Posts: 371
    I also have some questions about safe strings. Could someone clarify if these functions can be called at DISPATCH?

    I saw a few threads (AFAIR with replies from Doron) saying that if format string doesn't contain any string specifiers (like %s and so on) the functions can be called at DISPATCH. On the other hand I saw a thread describing BSoD even with no string specifiers. Probably the code path is PAGED.

    What a bigger problem I am trying to solve?

    Debug prints are not enough sometimes. I would like to have some logging with ETW mechanism to know what happened before OS has died. So, it should be something like KdPrint but not only to debug port but also to ETW. RtlStringCchVPrintf looks very useful to format the string, but some functions may be called at DISPATCH, so it should be DISPATCH safe.

    I could re-implement the wheel with my own DISPATCH safe formatter function. But it would be better to use existing one.

    Thanks.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I believe it is per-thread, with each thread starting off with the locale
    of the process, which is based on the per-session locale, which defaults
    to the system locale (the API SetThreadLocale is kind of a giveaway on
    this...)
    joe

    >> Because the conversion would be done in the context of the usermode
    >> process locale though,
    >> two processes could have the same ascii that results in different
    >> Unicode, I think.
    >
    > Actually, I have always thought locale works on per-system basis, rather
    > than per process one.
    > Am I wrong?
    >
    >
    > Anton Bassov
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Per-thread. See SetThreadLocale. Also look at WideCharToMultiByte and
    MultiByteToWideChar, which can supply a locale, indicate the current
    thread locale, current session locale, or current system locale be used.
    joe

    > On 09-Dec-2013 17:12, Maxim S. Shatskih wrote:
    >>> Actually, I have always thought locale works on per-system basis,
    >>> rather than per process one.
    >>
    >> The "Language for Unicode programs" settings, which governs
    >> MBCS<->Unicode conversions, is system-wide.
    >
    > http://www.microsoft.com/en-us/download/details.aspx?id=13209
    >
    > - pa
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    I think that the change of "Language for non-Unicode programs" in Control Panel actually _installs another NLS files_ to the OS.

    So, I expect that the _only_ locales which will work with W2A and A2W functions are US English and the one installed in the Control Panel. Well, also UTF-8 which is considered to be a fake locale, just to reuse W2A and A2W to do Unicode <-> UTF-8 conversions.

    IE supports displaying lots of different national languages in the web pages, but I don't think it ever supports A encoding for these languages, I think it only works with W and UTF-8.

    So, if you need to work with some national language using some app, and the app is built using A encoding, then you _must_ set the aforementioned Control Panel setting.

    Am I wrong?

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com

    <xxxxx@flounder.com> wrote in message news:xxxxx@ntdev...
    > Per-thread. See SetThreadLocale. Also look at WideCharToMultiByte and
    > MultiByteToWideChar, which can supply a locale, indicate the current
    > thread locale, current session locale, or current system locale be used.
    > joe
    >
    >> On 09-Dec-2013 17:12, Maxim S. Shatskih wrote:
    >>>> Actually, I have always thought locale works on per-system basis,
    >>>> rather than per process one.
    >>>
    >>> The "Language for Unicode programs" settings, which governs
    >>> MBCS<->Unicode conversions, is system-wide.
    >>
    >> http://www.microsoft.com/en-us/download/details.aspx?id=13209
    >>
    >> - pa
    >>
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >>
    >> OSR is HIRING!! See http://www.osr.com/careers
    >>
    >> For our schedule of WDF, WDM, debugging and other seminars visit:
    >> http://www.osr.com/seminars
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at
    >> http://www.osronline.com/page.cfm?name=ListServer
    >>
    >
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > I think that the change of "Language for non-Unicode programs" in
    > Control Panel actually _installs another NLS files_ to the OS.
    >
    > So, I expect that the _only_ locales which will work with W2A and A2W
    > functions are US English and the one installed in the Control Panel.
    > Well, also UTF-8 which is considered to be a fake locale, just to
    > reuse W2A and A2W to do Unicode <-> UTF-8 conversions.

    I believe A2W and W2A use the current user's locale, not the system
    locale, so they default to the per-session. But I haven't looked at the
    expansion of those macros in many years.

    >
    > IE supports displaying lots of different national languages in the web
    > pages, but I don't think it ever supports A encoding for these
    > languages, I think it only works with W and UTF-8.
    >
    > So, if you need to work with some national language using some app,
    > and the app is built using A encoding, then you _must_ set the
    > aforementioned Control Panel setting.

    Yep. This is why 8-bit apps should be treated as another dangerous and
    dead technology.

    Or, as I would tell my students, "The correct response, when your boss
    comes in and says 'We have a massive order for our software from Korea,
    but they want it localized. How long will that take?' the correct answer
    is not 'Well, let me see if I can get it to compile in Unicode, and then
    see how many things break, and I'll get back to you, give me a month or
    so' but 'How long will it take to get the Korean translator to get here?'"

    While Unicode is still a pretty small piece of the localization effort, if
    it a critical piece, and without it, there is not much point to worrying
    about currency formats, date formats, time formats, numeric formats in
    general, etc.
    joe

    >
    > Am I wrong?
    >
    > --
    > Maxim S. Shatskih
    > Microsoft MVP on File System And Storage
    > xxxxx@storagecraft.com
    > http://www.storagecraft.com
    >
    > <xxxxx@flounder.com> wrote in message news:xxxxx@ntdev...
    >> Per-thread. See SetThreadLocale. Also look at WideCharToMultiByte and
    >> MultiByteToWideChar, which can supply a locale, indicate the current
    >> thread locale, current session locale, or current system locale be used.
    >> joe
    >>
    >>> On 09-Dec-2013 17:12, Maxim S. Shatskih wrote:
    >>>>> Actually, I have always thought locale works on per-system basis,
    >>>>> rather than per process one.
    >>>>
    >>>> The "Language for Unicode programs" settings, which governs
    >>>> MBCS<->Unicode conversions, is system-wide.
    >>>
    >>> http://www.microsoft.com/en-us/download/details.aspx?id=13209
    >>>
    >>> - pa
    >>>
    >>>
    >>> ---
    >>> NTDEV is sponsored by OSR
    >>>
    >>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >>>
    >>> OSR is HIRING!! See http://www.osr.com/careers
    >>>
    >>> For our schedule of WDF, WDM, debugging and other seminars visit:
    >>> http://www.osr.com/seminars
    >>>
    >>> To unsubscribe, visit the List Server section of OSR Online at
    >>> http://www.osronline.com/page.cfm?name=ListServer
    >>>
    >>
    >>
    >>
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > I believe A2W and W2A use the current user's locale, not the system
    > locale, so they default to the per-session. But I haven't looked at the
    > expansion of those macros in many years.

    I just nicknamed the MultiByteXxx functions this way, to avoid excessive typing :-)

    > but they want it localized. How long will that take?' the correct answer
    > is not 'Well, let me see if I can get it to compile in Unicode, and then
    > see how many things break, and I'll get back to you, give me a month or
    > so' but 'How long will it take to get the Korean translator to get here?'"

    Modern days, compiling apps to ANSI is a nonsense.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >> I believe A2W and W2A use the current user's locale, not the system
    >> locale, so they default to the per-session. But I haven't looked at the
    >> expansion of those macros in many years.
    >
    > I just nicknamed the MultiByteXxx functions this way, to avoid excessive
    > typing :-)
    >
    >> but they want it localized. How long will that take?' the correct
    >> answer
    >> is not 'Well, let me see if I can get it to compile in Unicode, and then
    >> see how many things break, and I'll get back to you, give me a month or
    >> so' but 'How long will it take to get the Korean translator to get
    >> here?'"
    >
    > Modern days, compiling apps to ANSI is a nonsense.

    I started writing "Unicode-aware" apps about 1996, and one day I just
    "flipped the Unicode switch" and my app continued to function perfectly,
    with no issues at all. Most of my apps were trivially convertible to
    Unicode (I had trouble selling the idea to clients, who had weird ideas
    about how "inefficient" two-byte characters had to be, so I had to compile
    them as ANSI to meet client spec; but the first time a client needed a
    Unicode app, it was truly a matter of minutes to rebuild as a Unicode app,
    and yes, I was asked that very question, and they liked my answer. In
    only one case did I have to do a little more work, but the translation
    went so slowly on their side that I made the fix in a couple days and they
    never noticed...)

    Full localization can be a bit messier, particularly for some locales,
    where "non-standard" behavior is dictated by law. For example, in
    Scandanavia the "civilian" clock is the classic 12-hour clock, but by law
    all public transportation applications must use 24-hour time; one friend
    who worked for a while in Japan told me that while the conventional
    Gregorian calendar is the "civilian" calendar in Japan, the dates are not
    valid for legal documents, where the date must be in the form of "The
    <nth> day of the <kth> month of the <mth> year of the reign of our emperor
    <name>." And Windows supports this!
    joe


    >
    > --
    > Maxim S. Shatskih
    > Microsoft MVP on File System And Storage
    > xxxxx@storagecraft.com
    > http://www.storagecraft.com
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > Scandanavia the "civilian" clock is the classic 12-hour clock,

    It's classic only for Anglophones :-) together with the Farenheigt temperature and inches+feet+miles.

    Metric countries (nearly whole Europe+exUSSR+China+IIRC Asian/Pacific) use 24 hour clock.

    Nevertheless, in Russia, in everyday speech, we say "8 of evening" and not "20". But, in any official context, 24hour scale is used.

    Also, in Russia, Gregorian calendar was only accepted _by the communists in around 1918_, before this, _Julian_ calendar was used.

    The reason is that the Russian Orthodox Church dislikes anything going from Roman Popes, including the calendar in this case.

    The Russian Church is still using Julian calendar internally. That's why Christmas in Russia is early Jan and not late Dec.

    > valid for legal documents, where the date must be in the form of "The
    > <nth> day of the <kth> month of the <mth> year of the reign of our emperor
    > <name>." And Windows supports this!

    Oh really? This is one of the most amazing facts on Windows I've known.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,345
    <quote>
    The Russian Church is still using Julian calendar internally.
    </quote>

    Actually, that goes for the entire Eastern Orthodox Church, of which the Russian Orthodox Church is but one branch.

    Now... as to when Christmas is celebrated... that's actually a more complicated question.

    <quote>
    the Russian Orthodox Church dislikes anything going from
    Roman Popes
    </quote>

    LOL... yes, that's PART of it. Anything that smacks of the Papacy is anathema to the Eastern Orthodox Church, for sure. The other part is that the Eastern Orthodox Church is about things being unchanging. The Julian Calendar was in use at the start of the Common Era, and ... well ... that was good enough then, it should be good enough now.

    People tend to think that the Gregorian calendar has been used forever, but that's far from the truth. It's use is only relatively recent in most countries. Great Britain adopted it in 1752. And the Gregorian Calendar was only adopted in Russia after the October Revolution, which took place on October 1917 of the JULIAN calendar (or, at least, so says Wikipedia... and we all know that Wikipedia is always right).

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >Calendar was only adopted in Russia after the October Revolution, which took place on October
    >1917 of the JULIAN calendar

    Exactly, that's why the anniversary of the _October_ revolution (one of the 2-3 USSR's major holidays) is _November 7_.

    IIRC Gregorian calendar was adopted in Russia in Feb 1918, with a leap of Feb 1 - then Feb 14.

    --
    Maxim S. Shatskih

    Microsoft MVP on File System And Storage

    xxxxx@storagecraft.com

    http://www.storagecraft.com
  • James_HarperJames_Harper Member Posts: 1,615
    > > valid for legal documents, where the date must be in the form of "The
    > > <nth> day of the <kth> month of the <mth> year of the reign of our
    > > emperor <name>." And Windows supports this!
    >
    > Oh really? This is one of the most amazing facts on Windows I've known.
    >

    I am in awe of the fact that the death of a person would require a reasonably urgent hotfix to an operating system (assuming that law would demand that the crowning of a new emperor would require his name be used in all dates from that point on).

    James
  • Phil_BarilaPhil_Barila Member - All Emails Posts: 148
    Why would that require a hotfix? The <name> construct is evocative of a format specifier, no?

    Phil

    Not speaking for LogRhythm
    Phil Barila | Senior Software Engineer
    720.881.5364 (w)
    LogRhythm, Inc.
    A LEADER in the 2013 SIEM Magic Quadrant
    Perfect 5-Star Rating in SC Magazine for 5 Consecutive Years

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
    Sent: Monday, December 16, 2013 1:40 PM
    To: Windows System Software Devs Interest List
    Subject: RE: Re:[ntdev] Re:Re:Re:IRQL rules for RtlXxxString functions

    > > valid for legal documents, where the date must be in the form of
    > > "The <nth> day of the <kth> month of the <mth> year of the reign of
    > > our emperor <name>." And Windows supports this!
    >
    > Oh really? This is one of the most amazing facts on Windows I've known.
    >

    I am in awe of the fact that the death of a person would require a reasonably urgent hotfix to an operating system (assuming that law would demand that the crowning of a new emperor would require his name be used in all dates from that point on).

    James


    ---
    NTDEV is sponsored by OSR

    Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

    OSR is HIRING!! See http://www.osr.com/careers

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    James Harper wrote:
    >>> valid for legal documents, where the date must be in the form of "The
    >>> <nth> day of the <kth> month of the <mth> year of the reign of our
    >>> emperor <name>." And Windows supports this!
    >> Oh really? This is one of the most amazing facts on Windows I've known.
    > I am in awe of the fact that the death of a person would require a reasonably urgent hotfix to an operating system (assuming that law would demand that the crowning of a new emperor would require his name be used in all dates from that point on).

    I used to work with a rather strange fellow who insisted on using that
    style of date in his comments. So, where I would have written "10 June
    1988", he wrote "10 June, Showa 63". When I asked him about it, he
    tried to make a self-righteous claim that he objected to basing his
    entire timekeeping system on "the birth date of some poor schmuck". I
    wanted to point out that the Japanese emperor was "some poor schmuck",
    but I decided it was better just to drop it and back away slowly.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • <quote>
    Actually, that goes for the entire Eastern Orthodox Church, of which the Russian Orthodox Church is but one branch.
    </quote>

    Peter,

    This will probably be the only time I ever correct you. The Eastern Orthodox church is more fragmented than one might imagine, as not all churches are in communion. The largest schism is due to a disagreement over the fourth Ecumenical council. More recently, there is the schism in Ukraine as one portion recognizes the Moscow Patriarch, and the other portion recognizes the Kyiv Patriarch.

    The Greek Orthodox church is also split. The Old Calendarists adhere to the Julian calendar while the New Calendarists (the vast majority, including myself) adhere to the Gregorian calendar for Christmas and the Julian for Easter. This occurred if I am not mistaken, in the 1920's. Just don't ask me why on that one.
  • anton_bassovanton_bassov Member Posts: 5,022
    <quote>

    LOL... yes, that's PART of it. Anything that smacks of the Papacy is anathema to the Eastern Orthodox Church, for sure. The other part is that the Eastern Orthodox Church is about things being unchanging. The Julian Calendar was in use at the start of the Common Era, and ... well ... that was good enough then, it should be good enough now.

    </quote>


    Hold on - are not religious discussions of any description strictly prohibited on OSR lists???

    If we proceed at such a pace, I guess we will be discussing politics, salaries and consultancy rates, make hate speeches in a style that even Mr.Kyler himself would not dare to dream of, etc,etc,etc, on OSR lists, pretty shortly......



    Anton Bassov
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,345
    <quote>
    The Eastern Orthodox
    church is more fragmented than one might imagine, as not all churches are in
    communion.
    </quote>

    Thank you, Mr. CK. I humbly stand corrected, and appreciate the definitive clarification.

    <quote>
    Exactly, that's why the anniversary of the _October_ revolution (one of the 2-3
    USSR's major holidays) is _November 7_.
    </quote>

    Just one of the wonderful details of the Soviet calendar.

    Didn't the Soviet Union decide to change the length of the week at one point... from 7 days to 5 days, because a 7 day week was a religious thing? Or, did I simply read that in a pamphlet of hooey distributed by the John Birch Society to demonstrate the vast extent of the evil's of the USSR?

    <quote>
    are not religious discussions of any description strictly prohibited
    on OSR
    </quote>

    Yes, indeed. But not CALENDAR discussions that reference religion parenthetically.

    In any case, we're seriously off topic. Yet another interesting digression. But an off-topic one, for sure.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member Posts: 5,022
    > Didn't the Soviet Union decide to change the length of the week at one point... from 7 days to 5 days,
    > because a 7 day week was a religious thing? Or, did I simply read that in a pamphlet of hooey
    > distributed by the John Birch Society to demonstrate the vast extent of the evil's of the USSR?


    Well, I guess you heard it from Mr.Kyler.......


    Anton Bassov
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA