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
  #61  
Old January 20th 18, 10:23 PM posted to uk.comp.homebuilt,alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Gibson's Meltdown/Spectre Tester

"Paul" wrote

| On the other hand, I'm self taught and could
| probably never cooperate with a group myself.
| I always understand "willing to be a team player"
| as code for "expect to be an abused lackey if
| you work at our company". So I guess I'm not
| very modern myself.
|
| Don't knock a work dynamic, until you've tried it.
|

I've worked on "teams". Though it's been many
years. I've been self-employed for a long time.
What I know of teams is pecking order. Some
people are leaders. Some are followers. Both work
well in teams. Both *need* to have that structure.
Some are independents. They tend not to work well
in teams. As one of those I also don't tolerate
pecking order and don't like to hire people who
can't take care of themselves and be solely
responsible for their work.

Either way is OK. As Mr. Eastwood said so
well: "A man's just *got* to know his limitations."

But I don't accept the idea that teams are
"modern". To a great extent they're just a
psychological scam of subservience; a euphemism,
encouraging people to accept lackeyhood and
consider self-interest to be a failing, dedicating
themselves to their work far beyond what their
pay warrants, partly as devotion to their team.
As dedication to "something greater than
themselves".

Soldiers often talk like that. What gets them
to go to the field of mass murder where they're likely
to be killed, and to stay there? It's insanity. There's
no reason. No one in their right mind would do it.
But through patriotism or naivety or sense of
adventure or ambition they ended up there and
they're stuck. So they do it for their comrades.

Anyone who's worked for a large corporation
knows the kind of exploitation that's passed off
as dedication and not letting the team down.
This from Salon.com:

"When in December 2012 the Ver.Di representatives in Leipzig called on the
management of Amazon's local center to open negotiations on wage rates and
an improvement of working conditions, and especially for temporary workers
who are badly exploited at Amazon, management refused on the grounds that
employees should be "thinking about their customers" and not about their own
selfish interests."


Ads
  #62  
Old January 20th 18, 11:57 PM posted to uk.comp.homebuilt,alt.windows7.general
Diesel
external usenet poster
 
Posts: 937
Default Gibson's Meltdown/Spectre Tester

Richard Kettlewell
Thu, 18 Jan 2018 13:10:01
GMT in alt.windows7.general, wrote:

Diesel writes:
"Mayayana"
news 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.


Rather strange thing? MSVC certainly does include a runtime...I'm not
familiar with Clang, and, my experience with gcc is Linux based, and
so rather limited; aside from the few samples I've compiled so far
aren't static and require the dependencies to be present to
execute... I haven't played with the windows gcc version, so
couldn't tell you if it does/doesn't provide additional code inside
your executable to deal with various functions that wasn't purely
translated to machine code. By pure, I'm talking about assembler to
machine code or vice versa here. IE: no runtime. Which also means, if
your assembler program has an issue, unless you wrote in error
handling routines as well, the crash can be spectacular. If one
occurs.

I may not have been clear enough in my previous text. So, I'll
attempt to fix that, or, sadly, make it worse with this reply.

What I meant was that many compilers available to the would be
programmer/coder are not taking your source code and translating it
to native machine code. There's usually some overhead involved, hence
the runtimes. Where as there isn't with pure asm. The result is that
although you can typically write the program in an HLL faster, the
resulting exe is going to be bigger and consume more resources than
it otherwise may have had you written it in pure asm, or machine code
instead.

I don't find this to be a strange aspect myself, I just consider it
part of doing business when using a typical HLL.



--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit he
https://tekrider.net/pages/david-brooks-stalker.php
================================================== =
Gravity brings me down
  #63  
Old January 20th 18, 11:57 PM posted to uk.comp.homebuilt,alt.windows7.general
Diesel
external usenet poster
 
Posts: 937
Default Gibson's Meltdown/Spectre Tester

"Mayayana" news Thu, 18 Jan 2018 14:20:37 GMT in alt.windows7.general, 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.


No, those are interpreted languages. I was writing about compiled
ones. Take visual basic for example, your language of choice If i'm
not mistaken. It has a runtime embedded into your executable, OR,
depending on compiler switches, provides a very very small one, but
then depends on dlls to be present on the host.

