• Create Account

### #Actualfir

Posted 23 September 2013 - 10:57 AM

As i said I do not want to use window subsystem

Actually what you said is that you don't want to use WinMain(). Entry point is not synonymous with subsystem, and just because you use the Windows subsystem doesn't mean you need to use WinMain() as your entry point unless your tool chain requires it. Some tool chains will allow you to use main() as your entry point even if you use the Windows subsystem. Again, how you would go about that would depend on your tool chain. But yes, you do need to switch to a different subsystem if you don't want the console window to show up. The operating system creates the console window for any application run in the console subsystem. There's nothing application code can do to suppress that console window creation if you run in the console subsystem. And you have to run in one of the subsystems. Subsystem is specified as part of the PE executable header. If you don't have a valid subsystem entry then the OS won't know how to launch your program.

I tell you why I say I do not want a window subsystem - I got my own library flib.obj where I got my own api for making small 2d games it calls winapi internally.

I want to set up some easy environment for making games

in the form of c program using only my own libraray as an api

calls - no direct calls to winapi or any other thing just the simplicity



#include "flib.h"          // -> flib.obj

void main()
{
// game here using only functions
// given to you by flib and nothing more
}


I do not want to force a user of flib to any efforts (setting subsystem to windows or something)

I would like give him a lib, make him fire the c compiler, include header in standard c environment (preferebly would like if it would work with many compilers) and go (als I do not need, f**ing console)

What you would do it? I got a trouble here - and i consider it as a some kind of 'system' bug that it is some trouble to make it this way

### #4fir

Posted 23 September 2013 - 10:55 AM

As i said I do not want to use window subsystem

Actually what you said is that you don't want to use WinMain(). Entry point is not synonymous with subsystem, and just because you use the Windows subsystem doesn't mean you need to use WinMain() as your entry point unless your tool chain requires it. Some tool chains will allow you to use main() as your entry point even if you use the Windows subsystem. Again, how you would go about that would depend on your tool chain. But yes, you do need to switch to a different subsystem if you don't want the console window to show up. The operating system creates the console window for any application run in the console subsystem. There's nothing application code can do to suppress that console window creation if you run in the console subsystem. And you have to run in one of the subsystems. Subsystem is specified as part of the PE executable header. If you don't have a valid subsystem entry then the OS won't know how to launch your program.

I tell you why I say I do not want a window subsystem - I got my own library flib.obj where I got my own api for making small 2d games it calls winapi internally.

I want to set up some easy environment for making games

in the form of c program using only my own libraray as an api

calls - no direct calls to winapi or any other thing just the simplicity



#include "flib.h"          // -> flib.obj

void main()
{
// game gere using only functions
// given to you by flib and nothing more
}


I do not want to force a user of flib to any efforts (setting subsystem to windows or something) I would like give him a

lib fire the c compiler include geader in standard c environment

(preferebli would like if it would work with many compilers)

and go (als I do not need, fcking console) What you would do it? I got a trouble here - and i consider it as a some kind of 'system' bug that it is some trouble to make it this way

### #3fir

Posted 23 September 2013 - 10:51 AM

As i said I do not want to use window subsystem

Actually what you said is that you don't want to use WinMain(). Entry point is not synonymous with subsystem, and just because you use the Windows subsystem doesn't mean you need to use WinMain() as your entry point unless your tool chain requires it. Some tool chains will allow you to use main() as your entry point even if you use the Windows subsystem. Again, how you would go about that would depend on your tool chain. But yes, you do need to switch to a different subsystem if you don't want the console window to show up. The operating system creates the console window for any application run in the console subsystem. There's nothing application code can do to suppress that console window creation if you run in the console subsystem. And you have to run in one of the subsystems. Subsystem is specified as part of the PE executable header. If you don't have a valid subsystem entry then the OS won't know how to launch your program.

I tell you why I say I do not want a window subsystem - I got my own library flib.obj where I got my own api for making small 2d games it calls winapi internally.

I want to set up some easy environment for making games

in the form of c program using only my own libraray as an api

calls - no direct calls to winapi or any other thing just the simplicity

#include "flib.h"          // flib.obj

void main()
{
// game gere using only functions
// given to you by flib and nothing more
}


I do not want to force a user of flib to any efforts (setting subsystem to windows or something) I would like give him a

lib fire the c compiler include geader in standard c environment

(preferebli would like if it would work with many compilers)

and go (als I do not need, fcking console) What you would do it? I got a trouble here - and i consider it as a some kind of 'system' bug that it is some trouble to make it this way

### #2fir

Posted 23 September 2013 - 10:50 AM

As i said I do not want to use window subsystem

Actually what you said is that you don't want to use WinMain(). Entry point is not synonymous with subsystem, and just because you use the Windows subsystem doesn't mean you need to use WinMain() as your entry point unless your tool chain requires it. Some tool chains will allow you to use main() as your entry point even if you use the Windows subsystem. Again, how you would go about that would depend on your tool chain. But yes, you do need to switch to a different subsystem if you don't want the console window to show up. The operating system creates the console window for any application run in the console subsystem. There's nothing application code can do to suppress that console window creation if you run in the console subsystem. And you have to run in one of the subsystems. Subsystem is specified as part of the PE executable header. If you don't have a valid subsystem entry then the OS won't know how to launch your program.

I tell you why I say I do not want a window subsystem - I got my own library flib.obj where I got my own api for making small 2d games it calls winapi internally.

I want to set up some easy environment for making games

in the form of c program using only my own libraray as an api

calls - no direct calls to winapi or any other thing just the simplicity

#include "flib.h"          // flib.obj

void main()
{
// game gere using only functions given to you by flib
}


I do not want to force a user of flib to any efforts (setting subsystem to windows or something) I would like give him a

lib fire the c compiler include geader in standard c environment

(preferebli would like if it would work with many compilers)

and go (als I do not need, fcking console) What you would do it? I got a trouble here - and i consider it as a some kind of 'system' bug that it is some trouble to make it this way

### #1fir

Posted 23 September 2013 - 10:49 AM

As i said I do not want to use window subsystem

Actually what you said is that you don't want to use WinMain(). Entry point is not synonymous with subsystem, and just because you use the Windows subsystem doesn't mean you need to use WinMain() as your entry point unless your tool chain requires it. Some tool chains will allow you to use main() as your entry point even if you use the Windows subsystem. Again, how you would go about that would depend on your tool chain. But yes, you do need to switch to a different subsystem if you don't want the console window to show up. The operating system creates the console window for any application run in the console subsystem. There's nothing application code can do to suppress that console window creation if you run in the console subsystem. And you have to run in one of the subsystems. Subsystem is specified as part of the PE executable header. If you don't have a valid subsystem entry then the OS won't know how to launch your program.

I tell you why I say I do not want a window subsystem - I got my own library flib.obj where I got my own api for making small 2d games it calls winapi internally.

I want to set up some easy environment for making games

in the form of c program using only my own libraray as an api

calls - no direct calls to winapi or any other thing just the simplicity

#include "flib.h"

void main()

{

// game gere using only functions given to you by flib

}

I do not want to force a user of flib to any efforts (setting subsystem to windows or something) I would like give him a

lib fire the c compiler include geader in standard c environment

(preferebli would like if it would work with many compilers)

and go (als I do not need, fcking console) What you would do it? I got a trouble here - and i consider it as a some kind of 'system' bug that it is some trouble to make it this way

PARTNERS