Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jan 2012
Offline Last Active Dec 17 2015 12:59 PM

#5168844 This singleton keeps crashing.

Posted by on 24 July 2014 - 04:52 AM

Btw. using int as datatype is critical, because it's size isn't constant through x86 and x64 and different OS. You should use char, short or long.

If you needed fixed sizes for your datatypes use stdint.h this header file should be part of the compiler and works in respect to the pre defined macros a compiler issues. The headerfile defines types like int16_t uint32_t and so on. The usage of these types guarantee that the variables/attributes are always the expected size regardless you compile for 32 or 64 bit OS.


Only for MS development environments this headerfile was not part of developerstudio. But because I did not use them for a long time it may changed since my last try. But somewhere in the internet you will even find a MS compatible version of stdint.h

#5166213 Keep getting stuck

Posted by on 11 July 2014 - 09:12 AM

I never had problems with pointers. I prefers them much even I know that C++ has references as well.

So I am a bit the wrong person to tell you how to come to it. Only tell you: Dont deperate.

#5166210 Keep getting stuck

Posted by on 11 July 2014 - 09:03 AM

The only thing I can tell is that you are not alone getting stuck when it comes to pointers.

#5166027 memory map questions

Posted by on 10 July 2014 - 08:56 AM

Uninitialized data has been put in BSS (Base Storage Segment) for some hundred years of computer technology.

malloced data is taken from a block that gets requested from the OS. sbrk() and brk() are the ones.

#5165766 Tcp + iocp handling data receive and reusable sockets

Posted by on 09 July 2014 - 03:28 AM

If I would like to attack a server I would not close the socket. Only sending a syn-paket that will open the socket on your accept and let it starve. This way I send you 60k sync packets, that would be very quickly done at thats it for your server.

I think socket reuse is nothing that helps you anything against an attack.


I would think more about reusing your management for the sockets. If you are building the application with something object oriented language it would be a good thing to prevent the applicaion of constructing and deleting objects all the time.

#5165654 some assembly unknowns

Posted by on 08 July 2014 - 03:28 PM

In modern os the segment registers are only set once by the os. They use a flat memory model. Access to the segment descriptors is only possible by the os. Changing the segment registers to some value other than they are set after startup, shall lead to crash/exception.

#5165644 some assembly unknowns

Posted by on 08 July 2014 - 02:59 PM

Prefix codes 66 and 67 are available even in 32 and 64 bit modes. They are called operand size prefix and address size prefix. The CPU determines the default operand and address sizes from the D bit in the segment descriptors. With these prefixes this can be overriden for single instructions.
AFAIK this is extended for segments with 32 Bit and 64 bit as well. For some SIMD instructions this prefix is mandantory. If you want to know more about that read the programming manuals.

#5165492 raw binary to obj conversion

Posted by on 08 July 2014 - 02:47 AM


It depends completly on your experiences. Take a look into the specifications. There you find all information you need to make a decission.


I think you should quit this pseudo answers , when someone os asking specific questions, such answer like "go googling" or "go reading dosc" are not valuable at all - so really better not answer at all - Im not sure if i had option to block you but if you will repeating such way i will filter you out


So you expect that others read the specification and tell you what to do? Sounds like that. Because you do not ask specifics about the format, this is the first answer to give. Read the doc. If you do not understand parts of it, ask for help. Thats the way it works.

But not asking for help and refuse to read the first information source available, the specification.

#5165482 raw binary to obj conversion

Posted by on 08 July 2014 - 02:18 AM

It depends completly on your experiences. Take a look into the specifications. There you find all information you need to make a decission.

#5165475 raw binary to obj conversion

Posted by on 08 July 2014 - 02:01 AM

Assemblers and compilers are the tools to generate object files.

If you want to generate it in another fine way, write the tool yourself. Look into the specifications for the various object file formats and choose one to implement. Should not be very hard with your experiences.


Generating a bin file from objects is called linking. For embedded systems you often have an additional step of locating, because the different sections defined in an object file needs to be moved into the right memory addresses.


If someone needs an image file or some binary data within his/her application they use their application development environment and put it in as data. The toolchain do the rest. So it would be surprising if someone would need a special tool to create an object file from a binary.

#5164281 Installer for Linux?

Posted by on 02 July 2014 - 05:28 AM

there are some different package managers out there that are used in various distributions.

So you should support these package managers.






are the one I know in a hurry.

#5163914 very strange bug (when runing c basic arrays code)

Posted by on 30 June 2014 - 02:01 PM

fir does not use debuggers because he do not have bugs in the software he is writing. Only misbehaviour of compilers, operating systems and a complete misinterpretation of the language specification from the compiler vendors forcing him to analyze the resulting binary only and how it came to strange results the binary produces.


*sarcasm off*

#5163888 very strange bug (when runing c basic arrays code)

Posted by on 30 June 2014 - 12:52 PM

The callstack is of interest because it maybe corrupted by some operation that you dont see at the moment. Maybe the stack-frame is corrupted or something else is wrong. The debugger maybe shows you other information, exceptions or the like. Because of the nature of optimized code noone will debug assembler output that the compiler generates after doing massive optimizations because the assembler statements are normally little correlate with the source code.


So dont expect anyone to look into a bunch of assembler statements to tell you whats wrong with it.

#5163787 small structures passing

Posted by on 30 June 2014 - 02:56 AM

Have a look on the ABI (application binary interface) of the compiler and/or operating system.

Because many libraries come with the operating system the operating system defines some standard for passing parameters to functions and how they can be stored in registers instead moving them accross the stack.

This is what the ABI is for. If some special passing mechanism is used it must be made sure that you do not link diffent calling conventions (ABIs) together. If I remember right there has been in the history of MS compilers a calling convention "fast call" that used nearly all registers to pass parameters. To make sure that the caller is aware of it the linker symbols for such functions has prepended an @. This way they make sure not to call a fastcall function from some code that is not aware of this.

#5163669 sse-alignment troubles

Posted by on 29 June 2014 - 12:56 PM

Yes this is true.