A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows 7 » Windows 7 Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Gibson's Meltdown/Spectre Tester



 
 
Thread Tools Rate Thread Display Modes
  #31  
Old January 18th 18, 09:47 AM posted to uk.comp.homebuilt,alt.windows7.general
Jeff Gaines[_2_]
external usenet poster
 
Posts: 86
Default Gibson's Meltdown/Spectre Tester

On 18/01/2018 in message
XnsA86DE9765B573HT1@3pt7fw8U7aCGtyJCnVIIkUzL6V7eb B2xECPht83.A334jDo4AfjRd6C
Diesel wrote:

I was somewhat startled in discussion with a youngish computing
graduate - I think in the last ten years, but probably not much
more recent than that - to discover he'd never done any assembler.
But IT is so big these days that there will indeed be room for
people at all levels. And, sad though it may be for some of us
oldies, modern processing power (and storage, both RAM and disc)
are such that it really isn't necessary to write compact code
(unless you're writing for microcontrollers - and even those have
huge amounts compared to what I grew up with).


Those are not valid reasons to cease writing tight/compact code.
Those are excuses to make your program bloated and resource wasteful
and we continue to see ample evidence of just that.


Absolutely!
That, unfortunately, is what MSFT does.

--
Jeff Gaines Wiltshire UK
There is no reason anyone would want a computer in their home.
(Ken Olson, president Digital Equipment, 1977)
Ads
  #32  
Old January 18th 18, 11:11 AM posted to uk.comp.homebuilt,alt.windows7.general
mechanic
external usenet poster
 
Posts: 1,064
Default Gibson's Meltdown/Spectre Tester

Diesel wrote:

"J. P. Gilliver (John)"
Thu, 18 Jan 2018 00:22:19 GMT in
alt.windows7.general, wrote:

