1. |
Assembler (mind) |
14 sor |
(cikkei) |
2. |
VISUAL C++ UJRA !!! (mind) |
11 sor |
(cikkei) |
3. |
Re: pascal bug ??? -->Mc (mind) |
45 sor |
(cikkei) |
4. |
Re: keyboard buffer flushing... -->Mc (mind) |
20 sor |
(cikkei) |
5. |
lcc+DirectX 6 (mind) |
18 sor |
(cikkei) |
6. |
CD-R programozas (mind) |
18 sor |
(cikkei) |
7. |
fiddling with processes (mind) |
19 sor |
(cikkei) |
|
+ - | Assembler (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hello Coderek!
TASM 3.2-ot hasznalok, es a Pentium Pro/Pentium II procik uj utasitasait
akarom hasznalni, de a TASM 3.2 csak 486-ig ismeri a CPU-kat.
Van megoldas?
Makroval is meg lehetne oldani a dolgot, tud valaki esetleg ilyen makrokrol?
Vagy van olyan freeware/shareware assembler, amiben van ezekhez a CPU-khoz
tamogatas?
Elore is kossz.
K.
>
|
+ - | VISUAL C++ UJRA !!! (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udvozlom a tisztelt programozokat !
Nemreg erdeklodtem hogy van-e valaki, aki hajlando lenne-e felvenni
velem a kapcsolatot levelben, hogy feltehessek par Visual C++-os kerdest.
De semmi. Nos, lehet hogy senki nem olvasta aki ertene e nyelvhez, de
ha esetleg megis, akkor kerem hogy jelentkezzen ! Fontos lenne,
egy vizsgamunka befejezesehez kellene a segitsege !
Koszonettel :
Palvolgyi Gabor
|
+ - | Re: pascal bug ??? -->Mc (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hi inet,"HIX CODER" >!
iC> Egyik programomban tobb valtozot hasznaltam, es teljesen szetszedtem a
iC> programomat, amikor rajottem erre a hibara, amit most az alabbi
iC> programban illusztralnek:
> ----------------------------------------------------------------------------
iC> Var
iC> A, B, C, D, E : Byte;
iC> Result : Longint;
iC> Begin
iC> A:=2; B:=4; C:=8; D:=16; E:=32;
iC> Result:=a*b*c*d*e; {2*4*8*16*32 = 32768}
iC> Writeln(Result);
iC> End.
> ----------------------------------------------------------------------------
iC> Ha valaki elinditja ezt a programot, az eredmenyt negativ elojellel fogja
iC> kiirni a Pascal. De miert? ? ?
nos... szoval ugye ez 1 nehez kerdes, hogy mit min kell kiszamolni...
szoval, ha bytekrol van szo, akkor elvileg byte-ben kell szamolnia...
eszt ugy ertem, hogy ha byteket szorzol, akkor o arra nem is gondol,
hogy az esetleg kilephet belole.. es vajjuk be, az esetek nagy tobbsegeben
tok folosleges neki bytenel nagyobbal szamolnia /azaz a cput 1 kicsit
nagyon +terhelnie;)))/ sokkal gyorabb byten szorozni, min' dwordon...
eszt be kell latni... /foleg, ha 16 bytes szorzasokkal szamol dwordon;)/
szoval ezert o ezt valoszinu wordon szamolja... ez telleg bug, mer'hogy
byten kene neki... de ez gondolom teged nem vigasztal... iyenkor aszt
tudod tenni, hogy vagy a valtozokat atirod longintre /neha nem yon be,
mer' akko' builtin asmban nem tucc veluk mit kezdeni;)/ vagy pedig
a kovetkezokeppen modoSITod a kodot, ahol tudod, hogy nagyobb lesz
az eredmeny, es nem lesz eleg, ha source(k) tipusaval szamol:
> ----------------------------------------------------------------------
var
a,b,c,d,e:byte;
r:longint;
.
> ----------------------------------------------------------------------
no yo kodolast oszt vigyazzatok magatokra...;)))
Mc
|
+ - | Re: keyboard buffer flushing... -->Mc (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hi inet,"HIX CODER" >!
urites:
iC> KEYB_BUF_SEG EQU 0040H ;segment for keyb buff
iC> KEYB_BUF_START EQU 001AH ;keyb buff start ptr
iC> KEYB_BUF_TAIL EQU 001CH ;keyb buff tail ptr
iC> mov bx, KEYB_BUF_SEG
iC> mov es, bx
iC> mov bx, 001EH ;ES:BX->kbd buffer
iC> mov es:KEYB_BUF_START, bx ;clear kbd buffer
iC> mov es:KEYB_BUF_TAIL, bx
esem rossz, de akkor mi lenne, ha optimalnank 1 kicsit? ;)
sub ax,ax
mov ds,ax
mov ax,def:[41ah]
mov def:[41ch],ax
no yo kodolast....;)))
Mc
|
+ - | lcc+DirectX 6 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
En is letoltottem az lcc-t, es kezdem kiismerni. Szeretnek vele DirectX
6-os progit forditani, de szegeny lcc csak korabbi DX-re van
felkeszitve. Szivesen varom azok tanacsat, akik meg tudtak oldani a 6-os
ala valo forditast is.
(Probaltam a .h es .lib fajlokat atmasolni a DX SDK-bol, de nem jott
ossze pl.
error: ddraw.h: Missing parameter type...)
Orulnek, ha osszejonne a dolog.
Koszi, udv.: Nova
--
-= Navrasics Istvan (Nova) * IRC: _Nova_ * ICQ# 29357624 =-
-= http://hp.elte.hu/~nova * mailto: =-
-= SuSE Linux 6.0 kernel 2.2.1. =-
|
+ - | CD-R programozas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv!
Erdekelne forraskod (ASM/ pascal/ C)/ algoritmus/ Web site/ szakirodalom CD
iro altalanos (driver szintu) programozasaval kapcsolatban DOS, esetleg
Win.. alatt. Konkretan szektoronkenti iras (akar "raw", akar "cooked"),
esetleges iras elokeszites (gap?), stb. kellene, a szabvanyos
adatformatumoktol fuggetlenul.
Dokumentalt modszerrel egyenlore alig talalkoztam, az MSCDEX Int 2F/1509
(abszolut szektoriras) proba utan itelve ugy tunik, hogy nem implementalt
(szemben pl. a 1508 - szektor olvasassal). A kozvetlen karakteres eszkoz
szintu CD irasrol nincs olyan doksim, ami egyertelmuen utalna valamifele
kovetendo algoritmusra.
Kozvetlen I/O parancsok is erdekelnenek, ha nincs mas modszer.
Elore is koszi:
Leslie
|
+ - | fiddling with processes (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hali!
Van egy kis gondom processekkel kapcsolatban.
Adva van egy szülö és egy gyerek.
A gyerek csinál valamit, aztán át akarja adni a szülnek az eredményt. A
szülö az nem lóghat a gyerek pipe-ján a válaszra várva, mert akkor a júzer
megeszi a kefét.
Gondoltam a gyerek küldhetne egy SIGUSR1-et a szülönek, amit az majd
lekezel valahogy. De ehhez kellene a szülö PID-je a gyerek process
számára. Tudja valaki, hogy ezt hogy lehet megszerezni?
Itt még nem érnek véget a gondjaim, mert hát X alatt (motif) nem én írom a
végrehajtási ciklust, hanem az Xt. A szignál kezelö rutint pedig oda
illene beilleszteni, ugyanis szüksg lenne benne realloc()-ra és népi
együttesére amit illetlenség lenne beírni a signal handle-be. Van
valakinek valami ide vágó ötlete?
--
Live fast, die hard.
ImRe
|
|