Many have "runtimes". All of the VC++ versions
have runtimes. But those are companion function
collection libraries, also compiled to native code,
not interpreters.


Yes, they do. Where as pure asm does not. It has no need for a
'runtime' as the code you wrote in assembler was translated byte for
byte into machine code;exluding header details as that's for the OS
to properly load and execute the following machine code. This has
it's drawbacks though, of course.

The runtime is also your error handler...It tells your executing
program such and such function didn't do as you expected and sets the
error condition for you to read. So that whatever you wrote it to do
in the event it, couldn't say find a file, prompts the user. Where as
in pure asm, unless you specifically check the error flag yourself,
you don't know the i/o call you just made failed. Unless you have
code down the line that checks to see for the files existance and
acts accordingly when it doesn't find it.

Case in point, I can't take your vb code as is and translate it
directly to machine code; it has some overhead in the way. With a
pure asm source code, I actually can convert that to straight machine
code and vice versa. It's how a disassembler works, infact. It's able
to read the bytes of the file and depending on what they are, show
you the assembler it represents. Assembler and machine code have that
bond where as an HLL language typically does not.

Interpreted languages are another critter, with a lot more overhead;
they literally have the interpreter itself included with the pseudo
code they 'compiled' for you to execute them. I've seen one funky
basic like language that when it compiled your source code, literally
generated a fresh exe of itself with your own source code appended to
the end section. So when ran, instead of the ide, it interpreted and
executed your source code below. Which turned a simple hello world
program into 100Kilobytes or so.

I realize size/resource consumption isn't as important with modern
machines, and some programmers don't even consider those factors
anymore, but... I'm old school in the sense, if I know I can do the
same thing in 5kilobytes or less, I'm going to. I see no reason for
my executables to be bigger and consume more resources than is
necessary for them to do what I wrote them to be doing.

It's an old habit, granted, from my first computers where
space/resources weren't plentiful and if you wrote large programs,
you had to keep that in mind.



| 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.





--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit he
https://tekrider.net/pages/david-brooks-stalker.php
================================================== =
I do not know whether I was then a man dreaming I was a butterfly, or
whether I am now a butterfly dreaming I am a man.
  #64  
Old January 21st 18, 12:38 AM posted to uk.comp.homebuilt,alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Gibson's Meltdown/Spectre Tester

"Diesel" wrote

| No, those are interpreted languages. I was writing about compiled
| ones. Take visual basic for example, your language of choice If i'm
| not mistaken. It has a runtime embedded into your executable, OR,
| depending on compiler switches, provides a very very small one, but
| then depends on dlls to be present on the host.

It has an external runtime, msvbvm60.dll, but like
the VC++ runtimes, it's something like a function
kit or toolbox. The EXE is compiled to native code.

| Yes, they do. Where as pure asm does not. It has no need for a
| 'runtime' as the code you wrote in assembler was translated byte for
| byte into machine code

You could say that, but both are native code.
The assembly-written executable that creates
a RichEdit window and system buttons and
calls the Registry is using system DLLs. Unless
it *only* makes direct calls to CPU registers to
make calculations unrelated to anything external
then it has dependencies.
My VB6 EXE is the same in that respect: It depends
only on DLLs that are on virtually all Windows machines.
But it takes about 1 minute to make a button, rather
than 2 hours and 2 pages of code.

| The runtime is also your error handler...It tells your executing
| program such and such function didn't do as you expected and sets the
| error condition for you to read.

That depends on what function I called and where
it's coming from. If your asm and my VB both call
RegCreateKeyEx in advapi.dll then we're both getting
our error messages from the same place.

I think that's my point: For Win32 API and GUI
there are much easier ways to go about it than
assembly. I'm not criticizing using it. I'm just
questioning using it as the main tool to write
software on a modern operating system.

| Interpreted languages are another critter, with a lot more overhead;

The reason I wondered if you were thinking of
Python is because that's one example of a language
that allows embedding the support files.



  #65  
Old January 21st 18, 10:18 AM posted to uk.comp.homebuilt,alt.windows7.general
Richard Kettlewell[_2_]
external usenet poster
 
