flat assembler
Message board for the users of flat assembler.

Index > Heap > hll vs fasm

Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
one more problem identified:

the elementary data types we know in assembly (not depending on the platform) are:
byte 8 bits
word 2 bytes
dword 2 words
qword 2 dwords

then, why in hll, theses types are not implemented, or waits definitions from strange and ridiculous wintypes.h???

why for a platform, an int will be 16 bits, and on another platform, it will be 32?
why long, 32 or 64 for the same reason????

why does people interrested in programming makes this kind of shortcut in their learning? why don't they first learn assembly for many platform before to claim they are linux/apple/windows hll developpers that will completelly make dumb implementations???

why don't they take in account a minimal standard way to name the primary types? is that too hard for them? no, i doubt a lot, they just see assembly as a sort of useless langage without any "abstraction". and we know what abstraction means for them, it means that they have a virtual control on everything from a god level. but it is not the case at all, they are just trying to impose their dumb choices, and will just feel proud and clever to do so.

then, fight against this elementary problem about type definitions:

a BYTE is 8 bits
a WORD is 16 bits
a DWORD is 32 bits
a QWORD is 64 bits

a char is assumed to be a BYTE, and should not be anything else, if you like the utf, use a WORD or a DWORD
a QWORD is a long, and a DWORD is not a long, it should never be a long.

if it continues this way, i will spend my energy to impose many more dumb things like:
#define BYTE unsigned long int char*
#define string unsigned short vector<unsigned int long pouet>
#ifdef string
#define string string string string string string string string

[my brain is boiling]
Post 05 Sep 2013, 14:09
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 20:02; edited 1 time in total
Post 05 Sep 2013, 14:15
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
edfed wrote:

why for a platform, an int will be 16 bits, and on another platform, it will be 32?
why long, 32 or 64 for the same reason????


Indeed that is rather stupid. If the very reason for HLLs to exist is to provide an abstract machine for the programmer so that he won't have to deal with platform dependent stuff then why are platform specific types visible to the programmer at all?

Instead I'd just like to specify for example that "x is an integer with a range from 0 to 12k" or that something is a unicode character instead of having to play with chars and ints which mean different things depending on what kind of machine you want to compile your program for.

edfed wrote:

no, i doubt a lot, they just see assembly as a sort of useless langage without any "abstraction".


Abstraction is about making things more generic by hiding detail. I'm not that sure that their HLLs do that. Then again this is more of a "crappy HLL vs good HLL" problem.

edfed wrote:

and we know what abstraction means for them, it means that they have a virtual control on everything from a god level.


I think it's more about dumbing things down so that a programmer can't mess up as much and that you can more easily have one programmer replace another.

edfed wrote:

but it is not the case at all, they are just trying to impose their dumb choices, and will just feel proud and clever to do so.


I think they are just stuck with it. It's tradition after all in many languages.

I'm assuming that this is the same thing as what happened to relational databases i.e. they had to take performance into consideration and the not-really-relational monstrosity called SQL was born.
Post 05 Sep 2013, 17:07
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
Quote:
The C syntax is extremely simple - if you have problems understanding it, I honestly don't think you should be programming in any language.


Sorry man. I don't agree with this. C is a very badly designed language if indeed it was designed at all. More likely C just happened. Then it happened again. And again.

C syntax is not simple. C is full of tricks, exceptions, boundary cases, and fails the least surprise test much of the time. It is pure crap that was designed to be easy to implement in resource-constrained computing environments. It should have been put out of its misery decades ago. C is the poster child for how not to do programming languages.

A good assembly language can indeed be more clear than C. A bad assembly language is less clear. The issue about HLL (and C is NOT an HLL) is it abstracts more so people can use middleware and libraries and other stuff to get "more" done per unit time. There are some places where assembler is still the main language and HLL can never go there.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:08
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
edfed wrote:
one more problem identified:

the elementary data types we know in assembly (not depending on the platform) are:
byte 8 bits
word 2 bytes
dword 2 words
qword 2 dwords


This is wrong. It does depend on the platform.

edfed wrote:
why for a platform, an int will be 16 bits, and on another platform, it will be 32?
why long, 32 or 64 for the same reason????


Because not all hardware is the same, and there are other platforms besides Intel.