In message
, pjp
writes: []
I'm surprised people find assembler something they don't
expect to be used anymore. I would suspect that an assembler
level programmer would build up a toolbox of canned routines
used over and over again no different than people constantly
using any language. Even in C/C++/Pascal & Delphi (geez even
dBase in it's day) I had a library of "utility" routines I
constantly used.


I was somewhat startled in discussion with a youngish computing
graduate - I think in the last ten years, but probably not much
more recent than that - to discover he'd never done any
assembler. But IT is so big these days that there will indeed
be room for people at all levels. And, sad though it may be for
some of us oldies, modern processing power (and storage, both
RAM and disc) are such that it really isn't necessary to write
compact code (unless you're writing for microcontrollers - and
even those have huge amounts compared to what I grew up with).


Those are not valid reasons to cease writing tight/compact code.
Those are excuses to make your program bloated and resource
wasteful and we continue to see ample evidence of just that.


Surely the point is that the source should be easily maintainable
and easy to understand - it's the compiler's job to turn that into
compact object code.
  #33  
Old January 18th 18, 01:02 PM posted to uk.comp.homebuilt,alt.windows7.general
woo
external usenet poster
 
Posts: 7
Default Gibson's Meltdown/Spectre Tester

On 18-Jan-18 4:37 AM, VanguardLH wrote:
woo wrote:

Paul wrote:

He also mentions why AVs were false triggering on his InSpectre.exe file
when users were downloading it. One of his on-off toggles involves a
registry change and AVs where triggering on it. So he encrypted the
registry key's name and data item value.


Interesting, I'm not sure how that would work as I'd have thought he'd
have to be calling RegOpenKeyExA and RegSetValueExA where obviously
these are procedures in an external masm library. Or I guess what I'm
saying is that I personally would have no clue how to insert an
encrypted key name in the actual asm code that followed.


Although his tool still writes
to the registry, the AVs stopped triggering on that behavior (they
didn't know what was the registry key's unencrypted name). He submitted
a test version in his private forum to have his subscribers check if the
AVs were still triggering on his .exe file. The download is dated today
but I don't know if it is his test release he gave to his subscribers
and fellow testers. Avast did not alert on the file's download or run.


  #34  
Old January 18th 18, 01:34 PM posted to uk.comp.homebuilt,alt.windows7.general
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 2,679
Default Gibson's Meltdown/Spectre Tester

In message , Paul
writes:
J. P. Gilliver (John) wrote:

From what I've seen, C (for example) produces a lot of inefficient
code, which on the whole I'd say I could recognise.


In the hands of the wrong individual, yes.

Depends on whose definition of "wrong" you are using (-:
*******

You can compile to .s format, which is assembler metainstructions,
and see what the code quality looks like. The example at the
top of this page, is a particularly poor choice for an
efficiency explanation. What I want to point out in this link,
is you can generate a .s file using GCC, then examine it in comfort.
You don't have to use a hex editor on the object code, to review
what it's doing.

https://stackoverflow.com/questions/...le-the-asm-gen
erated-by-gcc


Thanks; I've saved your post for future reference, but I suspect my
coding days are long past: I haven't written any code (apart from a bit
of HTML, and that HTML 3) for years. I've never coded for a GUI.

Try some arithmetic statements in your test.c,
then tell me how efficient the test.s is, and how much wonky
overhead there was.

If you really need efficiency, you don't have to drop to
assembler and do the whole thing there. You can simply review
the .s and hand-optimize your source as desired.


(I take it .s is for "source code"?)

That only works if you have the #pragma to generate whizzy
instructions. For example, you might have to do something
special to have an instruction sequence emitted as AVX512 say.
You should have no problem generating ADD,SUB,MUL,DIV with
a little (integer) test program.

You can also experiment with compiler optization,
like -o, -o2 and so on, and see what effect that has,
Maybe some assembler is moved out-of-order, for better performance.
Initially, you'll want to test with no -o at all.


I just wonder how much of this sort of optimisation is widely done these
days: with the possible exception of high-density crunching app.s, like
video and perhaps audio processing, is it worth the programming effort
(which equates to money for commercial software producers, and time even
for freeware ones - though I feel the latter _do_ do it more). With
modern multicore processors, and OSs (?) that optimise code between
cores even if the original code doesn't, and the plummeting cost of RAM
and HD storage, who's going to even notice the odd extra second or so
here and there. (Not to mention the willy-waving aspect _some_ software
vendors, or _some_ of their departments, seem to still have about code
size ["if the code needs a DVD or two to be installed from, it must be
good"].)

Programmer time (resource) is often seen as better spent adding new
features, or - occasionally - fixing bugs, that code optimisation (with
the exceptions I have mentioned, plus some scientific purposes, and
maybe server software). [The same of course applies to the supporting of
older OSs.]

If you don't think the game is honest, there's at least
one free disassembler for x86 you can get. And you can
review the code after object is generated.


Reverse engineering. Hard work (-:, for not-your-own code! (Not easy
when it _is_ your own!)

Paul

John
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

.... the pleasure of the mind is an amazing thing. My life has been driven by
the satisfaction of curiosity. - Jeremy Paxman (being interviewed by Anne
Widdecombe), Radio Times, 2-8 July 2011.
  #35  
Old January 18th 18, 02:10 PM posted to uk.comp.homebuilt,alt.windows7.general
Richard Kettlewell[_2_]
external usenet poster
 
Posts: 31
Default Gibson's Meltdown/Spectre Tester

Diesel writes:
"Mayayana" news Wed, 17 Jan 2018 20:13:52 GMT in alt.windows7.general, wrote:
That would depend. A basic compiled executable
(as opposed to .Net, Java, scripting, etc) is compiled
to native or machine code -- the actual CPU operations.


Actually, most of the time, with the exception of a select few
compilers; that's not the case. They compile to pseudo machine
language with a runtime present inside the executable that performs
the low level translation work. There are some exceptions to this,
but the more well known compilers are not taking your c/c++/basic
source code and translating it verbatim to machine code inside your
executable.


Which C/C++ compilers do you think do this rather strange thing? A
moment with a disassembler will reveal that GCC, Clang and MSVC do not.

--
https://www.greenend.org.uk/rjk/
  #36  
Old January 18th 18, 03:20 PM posted to uk.comp.homebuilt,alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Gibson's Meltdown/Spectre Tester

"Diesel" wrote

| That would depend. A basic compiled executable
| (as opposed to .Net, Java, scripting, etc) is compiled
| to native or machine code -- the actual CPU operations.
|
| Actually, most of the time, with the exception of a select few
| compilers; that's not the case. They compile to pseudo machine
| language with a runtime present inside the executable that performs
| the low level translation work.

You mean like a python program? I'm talking
about compiled software. Compiled to native code.
What's running when just about any software
you use is running. (For the most part, .Net,
Java and Python are not running on desktops.)
Many have "runtimes". All of the VC++ versions
have runtimes. But those are companion function
collection libraries, also compiled to native code,
not interpreters.

| Looking at inspectre.exe, it contains a digital
| signature and it's marked as compressed with UPX.
| Decompressing and reading the bytes indicates
| that there's embedded RTF text that gets loaded
| into a RichEdit window. Not likely to be done with
| assembly. Even if it's possible it wouldn't make
| sense.
|
| Native win32 assembly can also make full use of Win api functions; In
| fact, you're encouraged to do so.

Yes, but why? He's making a GUI program
that uses a Richdit window, 3 system button
windows, and RTF text. Why not use a tool
designed to do that more easily and save the
low level code for things that require low level?

I can use an old fashioned
hand drill to drive drywall screws, at least
in theory, but it's going to take an awfully
long time. I could learn to start a fire by
rubbing sticks together. I could refuse to
use "lazy", "high level" technologies like
running water and gas stoves and electric
lights. And of course, some people do that.
It might be an interesting experience or an
impressive discipline, but not necessarily the
best way to spend one's time.


  #37  
Old January 18th 18, 06:17 PM posted to uk.comp.homebuilt,alt.windows7.general
VanguardLH[_2_]
external usenet poster
 
Posts: 10,881
Default Gibson's Meltdown/Spectre Tester

Bill wrote:

VanguardLH WROTE:

Besides the AVs looking for the malicious behavior, the OS gets
patches to mitigate the attacks. Only time will tell if Microsoft
will use the patches to leverage their customerbase in pushing them
to Windows 10 by not providing the updates to prior versions of
Windows.


As the original follow-up was limited to one ng,


My client warns me if FollowUp-To is used. Polite use is limited to
very few scenarios, like submitting a spam exhibit in one newsgroup but
discussing it in a different newsgroup (to keep the exhibits clean).
Otherwise, it is rude to shotgun a post by cross-posting to multiple
newsgroups where there is no intention to involve those other
communities. If you use FollowUp-To, you should only be posting to one
newsgroup (but then you don't need FollowUp-To for that). It is rude to
yank away the discussion to the other newsgroups if you wish not to
continue the discussion over there.

I'll repeat my observation that when I run this tester on my 32-bit
Windows machine, I get a message that Microsoft is only providing
patches for 64-bit systems and has no plans to change this.


Not only for 64-bit only machines but also only for the latest release
of Windows 10. So far, Microsoft has not released its patches for
Windows 7 & 8. That may change. Depends on how long Microsoft wants to
use this as leverage to push users off their old OSes. Remember the
original cutoff date for Windows XP support but that got extended? The
same could happen for Windows 7 & 8 regarding these security patches.
Windows 7 still has extended supported until 13-Jan-2020 for security
updates - and these fixes are definitely security updates. If Microsoft
doesn't update Windows 7 & 8 then they lose all that marketing blitz
regarding their claimed security support. I very much doubt Windows XP
will ever receive these updates.

The timing is so close between when Microsoft pushed their security
updates to when Google released their open source Retroline (Return
Trampoline) solution. If Microsoft did not incorporate Retroline, they
may do so in a later update. Microsoft's patch incurs a performance hit
in all implementations as they used only one instruction (something like
CPUid) instead of also using the other paired instruction (something
like invCPUid). The two together incur not performance penalty but
using only one does. However, while the CPUid instruction was added to
Intel processors somewhere around 2003, the 2nd instruction wasn't added
until the Haswell family and thereafter. I'm still using an old Intel
Core 2 quad-core processor so the security updates, if and when
available, WILL incur a performance penalty on my machine. There are
ton of Core 2 hosts still out there (last I checked, Core 2 outnumbered
all the other active processor usage). Haswell was for 4th generation,
and later, of the [Core] i3, i5, and i7 processors.

Folks with smartphones are in an even worse situation. Typically locked
(branded) phones don't get OS updates. The cellular providers don't
want the image or state of their products changing because that means
more support. I've had several locked phones that NEVER got updates.
Even unlocked phones may not get updates. LG decided to skip 7.1 and go
directly from 7.0 to 8 for an OS upgrade but who knows when that will
get pushed to customers, especially now that they'll have to wait a bit
longer for yet another Android version that incorporates the security
updates. Pixel users will get updated but others will have to wait or
never get the updates so smartphone will remain vulnerable for a very
long time. All IoT devices will remain vulnerable for a long time.

I'll wait until the vulnerabilities actually show up in the wild. I'm
not panicking over POCs.
  #38  
Old January 18th 18, 10:40 PM posted to uk.comp.homebuilt,alt.windows7.general
Vir Campestris
external usenet poster
 
Posts: 10
Default Gibson's Meltdown/Spectre Tester

On 18/01/2018 08:44, Bill wrote:
As the original follow-up was limited to one ng, I'll repeat my
observation that when I run this tester on my 32-bit Windows machine, I
get a message that Microsoft is only providing patches for 64-bit
systems and has no plans to change this.

I have to maintain a couple of 32-bit machines here because of certain
hardware and software constraints.


This is an old PC, and although it's 64-bit capable I put Windows 7
32-bit on it all those years ago.

If MS really are going to withdraw support I'll be force to put Ubuntu
on it (which I use at work). That won't help MS...

Andy
  #39  
Old January 18th 18, 10:59 PM posted to uk.comp.homebuilt,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Gibson's Meltdown/Spectre Tester

Mayayana wrote:
"Diesel" wrote

| That would depend. A basic compiled executable
| (as opposed to .Net, Java, scripting, etc) is compiled
| to native or machine code -- the actual CPU operations.
|
| Actually, most of the time, with the exception of a select few
| compilers; that's not the case. They compile to pseudo machine
| language with a runtime present inside the executable that performs
| the low level translation work.

You mean like a python program? I'm talking
about compiled software. Compiled to native code.
What's running when just about any software
you use is running. (For the most part, .Net,
Java and Python are not running on desktops.)
Many have "runtimes". All of the VC++ versions
have runtimes. But those are companion function
collection libraries, also compiled to native code,
not interpreters.

| Looking at inspectre.exe, it contains a digital
| signature and it's marked as compressed with UPX.
| Decompressing and reading the bytes indicates
| that there's embedded RTF text that gets loaded
| into a RichEdit window. Not likely to be done with
| assembly. Even if it's possible it wouldn't make
| sense.
|
| Native win32 assembly can also make full use of Win api functions; In
| fact, you're encouraged to do so.

Yes, but why? He's making a GUI program
that uses a Richdit window, 3 system button
windows, and RTF text. Why not use a tool
designed to do that more easily and save the
low level code for things that require low level?

I can use an old fashioned
hand drill to drive drywall screws, at least
in theory, but it's going to take an awfully
long time. I could learn to start a fire by
rubbing sticks together. I could refuse to
use "lazy", "high level" technologies like
running water and gas stoves and electric
lights. And of course, some people do that.
It might be an interesting experience or an
impressive discipline, but not necessarily the
best way to spend one's time.


Personally, I prefer that people keep their implementation
details to themselves. If you wrote it in LISP
or COBOL, that's your business.

I can relate a work story.

We had labs in multiple cities at work.

One of the other labs, a guy shows up one day, to show
us the LAN he's built up for our computers. Now, if
you want to give a demo, you'd bring some hardware
cards, a couple pieces of cable, and give a demo.
Then the audience could go "ooh shiny" and so on.
Coffee and muffins afterwards.

What does he do ? As an evangelist, he shows up with
zero hardware samples, nothing to look at in the
hardware area. *But*, the idiot does bring a 3" thick
stack of *assembler listings* and says "see, I wrote
all the code for this project in assembler". In other
words, "I'm a kook, and I'm here to make your day".
And he keeps waving that stack around. Rather
than promoting his project, he was actually
an assembler promoter. I can tell you the reception
he got was pretty chilly. If the guy had said to himself
"what hot button can I push to **** people off
in a work context", he succeeded :-) It would be
like he showed up for the presentation, not
wearing any pants.

Now, that's the situation I would want to avoid.

You can be proud of many things (your new LAN
invention), but writing a 3" stack of assembler
for the *whole* thing, isn't one of them.

It would be like the dry waller showing up
at your house, to do a quote, and keep waving
boxes of dry wall screws around in front of
your face :-) Or maybe showing you the *hammer*
he plans on using, to drive the screws into
the dry wall :-) Most people just want to see
that smooth flat wall when the job is done.
If we weren't forced to contemplate these things
as an audience, we'd be much happier. The details
of making sausage might not be all that palatable.

The author of Prime95 writes in a mix of HLL and
assembler. He has hand-optimized custom FFT routines,
as that's how he screens for Mersenne primes. And
different code modules are provided for the more
modern processors (he's somehow used one of the
flavors of AVX for this). You could make an
argument that the split makes sense. The "hot spot"
in the code, is in assembler. The GUI is not.

Paul
  #40  
Old January 19th 18, 12:03 AM posted to uk.comp.homebuilt,alt.windows7.general
Vir Campestris
external usenet poster
 
Posts: 10
Default Gibson's Meltdown/Spectre Tester

On 17/01/2018 18:20, J. P. Gilliver (John) wrote:
it produces the smallest, fastest, code.


Old assembler programmer here.

Although in theory you can produce better code in assembler, in practice
modern compilers will do all sorts of evil tricks to make things go
faster. Like random use of registers, keeping stores well before loads
of the same data to stop pipeline stalls, laying things out to suit
cache lines, to name but a few.

It was OK on the 8086 (5 word prefech queue IIRC, no cache), but these
days I can't keep the knowledge of all the different blocks in my head,
and still think about the program. C is almost always fast enough. C++
makes more reliable programs, and it's usually fast enough too...

Andy
  #41  
Old January 19th 18, 12:53 AM posted to uk.comp.homebuilt,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default Gibson's Meltdown/Spectre Tester

On 17/01/2018 15:10, Wolf K wrote:
On 2018-01-17 08:24, Jaimie Vandenbergh wrote:
On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Â*Â*Â*Â*Cheers - Jaimie


OK, but is he a clever loon?


Definitely.

He uses a large library of macros with assembler so his code does look
rather like a weird high level language of his own design.

--

Brian Gregory (in England).
  #42  
Old January 19th 18, 01:09 AM posted to uk.comp.homebuilt,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default Gibson's Meltdown/Spectre Tester

On 17/01/2018 11:28, Paul wrote:
PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.


That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


This is very "I couldn't do it therefore anyone who could is weird".

I know most people like to write in high level languages and adopt a get
something down now and we can poke and prod at it randomly later until
it seems to work right.

Surely being able to write code in a language that more or less demands
you get it 100% right first time and succeed in getting it right is
something to be admired.

--

Brian Gregory (in England).
  #43  
Old January 19th 18, 01:27 AM posted to alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default Gibson's Meltdown/Spectre Tester

On 17/01/2018 09:26, PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.


All the details he
https://www.youtube.com/watch?v=Lh6E...u.be&t=1h8m26s

--

Brian Gregory (in England).
  #44  
Old January 19th 18, 01:48 AM posted to uk.comp.homebuilt,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Gibson's Meltdown/Spectre Tester

Brian Gregory wrote:
On 17/01/2018 11:28, Paul wrote:
PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.


That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


This is very "I couldn't do it therefore anyone who could is weird".

I know most people like to write in high level languages and adopt a get
something down now and we can poke and prod at it randomly later until
it seems to work right.

Surely being able to write code in a language that more or less demands
you get it 100% right first time and succeed in getting it right is
something to be admired.


It's called using the right tool for the job.

I can build the Taj Mahal from toothpicks, but
that doesn't make it right.

For some tasks, you have to drop to assembler, as a HLL
just won't do. If you're good, you'll use your tools
selectively, a hammer for hammering, a screwdriver
for driving screws - not a hammer for driving screws.

A GUI doesn't need to be built from assembler. That's
why they put all those APIs and libraries there, so you
need less than a page of code to put it on the screen.

If you need to emit a privileged CPUID instruction in
your code, I'd buy the need to do a little inline code
or the like, to do it. Some things require a few tricks,
if they aren't in a library already.

Paul
  #45  
Old January 19th 18, 02:01 AM posted to uk.comp.homebuilt,alt.windows7.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 166
Default Gibson's Meltdown/Spectre Tester

On 19/01/2018 00:48, Paul wrote:
Brian Gregory wrote:
On 17/01/2018 11:28, Paul wrote:
PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


This is very "I couldn't do it therefore anyone who could is weird".

I know most people like to write in high level languages and adopt a
get something down now and we can poke and prod at it randomly later
until it seems to work right.

Surely being able to write code in a language that more or less
demands you get it 100% right first time and succeed in getting it
right is something to be admired.


It's called using the right tool for the job.

I can build the Taj Mahal from toothpicks, but
that doesn't make it right.

For some tasks, you have to drop to assembler, as a HLL
just won't do. If you're good, you'll use your tools
selectively, a hammer for hammering, a screwdriver
for driving screws - not a hammer for driving screws.

A GUI doesn't need to be built from assembler. That's
why they put all those APIs and libraries there, so you
need less than a page of code to put it on the screen.

If you need to emit a privileged CPUID instruction in
your code, I'd buy the need to do a little inline code
or the like, to do it. Some things require a few tricks,
if they aren't in a library already.

Â*Â* Paul


Just because it's not the right tool for you doesn't mean it's not the
right tool for someone who does it all the time and has a massive
library of macros to help him.

I bet most of the 5 or 6 days it took him to do it were taken up with
reading and understanding the processors and the vulnerabilities anyway.

--

Brian Gregory (in England).
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 09:57 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.