Posts: 31
Default Gibson's Meltdown/Spectre Tester

Diesel writes:
Richard Kettlewell
Diesel writes:
"Mayayana"
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.


Rather strange thing? MSVC certainly does include a runtime...


I’m talking about “compile to pseudo machine language”, not the presence
of runtime libraries. The output is machine code, there is no “pseudo”
about and it no further translation step; the CPU executes it directly.

--
https://www.greenend.org.uk/rjk/
  #66  
Old January 21st 18, 10:50 AM posted to uk.comp.homebuilt,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Gibson's Meltdown/Spectre Tester

Richard Kettlewell wrote:
Diesel writes:
Richard Kettlewell
Diesel writes:
"Mayayana"
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.

Rather strange thing? MSVC certainly does include a runtime...


I’m talking about “compile to pseudo machine language”, not the presence
of runtime libraries. The output is machine code, there is no “pseudo”
about and it no further translation step; the CPU executes it directly.


According to Wiki, it's the syntax which isn't quite standard by default.

https://en.wikipedia.org/wiki/GNU_Assembler

"Those more accustomed to writing in Intel syntax have
argued that not supporting the Intel syntax for assembly
on the x86 and x86-64 platforms, as many other assemblers
do, is a flaw.

However, since version 2.10, Intel syntax can be used
through use of the .intel_syntax directive.
"

This article isn't all that helpful.

https://en.wikipedia.org/wiki/Intel_syntax

But the comparison table here, shows the differences.

https://www.ibm.com/developerworks/l...asm/index.html

Paul


  #67  
Old January 21st 18, 11:11 AM posted to uk.comp.homebuilt,alt.windows7.general
Richard Kettlewell[_2_]
external usenet poster
 
Posts: 31
Default Gibson's Meltdown/Spectre Tester

Paul writes:
Richard Kettlewell wrote:
Diesel writes:
Richard Kettlewell
Diesel writes:
"Mayayana"
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.
Rather strange thing? MSVC certainly does include a runtime...


I’m talking about “compile to pseudo machine language”, not the presence
of runtime libraries. The output is machine code, there is no “pseudo”
about and it no further translation step; the CPU executes it directly.


According to Wiki, it's the syntax which isn't quite standard by default.


Totally irrelevant to the object code.

--
https://www.greenend.org.uk/rjk/
  #68  
Old January 21st 18, 04:43 PM posted to uk.comp.homebuilt,alt.windows7.general
Stan Brown
external usenet poster
 
Posts: 2,904
Default Gibson's Meltdown/Spectre Tester