edfed wrote:
why does people interrested in programming makes this kind of shortcut in their learning? why don't they first learn assembly for many platform before to claim they are linux/apple/windows hll developpers that will completelly make dumb implementations???


What are you talking about? Do you not realize Linux Apple and Windows are far from the only platforms in the world and that most assembly language is not written on those platforms at all? The rest of your post is just bizarre, man. You need to get out more often. There is a world before Intel and there will be a world after Intel.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:12
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
TmX wrote:
HaHaAnonymous wrote:

Of course, using C doesn't justify this. The C syntax is much harder to understand than assembly.


You may want to tell that to hardcore UNIX folks, who usually insists to write (almost) everything in C.

Very Happy


First of all, "hardcore UNIX folks" are very far from the best programmers around. They use C because UNIX is written in C and has all of its interface written in C. Using anything else besides C is just stupid in that environment. None of that makes C a good language. C is the best language for coding on UNIX. That's all.

UNIX people don't write assembly unless they absolutely have no other choice. This is not because assembly isn't better than C, it's because one of the primary goals if not THE primary goal of UNIX is to be portable. C is the best tool they have for keeping UNIX portable.

Everything in context. There is no one best language or everybody would be using it. There are sometimes obvious best languages for certain things. In other cases it's not so clear what's best.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:24
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
edfed wrote:
standard is like the good old times. everybody is used to it, then, everybody continue to use it.

but of course, standard can evolve, but asking evolution of standard is like asking to switzerland to write an ISO and impose it to the world.


That's not how standards work. I can think of no case where a standard made a language worse than it would have been without a standard. The point of standards is to make it possible for more than one compiler to exist for a single language and still allow people to use either one with any expectation of success.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:28
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
What is a HLL? IMHO the whole term is relative to what you intend to do. And to be practical about all of this we shouldn't consider the language and the libraries as separate entities.


I agree. It seems dishonest to me when people try to pretend the language is separate from its libraries. If a language depends on the libraries then the libraries are part of the language.

Lots of good comments in your post. I enjoyed reading it.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:30
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
Which is what I meant. Using a macro to lessen the amount typing required is a form of positive laziness. Many programmers are constantly looking for ways to get more functionality implemented with less work as you most certainly know.


I don't agree with this. If you use macros the right way you do get more productivity, but the main benefit to macros is usually in providing APIs and building blocks so that everything is done the same way throughout a large project. Without macros or copying blocks of code (inefficient and very inflexible and error-prone) or calling subroutines (inefficient and leads to bloat), there is nothing to insure that things are done identically everywhere in a large system. A lot of errors in large systems happen when people don't serialize on resources the same way everywhere, or when they don't access control blocks the same way everywhere. And a lot of errors happen when people don't define interfaces strictly (or at all) and this makes their code break in certain cases and also makes it unmanageable and changes cost much more than they should.

Macros can help you build interfaces that improve the safety of your code. Laziness has nothing to do with it, most of the time it's much harder to define interfaces and enforce them then it would be just to slop out a bunch of code.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!


Last edited by dogman on 09 Sep 2013, 12:51; edited 2 times in total
Post 09 Sep 2013, 12:35
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
I just meant that assembly languages usually don't have a lot of features that help keeping a big codebase consistent and error free.


That is a fair and accurate statement, but it also applies to many if not most other languages.

