Re: zmniejszenie WinSxS

Sempiterna <rzopa@amorki.pl> napisał(a):
> No, w sumie tak... ale kompilator sam jest programem, który w czymś został
> napisany, skompilowany, a jeśli ta komplacja, wskutek albo błędu, albo
> nienajlepszego algorytmu, da wynik powolniejszy...?

Kompilatory właśnie z racji tego, że służą do tworzenia milionów innch
programów są bardzo mocno testowane i błędy w nich są znajdowane bardzo
rzadko.

> W sytuacji, gdy zdarza się, że każdy wolny bajt jest cenny? (mimo, że już
> są terabajtowe dyski, gigabajtowe pamiątki, gigahercowe procki...)

W jakiej sytuacji każdy bajt jest cenny? Jak ma się dysk 20MB?

> Napisałeś "system nie każe kompilatorowi", czyli jak np. odpalam
> kompilator, a moja Szklarenka ma nagle coś i mówi mu np. "kompiluj pod
> AMD"... To chyba programista, czy deklaracje w kodzie, o tym decyduj.ą, a
> nie system, na którym kompilator jest odpalany?

No właśnie o tym piszę :)

> To automatycznie, niepotrzebny zasób, powinien nie być dołączany do
> wyniku, bo dołączony, staje sie śmieciem, który zajmuje pamięć,
> niedostępną już dla innych, potrzebniejszych zasobów.

Ale ile to zajmuje? Ile RAMu masz zajęte przez kod a ile przez inne dane?
Kod zajmuje mało miejsca.

> Rozumiem. Nie mogę jednak oprzeć sie wrażeniu, że wspłczesny kod jest tym,
> jak stary dowcip o malarstwie współczesnym, trochę niesmaczny:
> "Nasrałbym na płótno, rozmazał, poczekał, aż zaschnie, i zatytułowałbym
> go }}Orgazm niedźwiedzia{{". Już bardziej jestem w stanie pojąć malarstwo
> Picassa...

Z rozmiaru pliku wykonwalnego wnosisz, że zawiera on przypadkowe śmieci a
kompilatory działąją losowo i chaotycznie?

>> A writeln to co? Też sam napisałeś tę funkcję?
> Program napisałem.

Ale z użyciem biblioteki.

> Tekst zajmuje 63 bajty.

Jakie znaczenie ma ile zajmuje tekst?

> Czy makro jest rozpisane na kod maszynowy?

A na co innego?

>> Jaką przestrzeń/>
> Może to z dawnych czasów, niekiedy w pliku EXE było sporo wolnego miejsca
> gdzieś w środku, co wyśledzone dawało np. miejsce dla spraw "roboczych"
> programu (na zmienne np.), czy np. w jednym pliku był program, dane,
> konfiguracja... Rozuimem, zapisama np. bitmapa z wyglądem czołówki, OK,
> łyknę to.

Ale AFAIK nie zawsze plik exe ląduje w całości w pamięci, system operacjny
patrzy co należy wczytać. Jak masz samorozpakowujące się archiwum 1GB to OS
nie załaduje całego exe do pamięci bo kodu to tam jest ileś kilobajtów.

> Tylko, że tak myśląc, bezkrytycznie, dojdziemy kiedyś do tego, że aby
> odpalić calc.exe, (w XP 115200 bajtów, dużo IMO), będziemy musieli znaleźć
> plik o objętości 50 MB, odpalalny na maszynie minimum 3 GHz, z 8 GB RAM,
> bo tyle będzie wymagać sam system, by w ogóle pracować, jako absolutne
> minimum. Pamięci nie są z gumy. Ich możliwości kiedyś się wreszcie
> skończą, a wtedy ręka w nocniku...

Wątpię aby to się szybko stało. Poza tym nie wiem czemu łączysz ze sobą
wielkość pliku exe i wymagania sprzętowe.

> Od bajtów. Ich powinno być jak najmniej. Jeśli Kowalski ma duży dysk,
> zajęte 10 %, to mu rybka pipka, czy program ma 10, czy 50 MB, aby działał.
> Jednak w sytuacji, gdy miejsca mi na dysku brakuje (a taką właśnie mam,
> musiałem zrzucić ok. 100 GB backupów, by zacząć w ogóle porządki), to dla
> mnie każdy klobajt jest cenny. Byłbym więc zobowiązany programistom, aby
> kompilator NIE DOŁĄCZAŁ kodu, który nie jest potrzebny i nie zostanie
> nigdy wykonany. Tak, on zapycha dysk.

I zyskasz może parę MB. Jak się dysk kończy to zamiast męczyć się żeby
uzyskać jeden megabajt wolnego miejsca więcej kupuje się nowy.

> Ja zdaję sobie sprawę, że Windows narzuca pewne wymagania i nie da się
> zrobić nawet takiego prostego programu,

Zawsze jest coś narzucone. A ten plik akurat nie miał nic wspólnego z
Windowsem, to był plik ELF na architekturę little endian ARM. Nie wiem
dokładnie co w nim jest ale widać np. symbole.

> 10 INPUT "PODAJ IMIĘ"; A$
> 20 PRNT "WITAJ" + A$+ ", NAZYWAM SIĘ KOMPUTER"
> w 100 bajtach kompilatu. Ale niech to będzie naprawdę tylko tyle, ile jest
> naprawdę niezbędne, bez dołączania rzeszy procedur... Dla mnie do
> przyjęcia będzie kompilat do 4 kB, chyba, ze "narzut Szklarniowy" będzie
> większy...

Możesz sobie to napisać w asemblerze i pod Windows pewnie będzie miało to ze
2kB albo mniej. Jakby to napisać w C to pewnie też by exe było w tych
okolicach, tylko trzeba by trochę pokombinować, np. wywalić runtime C i
trochę pomachać przełącznikami kompilatora i linkera. Narzut systemy
wynikający z budowy pliku wykonywalnego nie jest duży. Narzut bierze się z
dodatkowo wrzucanyc rzeczy. Przykładowo pod Windows taki program:
#include <stdio.h>
int main(void)
{
    printf("hello, world\n");
    return 0;
}

tak naprawdę wygląda następująco:

#include <stdio.h>
int main(void)
{
    printf("hello, world\n");
    return 0;
}
int mainCRTStartup()
{
    int retval;
    init_heap();
    parse_command_line();
    init_global_vars();
    init_exception_handling();
    retval = main();
    ExitProcess(retval);
}

Więc tak naprawdę kod nie składa się z samego wywołania printf. Najpierw
inicjalizowana jest sterta, następnie parsowane są opcje wiersza polecenia,
potem zmienne globalne i wreszcie obsługa błędów. Dopiero w tym momecie
wołany jest main. To wszystko dzieje się niejawnie. Pod Linuksem jest
podobnie. Dlaczego? Bo programiści nie chcą tracić czasu na sterty,
parsowanie opcji itp. Ale jak ktoś nie chce to nie musi z tego korzystać,
może sobie pisać sam jak mu szkodza każdego bajtu. Tylko wtedy się namęczy a
jego program będzie dużo, dużo droższy. Droższy niż ewentualny upgrade
sprzętu.
Nie ma tu wię żadnego szklarniowego czy linuksianego narzutu, narzut wynika
z wygody programisty i względów ekonomicznych.

-- 
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i aktualności ze świata Outlook Express: grzegorz.net/oe
Uptime: 2 days, 9 hours, 3 minutes and 30 seconds