Петър Николов

Както е описано в "Дебелите книги" Windows 32 може да поддържа до 4G ram:
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

Но явно някой е взел "ограничението" много присърце и е публикувал начин за премахване на ограничението:
http://www.geoffchappell.com/viewer.htm?doc=notes/windows/license/memory.htm

Уви горепосочения код работи само под Vista, но съм убеден че с елементарни промени може да се портне и към Windows 7.

Ако сте си редактирали настройките на Windows и "случайно" сте открили че hibernate вече не работи проверете DisablePagingExecutive али не е на 1. За да проработи hibernate настройката трябва да е 0!

Ето и хитър метод за превключването му (и много интересен начин за бърза промяна)

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v DisablePagingExecutive /t REG_DWORD /d 0x00 /f

Сега какво е значението на 0 и 1. Според TechNet - http://technet.microsoft.com/en-us/library/cc959492.aspx при 0 части от кернела заедно с някой драйвери МОЖЕ да се запишат в pagefile. При 1 за съжаление те винаги си остават във физическата памет (т.е. функцията за пейджване няма да проработи).

Това http://www.zezula.net/en/prog/lpc.html е статията която чаках от няколко години.

LPC (Local Procedure Call) е начин за IPC под Windows който обаче не е много добре документиран в MSDN, но се използва масово за комуникация от системните файлове на Windows.

Това отваря нови врати в изследването на Windows поне за мен.

Vista идва със нов TCP стек и има известен проблем заради нещо наречено "Receive Window Auto-Tuning".

Накратко - в TCP има един параметър Receive Window който указва какъв размер данни може да се изпрати преди да се изчака потвърждение от другата страна, че са получени. Това позволява оптимизация в известна степен на канала защото грешки са сравнително рядко срещани и има съществен принос за увеличения трафик. Ако параметъра е малък при два-три пакета изпращането на нови спира докато не дойде потвърждение - това не е особенно ефективно в LAN и broadband средите. Ако параметъра е голям - може да бъдат изпратени 65535 байта и тогава да се разбере, че другата страна не може да ги получи или ги е получила с някаква грешка - тогава целия прозорец от 65535 байта трябва да се изпрати наново и не е най-ефикасния метод при модемни връзки.

Сега - наясно съм че няма пълно щастие. От Корпорацията също. Затова стандартно Windows XP беше оптимизиран за модемни връзки което доведе до бум на всякакви продукти увеличаващи мрежовата връзка. С излизането на SP2 нещата бяха пооптимизирани към broadband връзки, но все пак имаше още какво да се желае в повечето случаи.

С излизането на "най-перфектната" OS някоя мъдра глава е седнала и е решила че параметъра може да се настройва автоматично от TCP стека което безспороно е една стъпка напред в правилната посока. Друга глава (може и същата да е) е направила прозореца да бъде до 16 мегабайта! Това е втора ОГРОМНА стъпка също в правилната посока - вече gigabit ethernet е почти ежедневие, а са обявани и още по-бързи технологии.

За ОГРОМНО наше съжаление понякога се получава голямо мрежово забавяне заради инфраструктура или някаква несъвместимост и на хартия изглежда, че не би трябвало да има никакъв проблем, а практически Vista се мъкне в сравнение с XP. Това е особенно видимо под RDP сесия към сървър намиращ се отдалечено (не в LAN) правещо работата в сесия по-скоро дразнеща. Преминаване в същата сесия от XP показва, че проблема не е в отдалечения сървър ами е някаде другаде (някой каза ли Vista?).

Ако имате подобни проблеми следната магическа комбинация би трябвало и на вас да ги реши (пуска се под Administrator! Промените са ГЛОБАЛНИ!):

netsh interface tcp set global autotuninglevel=disabled
netsh interface tcp set global rss=disabled

За повече информация:
KB935400

Корпорацията пак е хваната в издънка.

Този път се изяснява че прословутия Windows Update дори и при положение "Turn off Automatic Updates" все пак се обновява себе си:
Microsoft is fiddling with system files without permission
Confirmation of stealth Windows Update

и обобщителното:
Experts Astonished to Learn Windows Update Updates Itself

Всъщност както винаги издънката е Грандиозна, а коментар за пореден път няма с изключение на високопарното "Automatic Updates трябва да бъде обновен" без много обяснения как и защо.

Бел. Ред. - пропуснах да отбележа, но това се случва и на XP както и на Vista.

Според Корпорацията не е възможно използването в една и съща машина на различни версии на Internet Explorer. Причините са много и все различни. Най-голямата е че просто в COM/ActiveX няма възможност в една система да съществуват няколко различни версии на един обект и при изпълнението да се указва освен обекта и версията която да се използва. С други думи това си е чист DLL HELL, ама малко по-завоалирано. Това е отстранено в .Net платформата и се изтъква под път и над път, но там има други проблеми.

Но както винаги става самаряни са приели нещата присърце и са направили частично това което Големите не могат (или по-скоро не желаят).

Multiple IE
Multiple IEs in Windows

Кратко сравнение между уязвимостите на различни OS.