I work on mid to mid-large systems (let's say up to 15 million lines of code before macro expansion) and the tools we have (specifically the macro assembler) are good enough to manage projects of that size and much larger (the OS is written in assembler). But I have not seen any other assembler that offers the power and flexibility of what we use so I think what you said is true.

I don't agree with most of the details of the rest of your post. It is true that strong typing and other syntax stuff can help make programs mostly work as intended if they get past the compiler (Ada, for example) but I've also seen fairly large systems that don't have type safety and also work fine. A lot depends on the designers and programmers and tools. Those are three very big variables and there are more.

Java is not an example of a language I could use because it's not useful for systems programming. It is probably a better than average language for large applications systems but it's not an example of an expert's tool that assembler programmers can really appreciate. Throwing runtime exceptions is not much more helpful than crashing. Most people don't know how to write recovery code, that is an art in itself, and most people are too lazy. So the program just crashes anyway. What did they accomplish? The point is to catch that stuff at compilation time, and Java doesn't do that. Ada mostly does and Fortran is getting better. Are there others?

nyrtzi wrote:
I'm not saying that writing big codebases is impossible in assembly. Of course it's possible. I'm just saying that some languages help more than others in working with a bigger codebase.


True, but it's also important to distinguish between language implementations. Assemblers can be very different. Unfortunately there don't seem to be many languages that really work well on large projects. The assembler I use and Ada are the two I can think of that are. Most others fall short because the compilation systems don't guarantee consistency in argument passing. This related to but not the same as strong typing. Fortran is moving in the right direction but it's taking a long time.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 09 Sep 2013, 12:47
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 19:57; edited 2 times in total
Post 09 Sep 2013, 15:55
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
dogman wrote:
Macros can help you build interfaces that improve the safety of your code. Laziness has nothing to do with it, most of the time it's much harder to define interfaces and enforce them then it would be just to slop out a bunch of code.


Which sort of macros are you referring to? Textual, syntactic or computational? Or are you just speaking in general terms?

I see any way of generating code or data automatically instead of writing it by hand as a good way of being lazy which at least to me is a positive thing as it allows me to spend more of my time on that which needs it more.
Post 09 Sep 2013, 15:58
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
dogman wrote:
nyrtzi wrote:
I just meant that assembly languages usually don't have a lot of features that help keeping a big codebase consistent and error free.

That is a fair and accurate statement, but it also applies to many if not most other languages.


I'd say to all of them simply because every language embodies some approach either to deal with or to ignore those problems which always come with a big amount of data/text/code no matter which language is used.

dogman wrote:

I don't agree with most of the details of the rest of your post. It is true that strong typing and other syntax stuff can help make programs mostly work as intended if they get past the compiler (Ada, for example) but I've also seen fairly large systems that don't have type safety and also work fine. A lot depends on the designers and programmers and tools. Those are three very big variables and there are more.


Yes, good design, quality coding and good tools can of course offset other disadvantages. A good compiler is just supposed to automate certain kinds of work. Other tools can do the same things too.

dogman wrote:

Java is not an example of a language I could use because it's not useful for systems programming. ... The point is to catch that stuff at compilation time, and Java doesn't do that.


I don't consider Java a very strongly typed language either. If a language allows one to cast a Car first into an object and then into a Duck I'd say the language's type system is as dead as Plato. Obviously a Car is not a Duck. An example which compiles but of course dies when run by throwing a ClassCastException:
Code:
// Car.java
public class Car
{
}

// Duck.java
public class Duck
{
}

// CastTest.java
public class CastTest
{
    public static void main (String[] args)
    {
        Car c = new Car();
        Object o = (Object)c;
        Duck d = (Duck)o;
    }
}
    

Code:
Exception in thread "main" java.lang.ClassCastException: Car cannot be cast to Duck
        at CastTest.main(CastTest.java:8)
    


dogman wrote:

Ada mostly does and Fortran is getting better. Are there others?


I thought that some of the functional languages are pretty good at catching stuff at compile time.

dogman wrote:

nyrtzi wrote:
I'm not saying that writing big codebases is impossible in assembly. Of course it's possible. I'm just saying that some languages help more than others in working with a bigger codebase.

True, but it's also important to distinguish between language implementations. Assemblers can be very different.


Aren't assembly languages more like a language family? What is a language? Where should we draw the line between language families, languages, dialects and implementations? MASM vs FASM vs NASM vs GAS? C++ with STL vs pre-STL C++? C is a subset of C++ (kind of)? C++ on Windows vs C++ with Qt? I mean if the library also counts as a part of the language as a whole in which the library is the actual main vocabulary you need to work with and the syntax is just the way to connect the words into something meaningful.
Post 09 Sep 2013, 16:49
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
dogman wrote:

First of all, "hardcore UNIX folks" are very far from the best programmers around. They use C because UNIX is written in C and has all of its interface written in C. Using anything else besides C is just stupid in that environment. None of that makes C a good language. C is the best language for coding on UNIX. That's all.


I'm certainly aware of that.
That was just a joke, anyway. Smile
Post 10 Sep 2013, 02:23
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
HaHaAnonymous wrote:
Quote:

They use C because UNIX is written in C and has all of its interface written in C.

This applies to lazy people.


No, it applies to practical people who have different values and priorities than we do.

HaHaAnonymous wrote:
Quote:

Using anything else besides C is just stupid in that environment.

This comment is ridiculous.


I think I gave good reasons for what I wrote. I don't like banging my head against walls. I have a life, hobbies, etc.

HaHaAnonymous wrote:
I've never coded a line of C and I already made many programs for the Linux platform using just "FASM" and/or "Free Pascal". And I can tell you: There's nothing stupid about it.


I don't write C either. It's a crap language. But if you're going to write any serious code on UNIX that's not very domain specific where you have an obvious better choice then if you don't use C you just make life harder for yourself. I avoid this problem mostly by not coding on UNIX.

HaHaAnonymous wrote:
Quote:

UNIX people don't write assembly unless they absolutely have no other choice.
Not me. I do this quite often (especially when I have other choices).


Then you're not a UNIX person by definition. You're arguing out of context, asymptotically and although you're quoting what I wrote, I get the impression you didn't understand anything I wrote.

HaHaAnonymous wrote:
Quote:

C is the best tool they have for keeping UNIX portable.

This was already discussed in the past. And my conclusion was: NO PROGRAMMING LANGUAGES ARE PORTABLE.


I don't know who you're arguing with because you're quoting me out of context and then responding to things I never wrote. You cannot possibly argue successfully that UNIX is not portable enough, or that C is not portable enough. Portability is not absolute. For this purpose (making UNIX run on more than one platform) C is the best compromise.

C is the best tool they have for keeping UNIX portable. I don't know how I can be more clear than that.

HaHaAnonymous wrote:
Quote:

That's not how standards work.

That's one more uncomfortable thing. I break standards quite a lot, many of them are just stupid (but some are acceptable).


You're quite masterful at taking things out of context! This has nothing to do with individual coders "breaking standards" as if that were even possible for you. The standards are mostly addressed at compiler and OS writers to insure their compiler and OS are useful to consumers of similar compilers and OS. We all benefit from that to some degree but it doesn't impose any restrictions on us.

HaHaAnonymous wrote:
Quote:

There are sometimes obvious best languages for certain things. In other cases it's not so clear what's best.

The best is what you're happy with. No "frescuragem" about it.


That is one criteria. But there's a lot more to consider than that. And there's a big difference between being a guy sitting at home with a PC and nothing else to do and a guy who gets paid to write code for a living.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 10 Sep 2013, 05:44
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
dogman wrote:
Macros can help you build interfaces that improve the safety of your code. Laziness has nothing to do with it, most of the time it's much harder to define interfaces and enforce them then it would be just to slop out a bunch of code.


nyrtzi wrote:
Which sort of macros are you referring to? Textual, syntactic or computational? Or are you just speaking in general terms?


I'm talking specifically about using macros as I use them, which is to provide interfaces to services and linkage between programs. You build services and then define an API and then provide macros implementing that API to people who want to consume the services. When you have a big product with many programs you should use macros to map the control blocks and data areas so that the control blocks and data areas are all serialized, accessed, etc. in the same way whenever they're used. It's also a form of interface and it is a huge help in writing correct code that can be maintained over a long period of time.

nyrtzi wrote:
I see any way of generating code or data automatically instead of writing it by hand as a good way of being lazy which at least to me is a positive thing as it allows me to spend more of my time on that which needs it more.


That is certainly a very traditional and "normal" use of macros. But it is only the tip of the iceberg in that there is a lot more value you can get from using macros. And there is a point where people abuse macros and obfuscate things that really should have been done in open code or in other ways. I tend to use macros in very specific circumstances and very specific ways, and I know right away when I see a piece of code whether it's any good or not by the way it's organized, as in what the designer/coder chose to do with macros, subroutines, program stucture, data modeling, etc.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 10 Sep 2013, 05:47
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
dogman wrote:
nyrtzi wrote:
I just meant that assembly languages usually don't have a lot of features that help keeping a big codebase consistent and error free.

That is a fair and accurate statement, but it also applies to many if not most other languages.


I'd say to all of them simply because every language embodies some approach either to deal with or to ignore those problems which always come with a big amount of data/text/code no matter which language is used.


If so you seem to be changing your stance from what you wrote earlier. First (see quoted text above) you pointed at assembly languages as not having features to work on a big codebase effectively. Then, once I said it applies to many if not most languages you agreed with me. But you're writing it now as if you disagree with me Wink

nyrtzi wrote:
dogman wrote:

Java is not an example of a language I could use because it's not useful for systems programming. ... The point is to catch that stuff at compilation time, and Java doesn't do that.


I don't consider Java a very strongly typed language either. If a language allows one to cast a Car first into an object and then into a Duck I'd say the language's type system is as dead as Plato. Obviously a Car is not a Duck. An example which compiles but of course dies when run by throwing a ClassCastException:


I didn't say Java wasn't typed strongly enough. My objections to Java are too numerous to list here but typing is not one of them and it doesn't address the issue of catching things at compilation time except at a very crude level. There are usually well-designed limits of what compilation systems are supposed to do. I believe Ada would not allow that code to compile.

nyrtzi wrote:
dogman wrote:
Ada mostly does and Fortran is getting better. Are there others?


I thought that some of the functional languages are pretty good at catching stuff at compile time.


I don't know, since I don't use them. For work I write 100% assembler. For my personal code I write in various languages I like. I don't think any of them could be called "functional languages."

If you consider LISP as the grandaddy of all functional languages, and if that is any example, then I think they don't, because most functional languages have an unusual compilation system that is more like just-in-time than it is like C or Fortran, and I think very permissive. I would say they're very weak in semantic analysis. But maybe I'm wrong. Maybe there is some hapless functional coder on the forum who could give us a few examples. I liked your code examples, btw. They illustrate various points nicely.

nyrtzi wrote:
Aren't assembly languages more like a language family?


Only in the sense that all computer languages are a family, or all languages are a family. Other than that, assemblers are among the most dissimilar languages around because they're bound to totally different hardware. Gnu's assembler is a bad example because it was designed to be as common as possible so it could be a back-end to their cross-compilers. But that is not typical.

nyrtzi wrote:
What is a language? Where should we draw the line between language families, languages, dialects and implementations?


That depends on what interests you. Personally I don't care what labels people put on stuff. I know what I like and I know what I don't like. But I do get interested when people talk about assemblers and assembly language programing of any kind at all. Razz

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 10 Sep 2013, 06:09
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
dogman wrote:
nyrtzi wrote:
dogman wrote:
nyrtzi wrote:
I just meant that assembly languages usually don't have a lot of features that help keeping a big codebase consistent and error free.

That is a fair and accurate statement, but it also applies to many if not most other languages.

I'd say to all of them simply because every language embodies some approach either to deal with or to ignore those problems which always come with a big amount of data/text/code no matter which language is used.

If so you seem to be changing your stance from what you wrote earlier. First (see quoted text above) you pointed at assembly languages as not having features to work on a big codebase effectively. Then, once I said it applies to many if not most languages you agreed with me. But you're writing it now as if you disagree with me Wink


What I meant was that for example any program that grows big enough is going to contain a lot of identifiers of different sorts. Therefore any language that is used to write something big will encounter the same problem and will have to decide what to do about it. Some languages help with this issue more than others. That was my point. Assembly less. C++ more.

dogman wrote:

I didn't say Java wasn't typed strongly enough. My objections to Java are too numerous to list here but typing is not one of them and it doesn't address the issue of catching things at compilation time except at a very crude level. There are usually well-designed limits of what compilation systems are supposed to do. I believe Ada would not allow that code to compile.


Then Ada does "the right thing" (tm).

dogman wrote:

If you consider LISP as the grandaddy of all functional languages, and if that is any example, then I think they don't, because most functional languages have an unusual compilation system that is more like just-in-time than it is like C or Fortran, and I think very permissive. I would say they're very weak in semantic analysis. But maybe I'm wrong. Maybe there is some hapless functional coder on the forum who could give us a few examples.


Yes, Lisp is the grandpa but some of the offspring are rather different. Like for example the ML language family and Haskell. They tend to be rather strict and nag about stuff. Where Lisp concentrates on the values and their latent typing at runtime these others try to make the programmer build the whole conceptual model of the program specifically around the type system at compile time. I don't like their syntax though.

dogman wrote:

I liked your code examples, btw. They illustrate various points nicely.


Thanks. I try to make them rather explicit and straight to the point.
Post 10 Sep 2013, 19:54
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 19:59; edited 1 time in total
Post 10 Sep 2013, 21:36
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
Maybe it's the language barrier Wink
Post 11 Sep 2013, 03:06
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.