On Sat, 20 Jan 2018 10:58:23 +0000, J. P. Gilliver (John) wrote:
Of course the splitting into modules, with properly-defined interfaces,
could be seen as an element of high-level language (-:.


Or as an element of assembler. Some sort of "call" instruction was a
feature of every assembly language, as far as I know.

With Univac assembly language in the 1960s, it was LMJ, "Load
modifier and jump". The arguments were an index register
(conventionally B11 or X11, though not necessarily -- hence the uber-
geek license plate "LMJ B11") and the address of the subroutine. The
effect was to load the address of the instruction following the LMJ
into that register, and transfer control to the subroutine.

At the end of its code, the subroutine would do an indirect jump to
the address in the register, corresponding to a "return" in higher-
level languages. I can't remember whether there was a specific
instruction used for returns in Univac assembler, or just the regular
jump instruction, and a quick review of the instruction set[1]
doesn't bring it to mind.

[1] https://www.fourmilab.ch/documents/u...tructions.html


--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
  #69  
Old January 21st 18, 05:17 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 , Stan Brown
writes:
On Sat, 20 Jan 2018 10:58:23 +0000, J. P. Gilliver (John) wrote:
Of course the splitting into modules, with properly-defined interfaces,
could be seen as an element of high-level language (-:.


Or as an element of assembler. Some sort of "call" instruction was a
feature of every assembly language, as far as I know.

[]
At the end of its code, the subroutine would do an indirect jump to
the address in the register, corresponding to a "return" in higher-

[]
(From what I remember, "gosub" and "return" were among the assembly
opcodes of any processor I ever used - 6800, 6502, 2901-style bit-slice,
96000 DSP, TMS320xxx DSP, and probably others.) I was thinking of more
formalised parameter-passing: in modular code design, it would be normal
for the job administrators to lay down how parameters are to be passed
to/between modules, by placing them in agreed registers, or even agreed
blocks of memory for larger parameters/numbers of parameters. With a
later optimisation stage that removed any case where such setting-up and
unloading was not necessary where code blocks talked only to one other
code block, _if_ such optimisation was necessary/cost-effective.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I admire him for the constancy of his curiosity, his effortless sense of
authority and his ability to deliver good science without gimmicks.
- Michael Palin on Sir David Attenborough, RT 2016/5/7-13
  #70  
Old January 22nd 18, 12:17 AM posted to uk.comp.homebuilt,alt.windows7.general
Vir Campestris
external usenet poster
 
Posts: 10
Default Gibson's Meltdown/Spectre Tester

On 20/01/2018 22:57, Diesel wrote:
I may not have been clear enough in my previous text. So, I'll
attempt to fix that, or, sadly, make it worse with this reply.

worse :P
What I meant was that many compilers available to the would be
programmer/coder are not taking your source code and translating it
to native machine code. There's usually some overhead involved, hence
the runtimes. Where as there isn't with pure asm. The result is that
although you can typically write the program in an HLL faster, the
resulting exe is going to be bigger and consume more resources than
it otherwise may have had you written it in pure asm, or machine code
instead.


The output of HLL compilers (except a few, such as Java and C#) is
native machine code. No more, no less.

If you are writing in assembly you have the option _not_ to link in
standard libraries that do helpful things like parse the command line
options and initialise a heap before entering the code of your program.

But once you are in that program (main, for C programs) you are running
the exact machine code that was generated by the compiler. Heck, when
you load an EXE on Windows all it does (sometimes) is map the code
section into virtual address space. It doesn't even read it until a page
fault happens.

Andy
--
Sometimes? That's complex...
  #71  
Old January 22nd 18, 01:05 AM posted to uk.comp.homebuilt,alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Gibson's Meltdown/Spectre Tester

Vir Campestris wrote:
On 20/01/2018 22:57, Diesel wrote:
I may not have been clear enough in my previous text. So, I'll
attempt to fix that, or, sadly, make it worse with this reply.

worse :P
What I meant was that many compilers available to the would be
programmer/coder are not taking your source code and translating it
to native machine code. There's usually some overhead involved, hence
the runtimes. Where as there isn't with pure asm. The result is that
although you can typically write the program in an HLL faster, the
resulting exe is going to be bigger and consume more resources than
it otherwise may have had you written it in pure asm, or machine code
instead.


The output of HLL compilers (except a few, such as Java and C#) is
native machine code. No more, no less.

If you are writing in assembly you have the option _not_ to link in
standard libraries that do helpful things like parse the command line
options and initialise a heap before entering the code of your program.

But once you are in that program (main, for C programs) you are running
the exact machine code that was generated by the compiler. Heck, when
you load an EXE on Windows all it does (sometimes) is map the code
section into virtual address space. It doesn't even read it until a page
fault happens.

Andy


Run a compiler and see.

In the following exercise, I went to my build VM that has
mingw in it.

*******

gcc -o filename.exe filename.c -lcomdlg32

Not shown in the trace, is gcc calling the constituents.
I wanted to collect as much as possible in one picture,
so didn't include all of that. Neither did I try to
copy and paste all the relevant shell commands that
might have been emitted. This picture is just
a teaser to get you interested. There are actually
some other EXEs that ran, from the GNU folder,
but we don't need to list or spell out what
they're doing for a simplified overview.
The nice thing about using ProcMon, is if
you need to know what happened, I can send
you the entire trace, with everything in it.

https://s13.postimg.org/ji8a5amvr/compiling.gif

In the example photo, gcc calls cc1 first.

cc1 takes filename.c and makes %temp%\ccPlc7wC.s

That .s file is assembler code with ADD, JMP, MOV etc.
It's a text file anyone can easily read. It looks
like "an assembler guy wrote it". You'd recognize
it immediately if you saw a sample.

You can even ask the compiler to "stop" at the
assembler source code generation step if you want.

Next step, is "as.exe" the GNU assembler,
takes %temp%\ccPlc7wC.s and makes %temp%\ccc6dCLM.o

That is object code. That's a binary, perhaps
with a PE32 header. Compilers actually make
different kinds of binaries, such that only
gdb can debug gcc object, while windbg can
debug Visual Studio object. But the twain
shall not meet.

Now, because I asked the compiler to please include
a system library, I need linking.

The GNU ld.exe program takes ccc6dCLM.o plus some object
file of a similar nature representing "comdlg32"
and makes my final, presumably statically linked
filename.exe. Since filename.exe is large compared
to the other files, it takes quite a few writes to
finish it. Comparatively speaking.

So the steps in the example are

compiling, assembling, linking

And the steps can be done piecewise to, as you'd
see in various makefiles.

The reason you could get away with just

compiling, assembling

is the executable calls msvcrt at runtime, for
the runtime portion of the environment. In
Cygwin, the runtime is two files. Presumably
Visual Studio has one or more runtimes
as well (sometimes you're required to download
and install particular versions or flavors).
Dynamic linking to a runtime, gives all the
"standard" C calls, as an example of what
might be in there. So even when a gcc
command line doesn't appear to link anything,
when the program runs, it does "suck in stuff".

Paul (who is definitely *not* a software developer...)
  #72  
Old January 22nd 18, 04:02 AM posted to uk.comp.homebuilt,alt.windows7.general
pyotr filipivich
external usenet poster
 
Posts: 752
Default Gibson's Meltdown/Spectre Tester

"Mayayana" on Thu, 18 Jan 2018 23:13:13
-0500 typed in alt.windows7.general the following:

I think we're all getting too old. This is turning
into one of those long threads where all the
geezers jump in:

My first computer was an abacus....

That's nothin'. We had an abacus made with stones,
and they slid uphill both ways....

Oh yeah, I remember that. My boss made me
chip and polish the stones myself....

You had an abacus?...


You had stones?

All we had was primordial soup.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?
  #73  
Old January 22nd 18, 04:05 AM posted to uk.comp.homebuilt,alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Gibson's Meltdown/Spectre Tester

"pyotr filipivich" wrote

| You had stones?
|
| All we had was primordial soup.

You probably shouldn't tell people that.
They might call you a slimeball.


  #74  
Old January 22nd 18, 04:42 AM posted to uk.comp.homebuilt,alt.windows7.general
B00ze
external usenet poster
 
Posts: 472
Default Gibson's Meltdown/Spectre Tester

On 2018-01-21 04:50, Paul wrote:

According to Wiki, it's the syntax which isn't quite standard by default.

https://en.wikipedia.org/wiki/GNU_Assembler

"Those more accustomed to writing in Intel syntax have
argued that not supporting the Intel syntax for assembly
on the x86 and x86-64 platforms, as many other assemblers
do, is a flaw.

However, since version 2.10, Intel syntax can be used
through use of the .intel_syntax directive.
"


Intel syntax is broken, I always have trouble handling it - who besides
Yoda says "Move into the box this item" ?

--
! _\|/_ Sylvain /
! (o o) Memberavid-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society
oO-( )-Oo Always proofread carefully to see if you any words out.

  #75  
Old January 22nd 18, 05:01 AM posted to uk.comp.homebuilt,alt.windows7.general
Rene Lamontagne
external usenet poster
 
Posts: 2,549
Default Gibson's Meltdown/Spectre Tester

On 01/21/2018 9:42 PM, B00ze wrote:
On 2018-01-21 04:50, Paul wrote:

According to Wiki, it's the syntax which isn't quite standard by default.

https://en.wikipedia.org/wiki/GNU_Assembler

*** "Those more accustomed to writing in Intel syntax have
**** argued that not supporting the Intel syntax for assembly
**** on the x86 and x86-64 platforms, as many other assemblers
**** do, is a flaw.

**** However, since version 2.10, Intel syntax can be used
**** through use of the .intel_syntax directive.
*** "


Intel syntax is broken, I always have trouble handling it - who besides
Yoda says "Move into the box this item" ?


"Throw the cow over the fence some hay" :-)

Rene


 




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 02:07 PM.


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