http://bink.nu/Article10819.bink

Победителите са предварително известни.

Ето още един много полезена административна програмка: Tasklist

Програмата показва списъка с активните процеси в момента. Полезното е че може да показва и списъка с активните services и кой къде се намира в момента. В Windows обикновенно услугите се намират в svchost.exe, но издирването коя услуга къде се намира е доста трудоемко поради факта че винаги има минимум 3-4 svchost процеса в паметта.

С простичкия ред:

tasklist /svc

се демистифицира това. И се показва коя услуга в кой процес "живее". Ако отстрани има N/A това означава, че програмата не е service, ами си е просто процес.

С това:

tasklist /svc /fi "imagename eq svchost.exe"

може да се ограничи списъка само до процесите стартирани от svchost.exe

Отделно ако се стартира с параметър /m това показва списък на наличните модули заредени във процесите. Списъка може да бъде ограничен по име на модул като се използва /fo:

tasklist /m
tasklist /m gdi*

Има още много параметри и опции - ограничаване по име на процес, по статус, по потребител, по сесия. Отделно списъка може да бъде изискан от отдалечен компютър при подадени име на компютъра, потребител и парола. Отделно изхода на програмата може да бъде табличен, списъчен или добре познатия ни CSV.

Всичко това прави програмата доста полезна за адмимнистративни цели каквато всъщност е и основната и цел.

От десетилетия предлагаме терминални услуги

Дрън, дрън. Windows NT4 Terminal Server Edition е пуснат в продажба 1998.

Освен ако не се смята и Citrix MetaFrame - но сметката пак не се вързва защото той е пуснат в 1995 базиран на кода на NT 3.51 и е толкова жестоко променен Windows че повече няма на къде. Затова се сключва през 1997 договор обвързващ бъдещите разработки с Windows като Citrix предоставят тяхните разработки на Корпорацията и те вече са част от Windows, а Citrix си запазва правата върху разработки от по-висок клас. На практика този договор открива пътя за за Windows NT4 Terminal Server Edition и последващите го.

Сега и нещо любопитно: Citrix получава лиценз върху Windows NT 3.5 и Windows NT 3.51. Но не получава такъв за Windows NT 4. Корпорацията създава 2 екипа в опит да клонират MetaFrame като държат Citrix в изолация от NT4. Обаче труда на двата екипа е неадекватен на вложения труд - единия използва готова технология от френската компания Prologue (която бива погълната), а другия се опитва да използва собственно решение. Резултата е плачевен - на един компютър може да работят паралелно около 5 (ПЕТ) клиента едновременно, докато под Citrix може да са 180. Citrix използва технология създадена от John Richardson "Session Space".

Така и двамата бивши партньори са в цунг-цванг, като основния губещ е по-скоро Корпорацията. Заради отказа си да лицензира NT4 тя не може и да използва тази ценна технология. Някъде през далечната 1997 година обаче се стига до споразумение. Но тук вече Корпорацията за пореден път хитрува - не лицензира ICA (транспортния протокол на Citrix), а само промените на ниво ядро на Windows като прави свой собствен протокол RDP базиран на ICU T.Share.

В резултат от договора - Корпорацията ключва кода на Citrix в ядрата на Windows (Първо като отделна версия NT4TSE, но в Windows 2000 кода е наличен във всички версии). Citrix получава правата да създава терминални услуги от по-висок клас предлагащи повече възможностти.

Лично за мен Citrix са герои - те са тези направили WindowsNT да бъде същински multiuser OS. За съжаление както историята учи - Революцията изяжда своите деца.

Нов панаир около Vista.

Изследователя Alex Ionescu (май имама румънски корени) е открил нов начин за зареждане на неподписани драйвери. Използва се дупка в съществуващия драйвер на ATI.

Веднага се вдигна голяма пушилка из интернета.

Резултата:
- ATI поправи проблема във версия 7.8
- Корпорацията веднага го взе и го постави в Windows update за да си обновят потребителите съществуващите драйвери
- Alex Ionescu постави въпроса "абе що не потествате малко драйверите преди да ги подпишете"

ATI driver flaw exposes Vista kernel to attackers

Това само по себе си не е много интересна новина. По-интересното е че 2-3 дена преди нея в Интернет се появи програма със същото предназначение написана от фирма и използваща драйвер. Тук вече панаира беше пълен.

Vista kernel tampering tool released, then mysteriously disappears

Тук вече се стигна до наказателна акция от Корпорацията. Сертификата на фирмата подписала с него драйвера беше revoked (премахнат). Програмата беше поставена в списъка с дефинициите на Windows Defender с цел триене на база "malware".

Windows Vista x64 Driver Signing update

Сега - това говори за нещо много, много опасно. Корпорацията се опитва да запази 64 битовите си версии чисти от всякакви drivers и kernel tools. За наше всеобщо съжаление това би стопирало доста разработчиците и съответно по-бавно навлизане на 64 битовите Windows. Последното и сега се случва и затова няма никаква причина (освен сървърните платформи) към миграция на x64.