Okay, as I want to go to 64 bit mode (on 32 bit OS, it is possible) , then calculate my stuff (no system-calls in this time) and after finishing go back to 32 bit mode and the do my system-calls and all other stuff (ie delay). To do so I know I need to clear the interrupt-flag (so no interrupt-procedure is started witch use 32 bit) and later set it back again to 1, after my personal 64 bit mode. Does this deactivating of interrupts affect the OS (no mater witch OS my app runs), ie display errors, hardware problems, or are the interrupts executed after activating the interrupts again? Or what happens?
Plz help me!

I don't think you'd be able to switch to long mode from ring 3 (i.e. user mode) - switching modes possible only from ring 0 (i.e. kernel mode). The same thing goes for interrupt disabling and enabling (strictly speaking, this depends on IOPL value, although it's usually 0). Your program will simply raise an access violation.

Hi,
I guess you will do this job using driver (I don't see another way). Execute CLI, setup long mode, execute your 64 bit code, return back to 32 bit mode, execute STI.
If you are fast enough nothing bad happens usually. If you are too slow, then win may watch CPUs in SMP machine and detect that e.g. secondary CPU didn't respond in usual timeout and reboot (watchdog timer, I got that a lot of times under win 2008 server R2 x64) - but perhaps watchdog is only new ms feature (not in older OS) - I don't know. Anyway, interrupts will be pending and delivered correctly after you execute STI.
Executing CLI/STI is very costly thing, if you look into kernel, interrupts are always disabled only as short as possible. Better way is to setup IRQL (mov reg64,IRQL \ mov cr8,reg64) to disable only low priority interrupts and allow to hit high priority interrupts. But in case switching 32 bit to 64 bit mode, interrupts must be surely completely disabled by the CLI.
If you want to play with long mode, why to use running 32 bit OS? You may directly load your code at boot stage or you may even try some simulator to avoid reboots (bochs, qemu, etc)
3 years ago I got a paid task to switch running ms windows in such situation at single CPU system: 64 bit -> 16 bit -> 64 bit (research to execute 16 bit interrupt in running 64 bit ms windows as 64 bit ms win doesn't support 16 bit subsystem). I spent about 1 month (few hours almost every evening, I was less skilled than today, I may say I was novice in kernel programming) until I put all together (the worse was return back from 16 bit to 64 bit - not the mode to return but the fact that ms windows x64 had to run normaly then). The whole task was made between CLI / STI. The 16 bit interrupt was called in such way that 16 bit exception handler which turned on keyboard LEDs was prepared and its 16 bit real mode address was put into correctly memory place and then it was executed directly by e.g. int 80h instruction or something like this - perhaps another number instead of 80h. Not surprise, FLAGS.IF=0 prevents only maskable external interrupts to hit (timer, harddisk, keyboard...) it doesn't prevent to normally execute the software INT instruction / exceptions / MNI.

first: thx a lot for this quick reply's
So I have to write an 32 bit driver and an 32 bit app, witch calls this driver per interrupt? and write more or less my whole code into this interrupt/driver. So I also have to install it on every OS as an driver?
It should get a server, but it also shouldn't take the whole machine for itself and in addition I don't to write driver for all network-cards, display and what else is needed(has to run on different machines).
And what is the main difference in programming between an normal app and a driver?

you create normal 32 bit driver
driver executes CLI
driver switches 32->64
driver executes 64 bit code
driver switches 64->32
driver executes STI
thats all
you don't need to play with interrupts (no need to create interrupt table, no need to call software interrupt)
the difference between doing ring3 app and ring0 driver is at least in count of BSODs and reboots
download some samples of drivers, they are available here at FASM forum and in FASM download section
if you start driver programming and when you increase your skills enough, you may find some good job (it's quite motivating, isn't it?)

yes it is motivating, I will sit down to the task in this summer, when I have more time, now I will concentrate on programming a 32 bit and 64 bit app, later I make this driver thing
thanks a lot